Hi,
There is one approach that might work. Certainly, what I'm about to discuss worked for me on my own local Linux box. But without a doubt the best solution here is to use SSH keys. But if you really don't want to do this (though they are far more secure than passwords, and a better idea by far in general), then you could try the following.
First, create a script like this, whose sole purpose in life is to echo out your password.
$ cat sshpass.sh
#!/bin/bash
echo password
Next, create a plain text file containing the commands you want SFTP to run. For example:
$ cat ssh.txt
cd /
ls -lrt
quit
$
Next, try the following technique (involving setting the SSH_ASKPASS environment variable and the setsid
command) to fool sftp
into using your script to provide the password. Note that you don't actually need ssh-askpass
installed for this to work.
$ export SSH_ASKPASS=/home/unixforum/sshpass.sh
$ setsid sftp unixforum@localhost < ssh.txt
$ Connected to localhost.
sftp> cd /
sftp> ls -lrt
drwxr-xr-x 2 root root 4096 Aug 20 2013 srv
drwx------ 2 root root 16384 Dec 18 2013 lost+found
drwxr-xr-x 2 root root 4096 Dec 18 2013 cdrom
drwxr-xr-x 6 root root 4096 Jul 14 2015 mnt
drwxr-xr-x 3 root root 4096 Sep 1 2015 omd
drwxr-xr-x 12 root root 4096 Jan 29 2016 usr
-rw------- 1 root root 30085120 Feb 8 2016 core
drwxr-xr-x 2 root root 4096 May 19 2016 snap
drwxr-xr-x 16 root root 4096 Jun 3 2016 var
drwxr-xr-x 2 root root 4096 Nov 11 15:43 media
drwxr-xr-x 11 root root 4096 Dec 5 13:03 opt
drwxr-xr-x 2 root root 4096 Dec 9 09:58 lib64
drwxr-xr-x 30 root root 4096 Feb 10 09:55 lib
drwxr-xr-x 5 root root 4096 Feb 11 09:59 home
lrwxrwxrwx 1 root root 32 Feb 22 10:08 initrd.img.old
lrwxrwxrwx 1 root root 29 Feb 22 10:08 vmlinuz.old
drwxr-xr-x 2 root root 12288 Feb 24 09:56 bin
drwxr-xr-x 2 root root 12288 Mar 8 10:06 sbin
lrwxrwxrwx 1 root root 32 Mar 8 10:07 initrd.img
lrwxrwxrwx 1 root root 29 Mar 8 10:07 vmlinuz
drwxr-xr-x 5 root root 3072 Mar 10 10:07 boot
dr-xr-xr-x 303 root root 0 Mar 17 10:36 proc
dr-xr-xr-x 13 root root 0 Mar 17 10:36 sys
drwx------ 26 root root 12288 Mar 17 13:55 root
drwxr-xr-x 218 root root 16384 Mar 17 13:55 etc
drwxr-xr-x 21 root root 4900 Mar 20 10:08 dev
drwxrwxrwt 18 root root 24576 Mar 20 16:42 tmp
drwxr-xr-x 41 root root 1500 Mar 20 16:42 run
sftp> quit
Now, a few caveats here. The point of the use of setsid
here is to detach sftp
from your current session, thus preventing it from picking up on the fact it has a valid terminal attached. Without a valid terminal to prompt for a password, it falls back on the program specified in the SSH_ASKPASS environment variable to provide the login details.
This works, but it's very much an odd way to go about doing things, and will leave your terminal in an odd state with sftp
still sort-of-connected to it (you'll see what I mean if you try typing some things at what looks like your shell prompt after doing this).
As I say, the best solution by far here (and the one I've used 100% of the time in similar situations myself with no issues whatsoever) is to use key authentication. That is literally what it was designed for. But if for some reason you're dead set against doing that, then this nasty kludge of a work-around should at least work, if not well or cleanly.