Generally speaking, you’re right, but I have servers I want to be able to access from anywhere, because I support some app running on them. Until 1password agent setup, having keys only and password disabled was too difficult, and yet, also unnecessary.
Zero day ssh bug? I’m not NSA, how often does this happen to random servers?? Again, never have been hacked in more than 20 years. Still support some servers with ~6 year uptime.
Ah yes, the "I've never been hacked so I must be secure" argument ;)
Unfortunately, you're not convincing anyone. Amongst the security conscious, multi-year uptimes are the opposite of a brag. And it doesn't matter how you spin it, key-based auth is best practice, as is reducing your attack surface.
It seems that some of these measures are too difficult for you, and that's fine. But trying to argue that the measures are pointless is just false.
I’m not trying to convince anyone, I’m trying to understand what drives sone security focused people to make things more complicated and harder without practical justification.
So, are you NSA? How many servers have you lost to the password attack vector?
For the record, and whatever worth - it is the (it seems, serious) conviction of here folks (and I concur) that the NSA is at least a reader of these threads.-
Yeah, it might read like that, but it also is how I feel. If I was running a crypto farm, or if I was doing security research, I would have different levels of concerns.
But, in fact, hosting a competitive gsmijg website, I did experience common brute force and and other types of attacks, but fail2ban did foil them for years :)
None of the attackers were ever sophisticated enough to come up with a successful attack (that I know of :))
The point is, should everything be do all the best practices as if they were equally likely to be attacked?
It’s like saying that everyone should also have a faraday cage house, and electrified fences, it is the best practice, after all.
Every large- or medium-sized multi-user server disables passwords for SSH login, because they're worried about things like password stuffing - and because they know password reuse is unavoidable when you've got even a small fleet of servers.
At the same time for most users certificate-based login is easy (no need to enter a password every time) and they've already got it set up, because github and AWS work that way.
OK, let's assume SSH is configured to accept one 30-character random password as an escape hatch. All normal auth is done using pre-shared keys. What are the risks, from your point of view?
From my POV, the principal risk is opsec mishaps, which may lead to leaking a public key or a password alike.
One difference is that MitM attacks can capture your password, thereby giving persistent access to at least that system (more, if you reuse passwords).
With public keys, this is not possible. The worst case of credential theft from MitM would be hijacking a forwarded SSH agent, which would require a deliberate (and highly discouraged) client configuration.
I feel like syncing a password-protected private key for break-glass use would be better than syncing a password database (given the same master password, key-stretching, and syncing strategy...or even just encoding your private key in a "secure note" field instead).
SSH is always using public keys even when you use password authentication. Your SSH client knows the host the key. If you're not connecting to the right host, you are informed.
I know that, but "public keys" is long enough on mobile without typing "public user-authentication keys."
Anyway, I think it is reasonable to assume that if you're using the "escape hatch" as mentioned by /u/nine_k, you may well not have your .ssh/known_hosts file on your client. In which case public user-authentication keys minimizes your blast radius of a MitM host.
Also, a compromised (but legitimate) host could still grab your password and try lateral movement (mitigated if you don't reuse your break-glass password, but you get it for free with public keys).
And yet syncing an encrypted private key is still easier and more secure than syncing (via the same mechanism e.g. Keepass) a 30-character random password.
You don't need a 30 character random password for SSH to your machine; that's a strawman.
The attackers are not cracking a password hash with GPUs; they are just connecting and guessing.
People who use passwords with SSH of course use passwords they can remember and type.
If the attackers are trying to brute-force your password by attacking the hash, that means the machine was already compromised. The password then has no value, unless you're re-using it for other machines.
The user who thinks they need a 30 character random password for SSH (if they were to use one) will of course opt for keys instead.
I see user nine_k introduced that. It's still a strawman; nobody needs 30 random characters for a SSH password (except in some circumstances in which a key would obviously be better).
Let's assume I have an uncommon user name (not root or www-data, ...) and not anything from my domain name or e-mail address or whatever, and a nine character password made of lower case characters and digits, reasonably easy to remember.
Well great, so I'm addressing nine_k and his question/scenario. As I have been this entire time. And it sounds like you're _agreeing_ that a 30-character random password makes no sense, and a key is easier and better. No?
Regarding _your_ scenario, cool bro, do whatever you want. However, if you reuse that password for any other servers, you're open to lateral movement attacks, which keys mitigate.
Actually I guess that's my main argument: you can mitigate the downsides of passwords, but keys are super simple, well-supported, and require no such fussiness. Just generate it, set a password, authorize it, forget it. Threats mitigated. If you want to futz about with workarounds, be my guest. I have no such desire.
Anything is better than a 30 character password, including quitting computing and just doing vegetable farming on a tiny island, completely off every grid.
BTW, that remark I made about known_hosts applies to keys. You could put your SSH client keys (I mean private ones) on some HTTPS URL, so that you could fetch them to a brand new machine (e.g. burner phone purchased abroad).
And that's back to passwords: anyone else knowing that URL could fetch those keys, and their security depends on their password phrase. So we are back to relying on the strength of a password phrase as well as faith in attackers not knowing anything about such an URL.
Oh right; the URL could be .htpasswd protected too, let's not forget. :)
Re: hosting your key, I think that's quite reasonable, again, assuming your access control + encryption is good. It's a solid break-glass solution. I would add monitoring that alerts if it is ever used, though. Then you can remediate quickly on the off-chance it is compromised. In day-to-day use I would stick with a different key that only lives on my machine.
That's access control and transport encryption. By encryption I meant the encryption of the private key itself. I would not upload a plaintext private key, especially for privileged account access, even to a server I control.
A strawman indeed. 30 characters is deliberate overkill.
So, thank you for confirming my understanding: keys are just as / more convenient from the ops standpoint than passwords. The weakness is only in short, guessable passwords.
Short, guessable passwords are another strawman. There are short passwords which are unguessable. Those passwords are crackable from their hash, which is different from guessable.
Zero day ssh bug? I’m not NSA, how often does this happen to random servers?? Again, never have been hacked in more than 20 years. Still support some servers with ~6 year uptime.