4 ms·

To secure SSH, the more I care about a system the farther down this list I go. 1. Disable root 2. Use keys, disable passwords 3. Install fail2ban 4. Re

To secure SSH, the more I care about a system the farther down this list I go. 1. Disable root 2. Use keys, disable passwords 3. Install fail2ban 4. Restrict incoming subnets 5. MathAuthTries = 1 6. Run on high random port 7. Use port knocking

steckerbrett 11y ago
If your threat model has someone stealing your private key and breaking/obtaining the password to it, none of the other measures are going to mean anything as they have root on your box. With root they can bypass the access restrictions, knocking, whatever else. 2FA with an external device would probably make more sense than any of them and be significantly less irritating.
- emidln 11y ago
  That assumes that stealing your private key is the same thing as sending arbitrary packets from your machine, otherwise things like restricting subnets/ip addresses and port knocking could still be useful layers. How different exfil of a private key from being able to send arbitrary packets on the user's machine is...probably not that different under most circumstances I'd guess.
- voidlogic 11y ago
  I'd recommend encrypting your private keys if needed with a pass-phrase. I'd also recommend still requiring a sudo password on the other end and sending auth events to a auditing server. 2 factor with a token is ideal, I suppose I should have added that to the list, but that is outside of feasibility for most users. Still, for someone who doesn't have RSA tokens etc available, assuming your remote machine doesn't get owned and someone doesn't extract your pass-phrase with a wrench, that list makes for a very secure system.
  - cbsmith 11y ago
    > I'd also recommend still requiring a sudo password on the other end and sending auth events to a auditing server. You should be auditing everything already, and adding in sudo now adds another attack vector. You also now have two different accounts that can be manipulated to compromise a system.
- lambda 11y ago
  > they have root on your box Or they have your discarded dead drive from your backup disk that you forgot to enable full disk encryption on. Or they rooted a machine that you were using "ssh -A" on to forward your agent, and have been able to temporarily hijack your SSH agent session. Or there's an information disclosure vulnerability in your web browser that allows them to read files from your hard drive, though without control of what files they can read, and by chance the attacker got lucky and one of the files was .ssh/id_rsa. While the above description goes way further than I probably would, and yeah, 2FA would be more reasonable, there are good reasons to practice defense in depth, and try to design systems that have a chance of staying secure even if one of your assumptions fails like "private key is compromised".
- cbsmith 11y ago
  If your threat model is someone stealing and cracking your private key, you really ought to be more worried that they are going to use their time machine to go back in time and kill your mother.
  - steckerbrett 11y ago
    Both actions happen at the same time, someone phishes you, captures your input and they have the password for it as well. Now that they've got a shell on your box IP address restrictions are bypassed as well, as is port knocking. This is completely plausible, time machines are not. I read a (private) incident report very recently where half a company had their devices spear phished in order to gain access to a single internal server.
    - cbsmith 11y ago
      Oh, someone capturing your private key's passphrase is something to be genuinely worried about. Someone brute forcing said passphrase? Yeah no.
moe 11y ago
1. Disable root This doesn't add any security, it only makes your admin life miserable.
- cbsmith 11y ago
  I keep trying to explain to people that if anything this adds complexity to the security problem...
  - hackmiester 11y ago
    Can you explain this to me? We do it at work for accountability purposes, but I'm not sure I'm clear on the security implications.
    - cbsmith 11y ago
      From an accountability standpoint, if each person logs in to the root account directly with a distinct private/public key, you can still have full individual accountability. I'd think the complexity side of the sudo strategy is self-evident, so perhaps I'm not understanding the part that needs explaining.
      - hackmiester 11y ago
        I don't find 'sudo' to be complex at all. If in your situation I would have had the ability to log in as root, in my situation I will be in the 'wheel' group. It seems very straightforward to me.
        cbsmith 11y ago
        I think you misunderstand my point. You have increased the complexity of securing the system. You now have each user's login shells, all of the joys of what those login shells touch, the sudo program and its configuration, all added to the attack surface.
    - moe 11y ago

steckerbrett 11y ago

If your threat model has someone stealing your private key and breaking/obtaining the password to it, none of the other measures are going to mean anything as they have root on your box. With root they can bypass the access restrictions, knocking, whatever else. 2FA with an external device would probably make more sense than any of them and be significantly less irritating.

emidln 11y ago
That assumes that stealing your private key is the same thing as sending arbitrary packets from your machine, otherwise things like restricting subnets/ip addresses and port knocking could still be useful layers. How different exfil of a private key from being able to send arbitrary packets on the user's machine is...probably not that different under most circumstances I'd guess.
voidlogic 11y ago
I'd recommend encrypting your private keys if needed with a pass-phrase. I'd also recommend still requiring a sudo password on the other end and sending auth events to a auditing server. 2 factor with a token is ideal, I suppose I should have added that to the list, but that is outside of feasibility for most users. Still, for someone who doesn't have RSA tokens etc available, assuming your remote machine doesn't get owned and someone doesn't extract your pass-phrase with a wrench, that list makes for a very secure system.
- cbsmith 11y ago
  > I'd also recommend still requiring a sudo password on the other end and sending auth events to a auditing server. You should be auditing everything already, and adding in sudo now adds another attack vector. You also now have two different accounts that can be manipulated to compromise a system.
lambda 11y ago
> they have root on your box Or they have your discarded dead drive from your backup disk that you forgot to enable full disk encryption on. Or they rooted a machine that you were using "ssh -A" on to forward your agent, and have been able to temporarily hijack your SSH agent session. Or there's an information disclosure vulnerability in your web browser that allows them to read files from your hard drive, though without control of what files they can read, and by chance the attacker got lucky and one of the files was .ssh/id_rsa. While the above description goes way further than I probably would, and yeah, 2FA would be more reasonable, there are good reasons to practice defense in depth, and try to design systems that have a chance of staying secure even if one of your assumptions fails like "private key is compromised".
cbsmith 11y ago
If your threat model is someone stealing and cracking your private key, you really ought to be more worried that they are going to use their time machine to go back in time and kill your mother.
- steckerbrett 11y ago
  Both actions happen at the same time, someone phishes you, captures your input and they have the password for it as well. Now that they've got a shell on your box IP address restrictions are bypassed as well, as is port knocking. This is completely plausible, time machines are not. I read a (private) incident report very recently where half a company had their devices spear phished in order to gain access to a single internal server.
  - cbsmith 11y ago
    Oh, someone capturing your private key's passphrase is something to be genuinely worried about. Someone brute forcing said passphrase? Yeah no.

moe 11y ago

1. Disable root This doesn't add any security, it only makes your admin life miserable.

cbsmith 11y ago
I keep trying to explain to people that if anything this adds complexity to the security problem...
- hackmiester 11y ago
  Can you explain this to me? We do it at work for accountability purposes, but I'm not sure I'm clear on the security implications.
  - cbsmith 11y ago
    From an accountability standpoint, if each person logs in to the root account directly with a distinct private/public key, you can still have full individual accountability. I'd think the complexity side of the sudo strategy is self-evident, so perhaps I'm not understanding the part that needs explaining.
    - hackmiester 11y ago
      I don't find 'sudo' to be complex at all. If in your situation I would have had the ability to log in as root, in my situation I will be in the 'wheel' group. It seems very straightforward to me.
      - cbsmith 11y ago
        I think you misunderstand my point. You have increased the complexity of securing the system. You now have each user's login shells, all of the joys of what those login shells touch, the sudo program and its configuration, all added to the attack surface.
  - moe 11y ago