New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
SSH login: Keys vs Password
Assuming a really strong password is used, are keys really more secure than passwords for SSH login?
I have always used keys because it's more convenient but I was just wondering how keys are more secure as compared to an extremely strong password (say, 24 characters long comprising of multiple symbols, uppercase+lowercase alphabets and numbers all mixed up randomly)?
Comments
"No matter how long or complex a password is, it can never equate with the cryptographic strength that SSH public key offers."
https://runcloud.io/blog/ssh-public-key-authentication
It's not impossible.
It just takes 19 billion trillion trillion years to crack it
Yes.
Password: something you know
Keys: something you know (assuming you're not using passwordless) + something you have
Passwords are single-factor. Keys are two-factor.
The default ssh key size is 3072 bits. Assuming your password truly is 100% random (and i.e. has 8 bit entropy per character), then a 24 character password has 192 bits of entropy.
However, you are unlikely to remember 24 truly random ASCII characters. Usually there is some kind of logic to passwords, which further reduces entropy.
The benefit of public-key cryptography for authentication is that your private key never leaves your machine and can't be derived from the public key which is stored on the server. A password is a shared secret that both the server and the client have to know by necessity. Keys make it easy to give multiple users access to the server, each with their own key. It is easy to revoke access from one user without affecting other users' access.
Summed up perfectly.
It is not bad to use passwords. It is an option in software after all. Just use long and complex. But for better sleep just ED25519 and that’s it.
Summed up falsely, 385 random ASCII characters have more "cryptographic strength" (whatever that's supposed to be) than a 3072-bit ssh key.
The whole article reads like ChatGPT bs.
Fucking lol.
Only if you do not understand the term cryptographic strength. SSH keys are not just a "password", it's an asymmetric encryption. To be able to authenticate you have to match the public key and be in possession of the private key. It is actually kind of a 2FA, so it can never be compared to just typing in characters as a password, no matter how many.
Google "Diffie Hellman key exchange", it's like the first thing you really need to understand about ssh keys.
Mentally strong individuals do not worry about such things.
They add their own fixed IP address under etc/hosts.allow and easily access it.
I'll also throw them in the firewall rules for an "extra layer of protection"
EDIT: Oh, don't forget
sshd: ALLinhosts.denySee my response to the OP regarding public-key cryptography.
Public-key cryptography is not 2FA.
You seem to not understand public-key cryptography. You don't need to "match" the public key. The client doesn't need the public key whatsoever. The client authenticates to the server by proving that it possesses the private key, which the server verifies using the public key.
Diffie Hellman is a key exchange scheme used to negotiate keys that are not preshared, like they are with ssh. It is not needed for public-key authentication. You have no idea what you're talking about.
If keys is painful to use for some people so 30-45 characters password is great 😂
From man sshd(8):
For protocol 2, forward security is provided through a **Diffie-Hellman key agreement**. This key agreement results in a shared session key. The rest of the session is encrypted using a symmetric cipher, currently 128-bit AES, Blowfish, 3DES, CAST128, Arcfour, 192-bit AES, or 256-bit AES. The client selects the encryption algorithm to use from those offered by the server. Additionally, session integrity is provided through a cryptographic message authentication code (hmac-md5, hmac-sha1, umac-64 or hmac-ripemd160). Finally, the server and the client enter an authentication dialog. The client tries to authenticate itself using host-based authentication, public key authentication, challenge-response authentication, or password authentication.Yes, you can search, but you can't read apparently or don't understand those words you just quoted.
Diffie Hellman is used to negotiate encryption keys for transit encryption, regardless of authentication method used. Asymmetric cryptography has nothing to do with Diffie Hellman, and by extension neither does public-key authentication.
Regarding your "public key match" bit. You can validate that easily,
mv .ssh/id_rsa.pub .ssh/id_rsa.pub.bakandssh i_dont_understand_cryptographyCheers
One thing that should be mentioned - password-based authentication is vulnerable to hosting-provider database leak (if it was not changed by a client obviously) unlike public key authentication. I consider it as a major advantage.
I said it was the first thing to know about key exchange. You seriously want to challenge me on that? It is the first thing that happens when a client connects to a server, if you want to understand ssh connections that is where you start.
The public key to match is on the server, not on the client. The client uses its private key.
I don't know if this is a language thing, am I not saying this right (I'm not a native English speaker)? It's either that or you are deliberately misunderstanding everything I say, maybe you just like being an asshole.
In addition if that private key is stored (one way) in a crypto card, e.g. PIV ID card, OpenPGP card, YubiKey, then it can't be exfiltrated by a keylogger or malware even on a compromised PC, though obviously any active sessions opened would be vulnerable to misuse. Same is definitely not true of a plain password no matter how long it is.
You literally said "To be able to authenticate you have to match the public key and be in possession of the private key".
Perhaps I'm being a bit of an asshole, but only because you were being one in your initial reply to me, while being blatantly false.
You said Diffie Hellman is "the first thing you really need to understand about ssh keys". Diffie Hellman has nothing to do with ssh keys. Diffie Hellman is used even if your ssh server is completely open with no password or key. Diffie Hellman is used by TLS/HTTPS and most other encrypted communication to securely negotiate a shared encryption key over an insecure channel. That's all it does.
Stop trying to wiggle yourself out of this. You were simply wrong and I doubt it's a language barrier issue. I wouldn't have cared about you being wrong if you hadn't been so rude in your reply to my post.
Of course keys are stronger...
If you have to compare the two, look at the length of your password compared to the length of your private key.
The other advantage, and the one that I like the most, is you can (usually) turn off password authentication in the SSH server, it disconnects the connection before the Password: prompt even appears.
There is one OS I have/use/configure that one can't turn off the password authentication, but it won't allow a password if a public key is set though. Can't stop the logging either, but that is a different issue.
Stops the bot activity when they don't get the opportunity to even enter a password.
The other big advantage is that if you need external support, I can post my public key and no security is lost, for you to add it to the root account of a system. I don't need/use the password. Most of the systems I setup don't even have a root password anymore.
If it matters, I have SSH open to the world.. If I can't connect to the VPN, I can use SSH to log into the system to fix the VPN. As long as SSHd hasn't been f**cked with, I consider it secure (Juniper hardcoding a root password for example).
That is exactly what I said!
Can someone please confirm that I speak english, what the hell am I doing wrong here???
If I came of as rude I apologize. Call it language barrier, tired or maybe just lack of social skills, I swear it was never my intention to be rude. I was actually trying to be helpful, believe it or not. If I in any way offended you, it was not my intention.
I do not know what I have said that was wrong. I know how ssh works, I've been in this business for 30 years. But seriously, you twist everything I say into something that I have never meant to say! If it's not language you have to be doing it on purpose, there is no way someone that clearly understands what I'm talking about can misinterpret exactly everything I say.
This XKCD is mandatory whenever people get this deep into discussing the strength of crypto protocols.
$5 wrenches destroying advanced cryptography since the 1400s
Wikipedia:
"Wrenches and applications using wrenches or devices that needed wrenches, such as pipe clamps and suits of armor, have been noted by historians as far back as the 15th century."
+1 to @AndrewL64 for attention to detail
Why would someone ever use a default password though? Any default passwords should be changed as soon as possible. Good hosting providers generally let you provide an SSH public key instead of using a default password.
In any case, I wouldn't really trust system images because of things like https://lowendtalk.com/discussion/169685/vulnerability-in-solusvm-debian-10-template-debianuser-backdoor-default-user/p1, and always install from ISO using an ISO I've uploaded myself.
Most of LowEndTalk members are advanced users. Recently we got a client, supposedly less advanced than usually, who asked us why don't we store the virtual machine root password and show it to the client in a control panel like another hoster does.
This makes sense. Passwords must be visible. Because not everyone uses keys
I believe that the passwords are a secret at the first place. It is cusromers' data which must not be shared with a 3rd party like hosting-provider. There are way more secure ways to gain similar convenience level.
Oh... Oh no.
Sometimes I wonder if VPSes need a basic proficiency test before using them. Learn locally in a safe environment before going onto the internet. There's way too many insecure servers being used in botnets
Requiring a public key and turning off password authenication would provide a basic proficiency test
I use both keys and passwords. I use keys for convenience. But I also use passwords (sufficiently random), some of which I've memorized, for disaster recovery. If I need start fresh on a new system with nothing but my memory, I can recover.
I use hardware keys so I don't need to remember them and they won't/can't be compromised.
New fresh/clean system, import my public key and good to go.