The people with PermitRootPassword=no are also the ones that’ll have weak default password. It’s probably actually saving the attackers time that allowing root password login and bad password choice occur together. If everyone with randomized high-entropy root passwords actually allowed root password logins that bruteforcers would have to spend so much more time!
I do. For some reason ssh keys became the group-think security advice to repeat ad nauseam. I often find people have only considered this very shallowly, and their reasoning is just "But OMG, entropy lolz" without actually seriously considering the available entropy and likely attack vectors and failure.
Why?
The benefits are largely theoretical if you choose sufficiently strong randomly generated passphrases, with some symbols and numbers mixed in, which I set my password manager to do. (Actually, I have a couple of super important, super long ones I keep only in my head.)
The draw-backs however are several:
1. I find that its not uncommon I find myself having to chain together ssh tunnels and other strange things to debug networking issues and need to login to another machine from a new machine that doesn't have the ssh-key. Treating servers as cattle exacerbates this issue since it's more likely to occur.
2. If a machine or server I use to manage stuff as a gateway/proxy/vpn entry to my network has all my ssh keys on it, and it becomes compromised because of some 0-day, the attacker now basically has access to... multiple entire networks. Now, this is technically true of my password manager as well, except that the context / IP addresses, etc, is not going to be as obvious as it will be on the server where the attacker can see the running services, check logs, command histories, etc. With the password-based management, sure I could get hit by a keylogger, but everything won't be compromised by default.
3. In my experience, you're more likely to lock yourself out than let an attacker in. You basically still have to have your keys managed via some type of password manager anyway because otherwise you run the risk of getting locked out of everything in case you're away from your primary machine and need to address some emergency or something.
Public key authentication isn’t just providing more entropy than passwords.
Passwords (as used in SSH) are bearer tokens – send yours to the wrong server, once, and you‘re compromised, for this and future sessions. That’s not the case with public key authentication.
> ... need to login to another machine from a new machine that doesn't have the ssh-key.
> gateway/proxy/vpn entry to my network has all my ssh keys on it, and it becomes compromised because of some 0-day, the attacker now basically has access to... multiple entire networks
On the other hand, SSH agent forwarding means exposing your SSH agent to the bastion host. If that gets compromised, an attacker may be able to move laterally to other systems your personal computer had SSH keys for.
You can also use ProxyJump to let SSH handle setting up tunnels for you. It logs into each hop via the tunnel(s), no need to forward your keys. Great thing is, once your ssh config is properly setup you don't care how convoluted the tunnel setup is; ProxyJump will connect to jump hosts via other jump hosts.
Just use `ssh-add -c` and confirm each use. If you have _really_ old ssh (which is probably insecure anyway) using gpg-agent as ssh-agent had this feature a few year earlier, but we are talking archeology here.
All of your items are just "i'm doing this wrong" combined with not understanding how keys even work.
Your private keys shouldn't even be accessible to you, they should be on a secure enclave like a yubikey, and you should forward the token along the chains. No risks, and basically painless, especially if you switch to certs so you don't even have to know the public keys ahead of time on the servers, just all trust the same private PKI.
> Your private keys shouldn't even be accessible to you, they should be on a secure enclave like a yubikey
That’s not the only reason or way to use SSH keys. Even when stored on disk (in plaintext or encrypted) they offer advantages over password authentication, e.g. making it impossible for an MITM to steal credentials or impersonate an authenticated client even without validating host keys.
You'd think, but yet one still sees one or two posts a week to SO or whatever forum asking how to enable password-based login to AWS EC2 instances. Often with screenshots showing '0.0.0.0/0' as the allowed incoming range.
Even if you disallow root login with a password, the user can still try to log in, and the attempt still gets logged
If you're asking why it would ever be worth it, there's always valuable stuff online with incompetent configuration. I don't know if shodan is still up, but I remember going on there in high school and getting access to random webcams (sometimes in peoples' homes)
This is a pretty excessive amount of SSH brute force but it honestly doesn't seem as bad as some of the cloud machines I run. There are always like at least 3 different IPs going relentlessly hard 24/7/365.
