SSH good practice

Hi everyone !

TL ; DR : Is it ok to use the same password for 2 SSH keys on 2 different clients ?

I have a general question that isn’t specific to YunoHost, but to good security practise in general.

Let’s say I want to be able to access my server from 2 machine, my desktop and my laptop. On each of them, I create a key pair and upload each public key to my server.

When creating these pairs, I have to choose a password that, I guess, is used to encrypt the private key on the disk, so that someone who have access to my computer cannot just use the key.

Is it ok to use the same password to protect both keys on each machine, or should I use a specific password for each. I know reusing password is bad practise in general, and do use a password manager to have strong random passwords. But do I have to have 2 separate entries on my password manager for my 2 different machines, or can I have a general “ssh keys” password ?

Thanks for taking the time to read :grinning:

Sounds like you answered your question.

I use separate passwords in my password manager.

1 Like

I guess… But since it give access to the exact same ressource (since I upload the keys to the same server(s)), I thought it could be different. It is a very different situation than having two passwords for two completely different services.

But there could be other reason. I don’t know much about cryptography, and I wonder if giving multiples files encrypted by the same password makes it easier to figure out the password for example.

I doubt it does

Imho it boils down to the “security vs. practicality” tradeoff, or to put it another way : “is it worth the trouble to have 2 different passwords just in case an attacker ends up having full access to your computer somehow ?”

Or you could imagine a similar situation / question where somebody would wonder if it’s more secure to have one password manager for each life context (say : personal, work, hobbies, …). Sure it’s more secure, but is it really worth the trouble vs. the security gain it brings ?

2 Likes

I like your answer, but to be honest, it boils down to this :

making this kind of choice is taking resposability for it, and as someone that is completly self-taught in this kind of thing, I don’t have the confidence/legitimacy to make those kind of choices, because there could be something “obvious” I may be missing !

And always being on the side of “caution and security” is not a valid choice if it impair practicality as you explain. (For example I only recently understood that I don’t need ta have a seperate ssh key for each server I administrate. Before that I tried having a specific key pair for each client-server relationship. This was so impractical I quickly stopped and went back to ssh without a key pair, just passwords, with is a worst practise, I knew it.)

But I guess this is a problem that is not so much a technical one, but more a political/philosophical one :sweat_smile:

I would also like to highlight that this kind of stuff, in the grand scheme of things, doesn’t really matter (but hey it always depend on threat model anyway …)

Like, the probability that an attacker obtains access to your private key (something which you can mitigate by encrypting your hard drive) AND happens to know your private key password (because???) … that’s already two huge ifs … And you essentially think about this because you are “actively” in the process of creating your keys and wondering what’s the best practice etc. And you should be thumbed up for wondering about what’s the best practice

But imho people wondering about security should really think more about everything they’re not thinking about.

Like, people seem to be overthinking the whole SSH access thing, but in the meantime maybe you have some random unused app which is not up to date, or unused service (maybe XMPP?) or unused user account which turns out to have a stupidly simple password, or some UNIX permission allowing random user to access critical secrets … The probability that you get hacked because of something like this is imho much higher than an attacker gaining access to your private key AND your SSH key password AND you happen to be using the same password for all SSH keys …

3 Likes

Perfect example where the first choice (well, not a choice, you didn’t know) was not a good one, as it ended up in a situation that has a way worse security level, because it was too complicated (for this specific context).


I would say it mainly depends on the risk of being breached on each machine.
If one SSH key is on your phone for instance, and the other on your computer, then maybe you should give less trust to the phone environnement and have a different key with a different password (and a strong one). And maybe not the same access : if you end up with for instance direct root access on your computer, don’t give it to you phone, so you are partly protected by a second step.
Apart from that, I’m not sure it really matters compared to the whole set of other, easier possibilities of security trouble…

1 Like

Completly agree. But it takes time to build the confidence that you even have the right picture of what you do. A stupid exemple but some absolutetly new that does not know what the root user is. They think that the important account is “admin” for example, because the name is more explicit. So they do their best, and grab a strong password for their admin account and change their root password to “1234” because they never use it anyway.

To me this error is embarasingly obvious, but it is an obscure technicallity to 99% of the population.

Point is, you do not know when you are the obvious idiot of someone else.

Yes, as I understand it this seems to be the way I saw it. Even more, I cannot imagine how someone could happen to have specifficlly the password to Key n°1 and Key n°2, but not have either Key n°1 nor the password to Key n°2

On that particular issue, Yunohost does it the right way by preventing password root login by default.

1 Like

Yes but it’s not easy to do ^^ even with specific methodology.

1 Like

Yes, my point is that a false sense of security ain’t equal to security … People are too often thinking they’re secure because they’re using the latest top-notch cipherlist they found on a blog, and they use a 74521145bits SSH keys protected by a 8457 char long password, and they even disabled root login ! … like … nope

Well said!