3 ms·

Sure, I don't think we actually disagree too much. Leaving password auth on is simply negligent. That said, blocking all countries that you don't expect to ta

Sure, I don't think we actually disagree too much. Leaving password auth on is simply negligent. That said, blocking all countries that you don't expect to talk to is the world's second easiest security fix, and protects other processes you might have running, and other unknown vectors that might be worse, such as heartbleed.

traceroute66 5y ago
> That said, blocking all countries that you don't expect to talk to All fun and games until you find yourself on travelling in Asia and you need to connect back home and forgot you blocked half the world. As for "other processes", we're talking about SSH on this thread. If you've got other processes then that falls into on-host/upstream filtering via firewall area of security. Regarding "unknown vectors", as I said, patching, no amount of IP blocking will help you with that. If you really want to talk about "world's second easiest security fix" for SSH, that would be running a super-hardened bastion host and using SSH ProxyJump.
- kijin 5y ago
  > All fun and games until you find yourself on travelling in Asia Leave a cheap droplet running somewhere, whitelist its IP, and SSH through it. I'm in Asia and I do exactly that with my U.S.-based servers. Actually, I've blocked all of the rest of the world as well, except the proxy droplet. It's like a global bastion host. There's no legitimate reason for anyone else on this planet to try and SSH into those boxes.
Enginerrrd 5y ago
>Leaving password auth on is simply negligent I know this is an oft-repeated trope, but I disagree. If you are whitelisting users for ssh and use secure passwords, you're really quite safe. Whereas if you lose access to your device with ssh keys, you're locked out with no hope of getting back in. In what sense is it "negligent"? I feel like this is just an example of people constantly repeating popular advice without really considering it, like happened with bad password expiration policies. Like, I get that an ssh key probably has more entropy, but there is such a thing as good enough. My ssh password for my server is mixed case with numbers, and 20+ characters. Good luck cracking it.
- anjbe 5y ago
  I’ve seen a compromised machine whose sshd had been replaced with a trojan that saved all passwords entered into it. Some investigation revealed that sshd modification to be part of a standard script kiddie toolkit. Are you 100% sure that every machine you log into remotely with your very strong password isn’t logging that password? That’s one advantage of keys.
  - Enginerrrd 5y ago
    Perhaps I'm missing something? I don't understand the issue. If the machine you're logging into (running sshd) is already compromised, it's... already compromised. I don't recycle passwords, so what is the risk? And if the device on which you're running your ssh client is already compromised, it doesn't matter whether you use a key or password, its the same thing. Can you explain the threat a bit more?
    - traceroute66 5y ago
      > And if the device on which you're running your ssh client is already compromised, it doesn't matter whether you use a key or password, its the same thing. Whoa there sunshine. Put your SSH keys on a USB HSM (Yubikey or Nitrokey) and nobody is ever going to be able to extract the private key. Added bonus, put it on a USB HSM with touch auth (e.g. Yubikey) and nobody will ever be able to use the key without you knowing it (because you have to physically touch it).
      - Enginerrrd 5y ago
        >Put your SSH keys on a USB HSM (Yubikey or Nitrokey) and nobody is ever going to be able to extract the private key. Except you. To run through a compromised machine... Perhaps I don't quite understand how it works, but I don't see how this setup negates that issue. Once you plug it into the compromised machine and allow access to it with whatever touch-authentication or w/e, I can't imagine you could keep it secret from the attacker on the compromised machine. But maybe it's encrypting the key on the device?

traceroute66 5y ago

> That said, blocking all countries that you don't expect to talk to All fun and games until you find yourself on travelling in Asia and you need to connect back home and forgot you blocked half the world. As for "other processes", we're talking about SSH on this thread. If you've got other processes then that falls into on-host/upstream filtering via firewall area of security. Regarding "unknown vectors", as I said, patching, no amount of IP blocking will help you with that. If you really want to talk about "world's second easiest security fix" for SSH, that would be running a super-hardened bastion host and using SSH ProxyJump.

kijin 5y ago
> All fun and games until you find yourself on travelling in Asia Leave a cheap droplet running somewhere, whitelist its IP, and SSH through it. I'm in Asia and I do exactly that with my U.S.-based servers. Actually, I've blocked all of the rest of the world as well, except the proxy droplet. It's like a global bastion host. There's no legitimate reason for anyone else on this planet to try and SSH into those boxes.

Enginerrrd 5y ago

>Leaving password auth on is simply negligent I know this is an oft-repeated trope, but I disagree. If you are whitelisting users for ssh and use secure passwords, you're really quite safe. Whereas if you lose access to your device with ssh keys, you're locked out with no hope of getting back in. In what sense is it "negligent"? I feel like this is just an example of people constantly repeating popular advice without really considering it, like happened with bad password expiration policies. Like, I get that an ssh key probably has more entropy, but there is such a thing as good enough. My ssh password for my server is mixed case with numbers, and 20+ characters. Good luck cracking it.

anjbe 5y ago
I’ve seen a compromised machine whose sshd had been replaced with a trojan that saved all passwords entered into it. Some investigation revealed that sshd modification to be part of a standard script kiddie toolkit. Are you 100% sure that every machine you log into remotely with your very strong password isn’t logging that password? That’s one advantage of keys.
- Enginerrrd 5y ago
  Perhaps I'm missing something? I don't understand the issue. If the machine you're logging into (running sshd) is already compromised, it's... already compromised. I don't recycle passwords, so what is the risk? And if the device on which you're running your ssh client is already compromised, it doesn't matter whether you use a key or password, its the same thing. Can you explain the threat a bit more?
  - traceroute66 5y ago
    > And if the device on which you're running your ssh client is already compromised, it doesn't matter whether you use a key or password, its the same thing. Whoa there sunshine. Put your SSH keys on a USB HSM (Yubikey or Nitrokey) and nobody is ever going to be able to extract the private key. Added bonus, put it on a USB HSM with touch auth (e.g. Yubikey) and nobody will ever be able to use the key without you knowing it (because you have to physically touch it).
    - Enginerrrd 5y ago
      >Put your SSH keys on a USB HSM (Yubikey or Nitrokey) and nobody is ever going to be able to extract the private key. Except you. To run through a compromised machine... Perhaps I don't quite understand how it works, but I don't see how this setup negates that issue. Once you plug it into the compromised machine and allow access to it with whatever touch-authentication or w/e, I can't imagine you could keep it secret from the attacker on the compromised machine. But maybe it's encrypting the key on the device?