Weblog entry #2 for chrisrend

sftp -b
Posted by chrisrend on Wed 13 Jun 2007 at 17:20
Tags: none.
Hello all, I have an SSH/SFTP question in regards to the new version in Etch.

I used to use the sftp -b option with a password but now it looks like sftp batchmode disables the password authentication at the prompt automatically. I don't want to automate the transfers completely with a key and cron. I just dont want to have to enter the same commands everytime and still want to authenticate via a password entered at the prompt by manually running sftp and entering a password. Is there any way I can still do this with the updated sftp using a command file? I have searched the web and found no solution, any help is appreciated thanks!

Chris

 

Comments on this Entry

Posted by dkg (216.254.xx.xx) on Wed 13 Jun 2007 at 17:52
[ Send Message | View dkg's Scratchpad | View Weblogs ]
Interesting. I don't use password-based authentication enough to run into this myself, but from a couple experiments, i couldn't figure out how to coax sftp to connect with a password in batch mode either.

I recommend setting up an ssh keypair (as discussed on this site recently), and using an ssh agent to manage it. If you really want to force yourself to type a password on each connection, set up the keypair, and then instead of invoking

sftp -b batchfile fubar
do:
 ssh-agent sh -c 'ssh-add /path/to/private/key; sftp -b batchfile fubar'
Using the agent this way lets the sftp process see the activity as "non-interactive", while you still have to give the agent access to your key via a password.

[ Parent | Reply to this comment ]

Posted by Anonymous (221.115.xx.xx) on Thu 14 Jun 2007 at 08:50
How about using `expect' with ssh(sftp)? Though maybe you have to modify your script largely.


- Ssh login expect script to supply password
http://bash.cyberciti.biz/security/sshlogin.exp.php

[ Parent | Reply to this comment ]

Posted by dkg (216.254.xx.xx) on Thu 14 Jun 2007 at 16:30
[ Send Message | View dkg's Scratchpad | View Weblogs ]
I think this might be backwards: the author already has an sftp batch file ready. The problem is that /usr/bin/sftp isn't willing to prompt for a password when it runs a batchfile.

If you were going to use expect, you'd need to use expect to automate the entire process, including all the sftp commands. This probably means rewriting the batchfile, which i don't think the author wants to do.

[ Parent | Reply to this comment ]

Posted by chrisrend (65.89.xx.xx) on Thu 14 Jun 2007 at 18:44
[ Send Message | View Weblogs ]
Thanks for the replies. I am not sure I want to use expect because I don’t want the password to be in history on the machine in plain text and I don’t really want to use a key pair because if one machine is compromised the second one is easily accessible (not that it would happen :). Maybe I am just paranoid but I don’t understand the rational of openbsd disabling interactive logins for batch mode, except that they are maybe preventing people from using plain text passwords on the host in the first place... I think I am just looking for a simple solution; modifications to ssh_config that will re enable interactive logins for batch. I have messed around with ssh_config and I can't overwrite the automatic disabled login when batch mode is enabled. I may bring this up to the openbsd folks... there should be some way to reactivate interactive logins for batch mode.

After looking at expect more there should be a way to get expect to just prompt for a password instead of putting it on the command line right? I don’t know I guess I have some more research to do. Thanks again!

[ Parent | Reply to this comment ]

Posted by dkg (216.254.xx.xx) on Thu 14 Jun 2007 at 20:49
[ Send Message | View dkg's Scratchpad | View Weblogs ]
I don't really want to use a key pair because if one machine is compromised the second one is easily accessible
What makes you say this? If your private key is stored with a strong passphrase (and why wouldn't it be?), it should not be an easy thing for someone who compromises the host containing the private key to crack it open. Without cracking the passphrase on the private key, i don't see how the attacker can gain easy access to the second machine. Can you explain?

I tend to think that keeping a one or two private keys on a single well-maintained, well-monitored personal computer is a better choice than dozens of passwords scattered everywhere. And it's probably a better choice than typing passwords in the clear into remote machines, as well, since a compromised remote account can just sniff the typed password and record it for future use.

Do you use ssh-agent in the normal way? The way i proposed above is a very specialized way to use that tool, trying to match what seemed like the user experience you were looking for. I find that using ssh-agent, when configured to prompt you to confirm each use, is the most convenient and most secure way i've used ssh yet. If only i could combine it with a reasonable key revocation and update infrastructure... (but that's another post)

[ Parent | Reply to this comment ]