Is it OK to use the same password for a Linux login and the SSH private key?

Question

I want to remotely log in to my Linux server with SSH. Public/private key authentication is more secure than password authentication, so I have disabled password-based authentication for SSH on my Linux server.

Now I still need to provide a passphrase to unlock my SSH private key. To save me having to memorize yet another password, can I use the same one on the SSH private key and on the Linux server login?

In my case, the client is Windows 7 on a TrueCrypt volume. Please indicate whether this is important to your answer.

Answer 1

Summary: using the same password for different things is a generally bad idea. However, in this case, where the two uses of the password control access to the same asset, it's not too bad.

---

So if someone can eavesdrop when you unlock your ssh key (for example by looking over your shoulder, or if they've managed to install a keylogger), they'll know your password on your server. If the only way to log in on that server is to have physical access or through ssh (which has passwords disabled), then having your password compromised doesn't matter.

That is, assuming that your password is only a login password. In fact, it is pretty common that your password doubles as an authentication token to become root through sudo. If that's the case, then an attacker who obtains your ssh key file's password as well as the key file can immediately escalate his access to the root account. If you're the only administrator on the server, it doesn't matter much, because the attacker can inject malware into your account that will let him piggyback on the next time you become root. If there are other administrators (or other ways for you to access the root account, such as a remote administration panel), this removes an opportunity for your colleagues to disable your compromised account.

Conversely, if someone can find out your password on your server, they can unlock your ssh key file. That's not a concern if you only use that ssh key file (or more generally that password) to access that one server. But if you use the same ssh key for other servers, then the attacker can gain access to these other servers given your key file and that server's password. This only represents a gain if you aren't using that same password on the other servers.

All in all, using the same password won't make much difference in typical situations other than a multiple-administrator server where you can sudo to root.

---

Public/private key authentication is more secure than password authentication

That's a bit simplistic. Public key authentication uses two factors (the key file and the password to the key file); this is good in that it takes more work for the attacker to compromise both factors. However, you also need to take the risk of a compromise into account. For example, for an ssh key, an active attack on the client will reveal both factors. If the attacker obtains a copy of the key file, he can try to brute force the password offline, so password protection on a key file requires a strong password, stronger than a password that can only be brute-forced through online attacks (though note that an online-only password can be brute-forced offline in some circumstances, for example if the attacker gets hold of a system backup).

Using a password for ssh is not wrong per se, if you can guarantee that it's unguessable. Typical users are bad at choosing unguessable passwords, that aren't a simple variation on their birthday or their girlfriend's name. If you have a good password (randomly generated with an amount of entropy that you can evaluate and that satisfies you), it's ok to enable password authentication if you don't type your password in a place where it'll be eavesdropped.

So if your login password is only a login password, you might combine an ssh public key for convenience and resistance to shoulder surfing, with a strong password that you don't remember keep in a safe and can use in private in emergencies (such as the loss of your client machine and difficulty to access its backups quickly). If your login password doubles as a sudo password, you will need to remember it.

If you only ever keep the key file on an encrypted volume (that only you can access), you don't need to encrypt the key at all. Remember to encrypt backups too.

Answer 2

Answering the question you asked. Re-using the same passphrase for both of these purposes is reasonable, given that you control both the Linux server (where it's used as a login password) and the Windows client (where it is used to unlock the SSH private key), and assuming that you keep both machines relatively secure.

The purists will say that you should never reuse a password. In theory, this is fine advice. But it fails to take into account the tradeoffs, and it fails to account human nature. We're human; our ability to memorize complex, meaningless passwords is limited. It's one thing to memorize a single passphrase that is long and strong. It is harder to memorize two -- and impossible to memorize 100. If we took the advice to "never reuse a password" seriously, then we'd need to have dozens, possibly hundreds, of passwords -- and, given human nature, the consequence would be that each of those passwords would be inevitably be weaker. They might all be short, or predictable, or slight variations on the same phrase. And that is arguably a worse situation than picking a single very strong passphrase and re-using it in this scenario.

So, if you can find a way to memorize them two different passphrases without compromising on their strength, that's the safest course. If you can write them down somewhere where noone else will have access (maybe on a slip of paper in your wallet?), that's perfectly reasonable.

But if you find yourself unable to memorize two long and strong passphrases -- if you find yourself dumbing down the passphrases, so you can remember both of them -- it is not unreasonable, in my opinion, to use the same passphrase for both purposes. It does open up some risks. For instance, if someone breaks into your Linux server and cracks the password hashes, then breaks into your Windows client and steals an encrypted copy of your private key, they'll be able to decrypt it. Or, if they get a keylogger onto your Windows client and are able to record your SSH passphrase, they'll be able to break into your SSH server. However, those risks may be acceptable, in exchange for having a strong passphrase.

An even better answer. However, I think there's an even better answer that you may not have recognized yet. If you're using SSH to log into your Linux server, you don't need a password for your Linux server! You can add your SSH public key to your ~/.ssh/authorized_keys file, and then log in using public key authentication. At that point, you don't need a password for logging into the Linux server. Now you only have one passphrase you need to remember: the one to unlock your SSH passphrase.

Personally, I think this is the best answer of all. SSH public-key authentication is more secure than password-based authentication. So, this is my recommendation.

(OK, OK, you might need to have a password for your Linux server's root account and other accounts after all. But I suggest you choose a very long and random one, one that you will never attempt to memorize, and then write it down, seal it in an envelope, and store it somewhere safe. You'll never use that password. It exists only as a backup, in case you get locked out of the server. Since you never plan to use it in ordinary use, it doesn't need to be memorizable, it can be as long and strong as you like, and it can be totally different from all the passphrases you regularly use.)

Answer 3

The attack vectors are different. Local attacks have no auto-lockout, logging, reporting or delay. Because a key will be attacked locally, a key needs to be protected with a more complex password.

I use KeePass to store my passphrases, a single, long, difficult password to protect KeePass, and a different single, long, difficult password for my TrueCrypt volume.

I encrypt my private keys to protect against people obtaining the key database over the network. TrueCrypt only protects my drive against physical access.

Sharing passwords is a bad habit.

Answer 4

If you have admin privileges on target server, then it IS risky to re-use login password for key passphrase. Now, depending on the strength of passphrase/password, the risk due to re-use may be small and worth the benefit, but there is added risk.

Successful system intrusion includes both login AND root access. By keeping the private key passphrase separate from sys password, you reduce the risk of an intruder doing further damage if he/she happens to get into the system via stolen private key.

Keep in mind, even if you use identical passphrase/password, passphrase is more vulnerable than system password, simply because they can be attacked OFFLINE. By cracking your private key that uses sys passwords, attackers would also have admin privileges to the target server. With a stolen private key, the attackers have time and privacy on their side.

On the other hand, login with a private key without re-use of sys password would still leave the intruder needing to attack sys password from WITHIN the target server. And brute-force or even dictionary attack of system password/login can be detected, provided the monitoring tools are deployed.