Using a public/private key pair is fairly convenient for logging in to frequented hosts, but if I'm using a key pair with no password, is that any safer (or less safe) than a password? The security around my private key file is paramount, but say my magical private key file was just a list of passwords to various hosts, is there a difference?
-
3Crackable bits of an ssh key is probably drastically higher than anything you would be using for a password.– KzqaiCommented May 17, 2011 at 16:24
-
3Why a key-pair with no password? Why not use a password on your private key, and use ssh-agent, for much better security and more convenience?– nealmcbCommented May 17, 2011 at 23:09
-
You may also look into using S/KEY authentication.– user10253Commented May 28, 2012 at 22:30
-
2See also security.stackexchange.com/questions/69407/…– MaxiWheatCommented May 10, 2016 at 13:51
-
the answer on security.stackexchange.com/questions/69407/… is a little more digestible IMO. But @john's answer is probably more comprehensive and should also be read for full understanding.– Trevor Boyd SmithCommented Jan 2, 2019 at 14:22
Add a comment
|
6 Answers
My answer is that using public key pairs is a much wiser thing to do than using passwords or lists of passwords. I will focus on things that are not widely known about different forms of SSH authentication, and I see no other answers mentioning them.
First of all, you must understand that user authentication is a different and separate process than the establishment of the secure channel. In laymans terms what this means is that first, the public key of the server is used (if accepted!) to construct the secure SSH channel, by enabling the negotiation of a symmetric key which will be used to protect the remaining session, enable channel confidentiality, integrity protection and server authentication.
After the channel is functional and secure, authentication of the user takes place. The two usual ways of doing that is by using a password or a public key pair. The password based authentication works as you can imagine: The client sends his password over the secure channel, the server verifies that this is indeed the password of the specific user and allows access. In the public key case, we have a very different situation. In this case, the server has the public key of the user stored. What happens next is that the server creates a random value (nonce), encrypts it with the public key and sends it to the user. If the user is who is supposed to be, he can decrypt the challenge and send it back to the server, who then confirms the identity of the user. It is the classic challenge-response model. (In SSHv2 something a bit different but conceptually close is actually used)
As you can imagine, in the first case the password is actually sent to the server (unless SSH would use password challenge response), in the second your private key never leaves the client. In the imaginary scenario that someone intercepts the SSH traffic, and is able to decrypt it (using a compromised server private key, or if you accept a wrong public key when connecting to the server) or has access to the server or client, your password will be known - with public-private key authentication and the challenge response model your private details will never fall in the hand of the attacker. So even if one server you connect to is compromised, other servers you use the same key for would not be!
There are other advantages of using a public key pair: The private key should not be stored in cleartext in your client pc as you suggest. This of course leaves the private key file open to compromise as an unencrypted password file would do, but it's easier to decrypt (on login) and use the private key. It should be stored encrypted, and need you to provide a usually long passphrase to decrypt it each time it is used.
Of course this means that you will have to provide the long passphrase each time you connect to a server, to unlock your private key – There are ways around that. You can increase the usability of the system by using an authentication agent: This is a piece of software that unlocks your keys for the current session, when you log in to gnome for example or when you first ssh into your client, so you can just type ssh remote-system-ip and log in, without providing a passphrase, and do that multiple times until you log out of your session.
So, to sum up, using public key pairs offers considerably more protection than using passwords or password lists which can be captured if the client, the server or the secure session is compromised. In the case of not using a passphrase (which shouldn't happen), still public key pairs offer protection against compromised sessions and servers.
-
My private keys can be decrypted automatically on Ubuntu, the passwords for them are encrypted with my login password, and Ubuntu unlocks them for me automatically when I log in. This is really the best of both worlds, because I have the convenience of a passwordless key with the security of a passphrased one (almost). If you are logging in to a high-security computer system, this might not be secure enough, since your login password can be compromised fairly easily, and thus the passphases for your keys can be compromised as well. However, it is much better than a key without a passphase.– crazy2beCommented May 18, 2011 at 0:08
-
1If "not using a passphrase isn't smart", then why does the OpenSSL documentation specifically say that "it may be a good thing to avoid protecting it with a password" ? (Should I ask this as an independent question?) Commented Aug 5, 2013 at 16:07
-
2Parts of this answer are a bit too detailed, and go astray as a result. The distinguishing feature of publickey authentication in this context is that the client signs something with his private key, and does not need to reveal a secret in the process. SSH-2 publickey authentication does not actually use a challenge-response protocol as described in this answer. The client signs a value which is derived independently by each side as part of the symmetric key-agreement process; see RFC-4252, section 7 (in particular the "session identifier"). Both sides contribute, and neither can determine it. Commented Aug 26, 2015 at 1:41
-
6The use of the session identifier in publickey authentication has an interesting effect not often remarked on: it affords extra protection against a man-in-the-middle attack. If the attacker executes the key exchange separately on each side, the session identifiers (IDs) will be different. The server demands a signature over the ID for its connection with the attacker -- but the client will only produce a signature over the ID on its side. The attacker has no way to force them to be the same, and no way to induce the client to do anything else. A challenge-response protocol would not do this. Commented Aug 26, 2015 at 1:52
-
@RichardE.Silverman Maybe you should suggest an edit. The poster is unlikely to edit himself considering that he hasn't been on this site for three years.– kasperdCommented Aug 28, 2015 at 21:13
Compared to a stored list of (long and random) passwords, a stored SSH private key offers the same security: things are safe as long as your private file remains private.
The private key, however, is much more convenient, both practically (right now, the SSH clients support it out-of-the-box, contrary to a custom file of passwords which you must use with some manual copy&paste) and theoretically (you can reuse the same key for each host you want to connect to, whereas a list of passwords will grow linearly with the number of contacted hosts, unless you reuse the same password for multiple hosts, which is bad).
answered May 17, 2011 at 14:27
-
9I fear that some readers will miss the implications of “long and random passwords”. A private key carries a lot more entropy than a realistic password (let's say at least 128 bits of entropy, assuming a decent RNG; a 10-ASCII-character password has about half that, a lot less if it's memorable). Also people reuse passwords a lot more often than private keys. So in practice there are security advantages to a private key. Commented May 17, 2011 at 16:59
-
@Gilles asymmetric keys like those used in SSH all have at least 1024 bits of entropy, not 128. However asymmetric encryption also requires more entropy. 1024 bit asymmetric is weaker than 128 bit symmetric encryption. When somebody tries to brute force an SSH server, they have to do it "slowly" to avoid creating a denial of service attack. This means a password with ~50 bits of entropy will take hundreds of millions of years to guess. Go any faster and the server will be blown off the internet for the duration of the attack, and the sysadmin is going to notice/investigate. Commented Feb 21, 2016 at 6:48
-
To effectively brute force a 10 character password you need hundreds of trillions of guesses per second, and it'll still take weeks. No server is capable of receiving anything remotely close to that many SSH login attempts. A few hundred attempts per second is more realistic, which is too slow to be effective unless the password is terrible. Anybody reading this website is smart enough to choose a good password. Commented Feb 21, 2016 at 6:50
-
2@AbhiBeckert I think you're confusing key size with entropy. Also, breaking the key or password isn't always have to be an online attack: the attacker may have access to the public key. In any case I think you missed my point altogether: the entropy in a key pair, barring bugs, is always far larger than any memorable passwords. Commented Feb 21, 2016 at 13:09
-
@Gilles and I think you're missing my point, which is that nobody should be using memorable passwords for a production server. Passwords should be full random numbers, encoded using characters that can be typed on a keyboard. Commented Feb 22, 2016 at 0:49
It depends on which threats you consider.
The main point of public/private key authentication is not to let your secret out, even to the party you're authenticating to. For this reason, using keys is better, as you never send your secret outsite your machine.
However, if the threat you consider is local, and if you don't protect your private keys with a password, storing a list of passwords in clear is about the same storing the private keys without protection.
For this reason, it's useful to protect your private keys with a password and use tools such as ssh-agent (for convenience). On OSX, this can also be integrated with the KeyChain, so that you may not even need to unlock the private key (at the application level, only at the security daemon level) to be able to use it via SSH (essentially, the KeyChain and security daemon take care of ssh-agent).
-
> The main point of public/private key authentication is not to let your secret out, even to the party you're authenticating to. For this reason, using keys is better, as you never send your secret outside your machine. Is challenge password authentication not supported by SSH? Commented Sep 22, 2011 at 15:40
-
Welcome to Security.SE. As you may have noticed, your answers are being downvoted by various members of the community. If you have a good read of the FAQ (link at the top of the page) you will get a better view of how to post in this community. You might also want to concentrate more on the newer questions rather than dig up old ones with highly voted, accepted answers.– Rory Alsop ♦Commented Sep 22, 2011 at 16:09
-
... further, your addition here as an answer would have been more appropriate to place as a comment. As to your clarifying question, SSH does not support password challenge auth.– Jeff Ferland ♦Commented Sep 22, 2011 at 16:13
The main difference between using a private key without password and using plain text password for SSH authorization is authorizing by something you have (your private key) or by something you know (your memorized password). They are different breed, but it's hard to say that one is ultimately better or more secure.
Authorizing by something you have is normally harder for the attacker to replicate out of the the blue - it's easier to brute-force/guess your simpler password than to replicate your key. But it has a major drawback - now keeping your private key really secret becomes paramount. If you use something only you know (memorized password), it should be easier to keep it that way (at least theoretically). But if you have to memorize it, then you probably use something not that complex.
So it's for you to decide, what's more probable - your strong private key being stolen or not so strong password guessed (or acquired in some other manner).
There's one exception here - if you mean in your question that you'll be storing really long, complex and random passwords in your secret file instead of using a private key, then there's probably little difference between the two still some difference (I've missed the part, see @john's answer for a nice writeup on this). In that case both are something you have, keep it secret types, but then ask yourself - why do it in the first place if that's what private keys were designed for? you should stay with private keys in that case.
answered May 17, 2011 at 15:12
-
7Note also that these two can be trivially combined by password-protecting the private key. Now you need something you know (the password) to get at something you have (the private key). Commented May 17, 2011 at 15:55
The referenced paper is discussing passwords typed within an ssh session; I think it, and Richard's comments, are worth keeping around, but no longer believe in the answer itself. (I still do prefer public keys.)
Song, Wagner, and Tian have shown that it is possible to speed up brute-force password searches roughly 50 times by using timing information from ssh sessions. Noack revisited their study and found SSH2 vulnerable to timing analysis as well.
The attack makes two assumptions:
- The password hash is available for brute-force cracking.
- An attacker can get accurate timestamps on packets sent between hosts, or otherwise acquiring timing information.
Public keys are not only more convenient, but more secure against certain threats.
-
This comment is misleading, and the writer may have misunderstood Song et al.'s work. It only applies if you type your password over an SSH connection, interactively: for example, if you use SSH to log into a remote host, then run a command with sudo so that you have to type your password for sudo authentication over the connection. When you do that, the inter-packet timings of your keystrokes as you type the password reveal information about the password. [cont'd…] Commented Aug 26, 2015 at 1:22
-
1The question, however, is not about "typing your password over SSH," but rather about "SSH password authentication," which is entirely unrelated. When you authenticate yourself via password to an SSH server (with either the "password" or "keyboard-interactive" userauth methods), you type your password locally -- not over SSH. The password is sent in a single packet to the server. The timing attack is irrelevant here. see: archive.oreilly.com/pub/a/linux/2001/11/08/ssh_keystroke.html Commented Aug 26, 2015 at 1:26
-
@RichardE.Silverman, thanks. I've edited my answer to reflect that I misread or misremembered the paper. (I can't recall now, it was ages ago.)– sarnoldCommented Aug 28, 2015 at 8:29
If you are using "software" keys (meaning keys stored in your .ssh directory or equivalent) you are basically on the same level as storing passwords.
OpenSSH now has almost decent PKCS#11 support, same is available in KiTTY(a PuTTY fork) thus for really making use of pubkey authentication, go for a smart card. Then there is real difference from passwords. A software keyfile, protected by a password, can be replicated the same way as a plain password, whereas a smart card can not.
-
2As the other answers note, there are lots of scenarios in which pk auth is a very effective protection, so you should at least clarify the threats scenarios you're addressing.– nealmcbCommented Jun 12, 2011 at 17:47
-
If your host is compromized by the adversary (other than lost/stolen, meaning you are hacked/rooted/keylogged etc) your private keys protected by a password are as good as simple plain passwords that get sniffed - both can be copied and used without your consent. Cloning a smart card on the other hand has proven to be "difficult enough" for mere mortals like us. Also, destroying a smart card usually destroys the private key, deleting a copy of a file you have does not mean that there are other copies "somewhere"– martinCommented Jun 14, 2011 at 8:08
-
1Sure. But you're ignoring the protection that even software pk auth gives you against losing your password to the remote host (for possible reuse on other hosts where you've reused it, as so many folks do), or to a MITM, as others have pointed out.– nealmcbCommented Jun 14, 2011 at 14:15
-
Maybe. But I hope I have drawn attention to issues with (only password protected) key based authentication as well.– martinCommented Jun 14, 2011 at 18:16