On Thursday 06 September 2007 15:54, Shachar Shemesh wrote: > Storing a password in plain text truly is less secure than using private > keys (especially with ssh-add),
This bug isn't about storing passwords. sshpass doesn't store passwords, it leaves that up to the program that invokes it. Right now, my program does store passwords in plain text (base64 actually), but the plan is to move the passwords into something like kwallet, which stores the passwords encrypted against a passphrase. As a side note, storing passwords in plain text (which is not the issue here) is no less secure than using public key authentication with a weak or empty passphrase. Either way, if your secrets file is compromised, it's bad. MIT Kerberos stores its master key unencrypted on the disk, by the way. > and so I am a bit reluctant to make the > use of sshpass as a replacement to public key authentication too easy. I understand your reservations, and I think the warnings in the package description and the man page are more than enough warning. As a package maintainer, there is little you can do beyond that; You can't prevent users from posting their private SSH keys on Usenet, for example. > It's more to do with the fact that when run through sshpass, the ssh > process is connected to a different TTY than the one used by sshpass and > the parent process. If passing SIGWINCH along to ssh is all it will take > to make things work, I will gladly do it. If it takes starting to figure > out what goes wrong and why, I somewhat doubt I'll invest the time > (though, if you write a patch, I'll incorporate the fix into upstream, > of course). Oh, it uses a different tty? I think there might be an ioctl that sshpass needs to handle, then. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
