Best Practices for Securing SSH

  • As sad as it makes me, blocking large parts of the world that you don't expect to connect from via a list of CIDR blocks is an incredibly effective way to secure anything and reduce logspam.

    I personally use nft blackhole [1], which I can recommend for its ease of use.

    [1] https://github.com/tomasz-c/nft-blackhole

  • This sure looks like advertisement for teleport vs any actual advice. A real post would actually tell you how to do these things.

    Compare it to something like https://www.howtogeek.com/443156/the-best-ways-to-secure-you...

  • If public key authentication is used with secret key in a hardware key/TPM/secure enclave, most other suggestions made don’t help further.

    Fail2ban is certainly not needed (unless there is potential that some users may use very weak passwords, which password policy shouldn’t permit that, or logs are preferred to be cleaner).

    Firewalls, public key authentication (verify host keys, also rotate), hardware keys, using SSH over Wireguard, and a secure bastion host provide real security. Preventing SSH agent and X11 forwarding is good too.

  • The article says to use two-factor-auth (obviously a good idea) but says nothing about HOW you add 2FA to SSH. Does anybody have pointers? I'd love to add 2FA to my bastion hosts, but don't want to put a ton of effort into doing so.

  • What happened to single packet authentication? As someone who has casually run hosts, I've been disabling password and setting up keys for most of the 10+ years. Always been curious about SPA though, it seems like a decent way to protect a service, better than firewalling IP ranges and changing ports, no?

  • > Implement firewalls

    This is the most important by faaaar.

    Do this experiment: Start a vm on any cloud with an open port 22, and watch the logs of sshd service. You will be amazed at the number of requests with bad credentials that will hit your machine within minutes. I watched logs to different ports, and ssh wins first place

  • I usually set up a bastion host that has Tailscale installed on it, with my private key stored on a yubikey.

    That way you need to be on the Tailscale network, and have my Yubikey/PIN - makes it nice and easy for me to get on from pretty much anywhere if I need to.

  • Around the time it was released I tried to interest people in Kuhn's https://www.cl.cam.ac.uk/~mgk25/otpw.html for those travelling and wanting SSH access to the site from potentially-dodgy systems. Still, without your own device you may not be able even to use hardware keys. If the client is untrustworthy, you do still might worry about the channel being open from it to the other end.

  • The article fails to recommend turning off "KbdInteractiveAuthentication", which used to be called "ChallengeResponseAuthentication", which is another password protocol.

  • I wrote a simple bash script which fetches my current ipv4 address , and then uses aws cli to add that ip address to my whitelist for the ssh port on all my instances.

    I have a cron job which autoclears all the whitelisted ip addresses at the end of the day.

    If youre a team, you can always make a similar script and share it with everyone, since aws cli is configured with your team members iam access, you can be assured that they can only whitelist themselves on instances which they have access to over iam.

    If you dont use aws, just expose an api on your server, protect the endpoint with an api key and use that endpoint to send the whitelisted ip to update your iptables(/whatever firewall you're using).

    If all of this sounds really complicated to you, you can always just setup wireguard on one of your machines, then make all your team members connect to that vpn, and only whitelist the ip address of that machine across all your instances. That way only people who can authenticate with your vpn can even access your ssh ports.

  • An advertorial puff piece that fails to mention that OpenSSH since 8.2 has had the ability to use FIDO U2F tokens as private keys.

  • SSH blocked by firewall for any connections except incoming from VPN IP address. VPN server is mine and located on separate server.

    This has proven to be working solution for years. Any monstrous "security" constructions with keeping it open or partially open will backfire once one attack vector will be discovered.

  • At work I have an access tool for writing automation on groups of servers. Basically orchestration without a server.

    I used to be SSH only, but the framework is built around simply delivering CLI commands and enabling file transfer.

    So I abstracted the command request/response and now I can do it over AWS-SSM, or docker run, kubectl, salt daemon, teleport, or even AWS-SSM to a "bastion" and then ssh from there.

    AWS-SSM is basically a polling mechanism, you can easily roll one of your own.

    What I don't like is two factor authentications that require manual steps. Then you can't automate anything.

  • Another option is not actually expose SSH at all and proxy shells through a web server via WebSockets, fronted by xterm.js or hterm.js. There are some limitations here (like ctrl-W will get captured by the browser rather than the shell) but it is relatively easy to implement and fits a lot of use cases without the nightmare of fitting Linux PAM to your organization's evolving IAM needs.

    Won't work for everyone, but definitely something to consider if you are offering "shell-as-a-service" internally or externally.

  • Is fail2ban still a good idea? Any reason it's not mentioned here?

  • Lovely that they are propagating the folklore security of using a non-standard port. And yet they also discuss using a well-known bastion host.

  • Can also audit using ssh-audit [1][2]

    [1] https://man.archlinux.org/man/community/ssh-audit/ssh-audit....

    [2] https://www.ssh-audit.com/

  • > Disable password-based auth

    What happens if I lose my ssh key?

    I like passwords because I can remember them so I don't have to put my key on someone else's computer (cloud). So on my server I have one user (non root) with a long password so I don't have access to my keys I can still login.

  • This advice is not very good. Probably the best thing in this list is using the “AllowUsers” directive (which makes limiting root access a moot point) and using a good, strong key. There’s not much benefit to using a cert over a password-protected ssh private key.

  • They really push ssh certificate auth vs key auth. Each has their tradeoffs. If you're going to go through implementing a pki for ssh, I'd throw in something like kerberos also to look into.

  • FWIW, Teleport are also the sponsor of Last Week in AWS Security (2022-01-06).

    It seems someone was told to go market Teleport and posting to HN is free (unlike newsletter sponsorships).

  • Implement port knocking

  • SSH over Tor hidden service

  • Is there any simple, secure by default alternative to ssh?

  • I try to have IP6 only addresses as it helps with port scanning. I'd think it'd be more common.