A co-worker argues we can login using only password to a "ssh-key restricted host (PasswordAuthentication no)", without being asked by any passphase; just by putting a key (no need to be the private key) on another password-based host. It that true? I do not think so. I would name that as an "important OpenSSH daemon security bug". That is because I think it is not true. co-worker wrote:> You cannot distinguish passphrased keys from passphraseless ones.I think the OpenSSH daemon will take care to ask for a key passphrase before using a key to open an encrypted channel. A ssh key which requires a ssh passphrase to be usable can not be used to open a ssh connection if such ssh passphrase is not provided, as it is part of the encryption algorithm. I know we can create ssh keys without passphrases (useful for unattended backups, scripts and so on). However our users will be told not to do that, of course, as they are told not to create weak passwords. co-worker wrote:> I am all for encouraging key-based logins, but I think disabling > password logins completely actually reduces security.Of course I disagree because I think such "OpenSSH daemon security bug" is not a true story. It is a false one. What do you think?
It's true that for some threats a poorly managed ssh private key is weaker authentication than a well managed password. Trying to fix poor password management (brute force ssh password guessing doesn't work with well managed password policies) by mandating the use of ssh keys is generally a recipe for disaster. (If you can't enforce a password policy why on earth do you think you can enforce a key management policy?) Both mechanisms have their strengths and weaknesses, and neither should be chosen over the other unless you understand what those are. In many cases the ideal option would be *both* a certificate *and* a password. Mike Stone
On Tue, Jan 5, 2010 at 4:01 PM, Davi Diaz <davi at leals.com> wrote:> A co-worker argues we can login using only password to a "ssh-key restricted > host (PasswordAuthentication no)", without being asked by any passphase; just > by putting a key (no need to be the private key) on another password-based > host. > > It that true? I do not think so. ?I would name that as an "important OpenSSH > daemon security bug". That is because I think it is not true.You can only login using keys if the public key is included in the 'authorized_keys' file on the server. The ssh client will read the private key (passphrased or not, ask for a passphrase if needed (or read from an agent)). The server has no way of knowing if the key had a passphrase (was encrypted), as it never sees the private key. The private key is only used for authentication/encryption on the client-side.> co-worker wrote: >> You cannot distinguish passphrased keys from passphraseless ones.True (server never sees the key, only the result of computations on the decrypted key)> I think the OpenSSH daemon will take care to ask for a key passphrase before > using a key to open an encrypted channel.False, the client handles keys> A ssh key which requires a ssh passphrase to be usable can not be used to open > a ssh connection if such ssh passphrase is not provided, as it is part of the > encryption algorithm.False> I know we can create ssh keys without passphrases (useful for unattended > backups, scripts and so on). ?However our users will be told not to do that, > of course, as they are told not to create weak passwords. > > > co-worker wrote: >> I am all for encouraging key-based logins, but I think disabling >> password logins completely actually reduces security.I must agree here, while keys are better then passwords, it's impossible to enforce passphrase quality on keys, while it is possible to enforce some quality on passwords. -- Mark Janssen -- maniac(at)maniac.nl -- pgp: 0x357D2178 | ,''`. | Unix / Linux Open-Source and Internet Consultant @ Snow.nl | : :' : | Maniac.nl MarkJanssen.nl NerdNet.nl Unix.nl | `. `' | Skype: markmjanssen ICQ: 129696007 irc: FooBar on undernet | `- |
> co-worker wrote: > > You cannot distinguish passphrased keys from passphraseless ones.Is there any way to detect from sshd whether a private key has a passphrase or not? That would allow add a configuration option to be able to reject keys which does not has passphrases? That would be a security enhancement for OpenSSH.
Hello, Password authentication and password-protected keys are two different things. Using password-protected keys, the decryption of the private key is done on client side (to protect the confidentiality of the key), and there is nothing in the SSH protocol which could stop the behavior of accepting "less secure keys because they were stored in clear". It's not less secure than writing the utterly complex password in a clear text file because you can't remember it. So the quote from your coworker>> You cannot distinguish passphrased keys from passphraseless ones.Is true.>> I am all for encouraging key-based logins, but I think disabling >> password logins completely actually reduces security.Possibly, especially when you need to authenticate from a host whose security is not known (cyber-caf?, friends station, ...). A OTP or 2-factor authentication is preferred. Regards, Aris Davi Diaz a ?crit :> A co-worker argues we can login using only password to a "ssh-key restricted > host (PasswordAuthentication no)", without being asked by any passphase; just > by putting a key (no need to be the private key) on another password-based > host. > > It that true? I do not think so. I would name that as an "important OpenSSH > daemon security bug". That is because I think it is not true. > > > co-worker wrote: >> You cannot distinguish passphrased keys from passphraseless ones. > > I think the OpenSSH daemon will take care to ask for a key passphrase before > using a key to open an encrypted channel. > > A ssh key which requires a ssh passphrase to be usable can not be used to open > a ssh connection if such ssh passphrase is not provided, as it is part of the > encryption algorithm. > > I know we can create ssh keys without passphrases (useful for unattended > backups, scripts and so on). However our users will be told not to do that, > of course, as they are told not to create weak passwords. > > > co-worker wrote: >> I am all for encouraging key-based logins, but I think disabling >> password logins completely actually reduces security. > > Of course I disagree because I think such "OpenSSH daemon security bug" is not > a true story. It is a false one. > > What do you think? > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev >-- Aris Adamantiadis -- BELNET, Customer Relations Technical Advisor t: ++32 2 790 33 33 Dept: customer at belnet.be Contact: http://www.belnet.be/contact.html
On Jan 5, 2010, at 9:37 AM, Davi Diaz wrote:>> co-worker wrote: >>> You cannot distinguish passphrased keys from passphraseless ones. > > Is there any way to detect from sshd whether a private key has a passphrase or > not? > > That would allow add a configuration option to be able to reject keys which > does not has passphrases? That would be a security enhancement for OpenSSH.In a word "no"... Because the server never sees the private key. The client handles the decrypting if there is a need. - Ben
You might want to check out pamobc at http://sourceforge.net/projects/pamobc. pamobc provides sshd with an out-of-band challenge-response authentication mechanism delivers one-time passwords through any user-land mechanism of your choice (i.e., email, pager, cell phone, etc). The one-time pwds can optionally be encrypted to create a two-factor authentication mechanism. Damien Miller wrote:> On Tue, 5 Jan 2010, Davi Diaz wrote: > > >> Unfortunately we can not configure sshd to require both >> account-password and key authentication to be able to login. That >> maybe would help to solve the key management risk because at least we >> could automate the check to force the use of strong account-passwords >> in our policy security. >> > > Watch activity on https://bugzilla.mindrot.org/show_bug.cgi?id=983 if > you are interested in progress on this feature. > > -d > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev >
Michael Stone wrote:> mandating the use of ssh keys is generally a recipe for disaster.Does "ssh -A" or any other parameters copy the private key to a remote host?
>> I see the private key is never transfered, even if we use "ssh -A". > > Just the connection with the new host is started with the help of the original > ssh client where the private key is. Could you point me to source code, the > file or function which start such operation? >Sure, a lot of the client meat for ssh-agent stuff is in authfd.c. on the client: sshconnect2.c:pubkey_prepare opens the agent connection, and iterates the key list, sshconnect2.c:userauth_pubkey does client portion of exchange; and auth2-pubkey.c:userauth_pubkey does the server side. You could also look at my project, http://pamsshagentauth.sourceforge.net/, to see another example of the same type of exchange.
Jamie Beverly wrote:> Sure, a lot of the client meat for ssh-agent stuff is in authfd.c. on the > client: sshconnect2.c:pubkey_prepare opens the agent connection, and > iterates the key list, sshconnect2.c:userauth_pubkey does client portion of > exchange; and auth2-pubkey.c:userauth_pubkey does the server side. > > You could also look at my project, http://pamsshagentauth.sourceforge.net/, > to see another example of the same type of exchange.Thanks a lot Jamie