4 ms·

I think a lot of the people in this comment thread are missing the point when using the `sshd` example. There is no single infallible way to secure ssh, but the

I think a lot of the people in this comment thread are missing the point when using the `sshd` example. There is no single infallible way to secure ssh, but there are a lot of things that can be done together to make it pretty darn hard to hack, and most of those countermeasures have some degree of 'obscurity' to them. Example: * Use RSA keys instead of passwords -> This will eliminate most risk, except for exploits in sshd itself, * Change the default port from 22 to something in the 40k+ range, which will keep you from being scanned, and * Whitelist IP addresses that can connect to port xx on your server -> This will eliminate 95% of remaining risk * Using a 'clean' bastion server to access other systems via agent-forwarding, preventing malware on admin workstations from being able to propagate over SSH. So, no you're never going to be 100% secure, that's just unreasonable. But like you said, the cost can be increased to the point that all but the most determinted state sponsored APT groups.

scarmig 6y ago
Each security measure has a value and a cost. Keys over passwords provide by far the best value/cost ratio. Using obscure ports or port knocking or whitelisted IPs are relatively clunky mechanisms that are more expensive and obscure your security posture as much to yourself as to adversaries.
- yabones 6y ago
  This is absolutely true, but in some ways this is more about reducing the number of 'attempted connections' in the sshd log. Meaning, any failed connection that is recorded (and ideally shipped off to a centralized log system) is in some way actionable. Opening up port 22 (with keys) will still create tonnes of alerts from any SIEM. The other thing to consider is that there could be exploits in OpenSSH itself. There hasn't been a truly critical vulnerability in a very long time, but low severity or non RCE vulnerabilities aren't exactly rare: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=openssh https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=openssh
- somedude11 6y ago
  >obscure your security posture as much to yourself as to adversaries Almost barfed from sheer intensity of tech corpobabble. Its for blocking 0-days dummy!
cthalupa 6y ago
>* Change the default port from 22 to something in the 40k+ range, which will keep you from being scanned, and I'm replying to these suggestions all over this item because I think it's important, so I apologize if you've since seen this comment elsewhere, but: This introduces new security risks. Non-privileged users can bind on ports in the 40k+ range and cannot bind on 22. If you restart sshd for a software upgrade or some other reason, or the iptables rules you're using to remap the ports get flushed, the malicious non-privileged user can now bind to the port people were communicating with your sshd on, and if they ignore the host key mismatch, everything they send can be captured by the malicious user. Older openssh clients have default configurations that can result in the leak of the whole private key, if you use password auth or 2FA they can outright steal those, perhaps their fake sshd will do more than just steal credentials and will actually mimic a shell and let them gain more understanding of how the system ticks, etc. Is this level of attack something most people are going to run into? No. But neither is an attack more sophisticated than brute force password attempts. It's definitely information people should be keeping in mind when making these sorts of decisions, too.
- magicalhippo 6y ago
  > This introduces new security risks. Non-privileged users can bind on ports in the 40k+ range and cannot bind on 22. My firewall does port mapping so externally it's not 22, but internally it is.
  - cthalupa 6y ago
    This is significantly better than just changing the port the daemon listens on, for sure. There's still public access to SSH, so you're still at risk from a zero day, weak credentials, etc., so I don't think it's quite to ideal levels where you are employing a VPN, disallowing all public access, etc., but at least you're not introducing new potential attack vectors :)
    - magicalhippo 6y ago
      What about VPN makes the VPN server software more secure than the SSH server software?
tptacek 6y ago
Neither changing the SSH port nor using IP source address filters constitute serious countermeasures; they complicate systems and offer little return on the investment. Don't bother. If you're worried enough to change the SSH configuration, set up WireGuard.
pabs3 6y ago
I'd suggest using jump hosts (-J or ProxyJump) rather than agent forwarding to a bastion host. IIRC the latter gives the bastion host access to your keys.

scarmig 6y ago

Each security measure has a value and a cost. Keys over passwords provide by far the best value/cost ratio. Using obscure ports or port knocking or whitelisted IPs are relatively clunky mechanisms that are more expensive and obscure your security posture as much to yourself as to adversaries.

yabones 6y ago
This is absolutely true, but in some ways this is more about reducing the number of 'attempted connections' in the sshd log. Meaning, any failed connection that is recorded (and ideally shipped off to a centralized log system) is in some way actionable. Opening up port 22 (with keys) will still create tonnes of alerts from any SIEM. The other thing to consider is that there could be exploits in OpenSSH itself. There hasn't been a truly critical vulnerability in a very long time, but low severity or non RCE vulnerabilities aren't exactly rare: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=openssh https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=openssh
somedude11 6y ago
>obscure your security posture as much to yourself as to adversaries Almost barfed from sheer intensity of tech corpobabble. Its for blocking 0-days dummy!

cthalupa 6y ago

>* Change the default port from 22 to something in the 40k+ range, which will keep you from being scanned, and I'm replying to these suggestions all over this item because I think it's important, so I apologize if you've since seen this comment elsewhere, but: This introduces new security risks. Non-privileged users can bind on ports in the 40k+ range and cannot bind on 22. If you restart sshd for a software upgrade or some other reason, or the iptables rules you're using to remap the ports get flushed, the malicious non-privileged user can now bind to the port people were communicating with your sshd on, and if they ignore the host key mismatch, everything they send can be captured by the malicious user. Older openssh clients have default configurations that can result in the leak of the whole private key, if you use password auth or 2FA they can outright steal those, perhaps their fake sshd will do more than just steal credentials and will actually mimic a shell and let them gain more understanding of how the system ticks, etc. Is this level of attack something most people are going to run into? No. But neither is an attack more sophisticated than brute force password attempts. It's definitely information people should be keeping in mind when making these sorts of decisions, too.

magicalhippo 6y ago
> This introduces new security risks. Non-privileged users can bind on ports in the 40k+ range and cannot bind on 22. My firewall does port mapping so externally it's not 22, but internally it is.
- cthalupa 6y ago
  This is significantly better than just changing the port the daemon listens on, for sure. There's still public access to SSH, so you're still at risk from a zero day, weak credentials, etc., so I don't think it's quite to ideal levels where you are employing a VPN, disallowing all public access, etc., but at least you're not introducing new potential attack vectors :)
  - magicalhippo 6y ago
    What about VPN makes the VPN server software more secure than the SSH server software?

tptacek 6y ago

Neither changing the SSH port nor using IP source address filters constitute serious countermeasures; they complicate systems and offer little return on the investment. Don't bother. If you're worried enough to change the SSH configuration, set up WireGuard.

pabs3 6y ago

I'd suggest using jump hosts (-J or ProxyJump) rather than agent forwarding to a bastion host. IIRC the latter gives the bastion host access to your keys.