7 ms·
Who still allows password-based login for any SSH account, root or not? Keys, certificates, or Kerberos for all users.
by tjohns 3y ago
Who still allows password-based login for any SSH account, root or not? Keys, certificates, or Kerberos for all users.
- banana_giraffe 3y agoYou'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.
- kenniskrag 3y agoSometimes the default after creating the VM. Sometimes it is, if you start in the recovery mode (usually with a random long password)
- Enginerrrd 3y agoI 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.
- rhaps0dy 3y ago> ... 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 That's why you use SSH agent forwarding https://docs.github.com/en/authentication/connecting-to-github-with-ssh/using-ssh-agent-forwarding https://docs.github.com/en/authentication/connecting-to-gith..., so you never need to copy the private keys to other computers, and thus they can't be stolen from there.
- megous 3y ago...May not be stolen, but may be abused from there via ssh-agent connection.
- duskwuff 3y agoOn 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.
- folmar 3y agoJust 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.
- rft 3y agoYou 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.
- ikiris 3y agoAll 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.
- sspiff 3y agoI do on my local network. Nothing that's on the Internet. I think it's still enabled by default on Fedora and Debian.