[HN Gopher] Best Practices for Securing SSH
___________________________________________________________________
Best Practices for Securing SSH
Author : old-gregg
Score : 52 points
Date : 2022-01-05 18:20 UTC (4 hours ago)
(HTM) web link (goteleport.com)
(TXT) w3m dump (goteleport.com)
| aborsy wrote:
| 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.
| theandrewbailey wrote:
| Is fail2ban still a good idea? Any reason it's not mentioned
| here?
| oakwhiz wrote:
| I think that if you follow the recommendation to disable
| password-based authentication, then fail2ban is downgraded from
| a near-requirement to a defense-in-depth tactic. It's not
| nearly as important to restrict the number of retries if
| asymmetric key-based authentication is used, because there is a
| much larger keyspace to search through than if passwords were
| used - assuming that the cryptography works as intended.
| fulafel wrote:
| It's a way to lock you out if the adversary can source or spoof
| connections from your usual access network.
| tyingq wrote:
| I'm a fan of pam_shield, because it's tied right to the auth
| part versus tailing log files. And you can trigger whatever
| action you want. I believe the default is just null routing.
|
| https://github.com/jtniehof/pam_shield
|
| There are other, similar pam modules if this one isn't your cup
| of tea. There's pam_tally2, and others.
| traceroute66 wrote:
| Not a good idea for two reasons: 1) The very
| first configuration change anybody should be making to an SSH
| server should be disabling password-based authentication. Once
| you've done that you've rendered fail2ban obsolete, because the
| only real way in for attackers from that point in is via
| software security vulnerabilities, and fail2ban can't help you
| with that, that's your job to keep yourself patched up.
| 2) In an IPv6 world, fail2ban is pointless. The ranges are so
| vast.
| bennyp101 wrote:
| 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.
| throwJan22 wrote:
| I try to have IP6 only addresses as it helps with port scanning.
| I'd think it'd be more common.
| beermonster wrote:
| 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/
| [deleted]
| chasil wrote:
| Rotate your keys.
|
| https://www.linuxjournal.com/content/ssh-key-rotation-posix-...
| uniqueuid wrote:
| 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
| traceroute66 wrote:
| Absolutely pointless for two major reasons:
| 1) Many attackers "hide" behind cloud services. So whatcha
| gonna do when your primary attack vector is AWS EC2 instances ?
| Block AWS CIDR ranges ? 2) With IPv4 exhaustion
| increasing numbers of people will be using IPv4 allocations
| across geographic boundaries.
| R0b0t1 wrote:
| > Block AWS CIDR ranges?
|
| Since I don't log in from there, yes sure? And if I'm hosting
| on AWS I can proxy through an AWS resident host. Same with
| any other cloud provider.
| throwawayboise wrote:
| Yep. It has been a long time since I ever needed to provide
| a wide-open SSH service. By far the normal case is to allow
| login from one or a handful of IP addresses, or maybe a
| /24. Do this and your SSH log noise drops to zero.
| urda wrote:
| > Absolutely pointless
|
| My logs and firewall greatly disagree. Please avoid comments
| on HN like this where it boxes solutions into a "my way or
| the highway" result, when it has been demonstrated to you
| here it's not "Absolutely pointless". Security is the
| layering of multiple solutions and defenses to protect your
| assets, there is no magic bullet or single solution.
| uniqueuid wrote:
| Looking at my case, I wouldn't call this pointles, since it
| removed > 95% of login attempts.
|
| Sure, IP address block fragmentation will remove some value,
| but you'd still kill a lot of juicy compromisable home IP
| addresses in those countries.
|
| Regarding cloud providers - well, I hope they have some
| automated systems to clamp down, since it's against their own
| interest to serve as vectors.
| traceroute66 wrote:
| > since it removed > 95% of login attempts
|
| If you use certificate authentication and disable password
| authentication then you've killed off 100% of unauthorised
| attempts right off the bat. There really isn't much need to
| do more than that, its the world's easiest security fix.
| Damogran6 wrote:
| When this topic (always) comes up, somebody points out
| that moving the ports isn't security...but it kinda is,
| because if you suddenly see an uptick in logging, you
| know someone cares enough to FIND your port, and then
| POINT SOMETHING AT the port, and in the meantime it
| reduces heat and power and disk wear.
| uniqueuid wrote:
| 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 wrote:
| > 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.
| ncmncm wrote:
| The article fails to recommend turning off
| "KbdInteractiveAuthentication", which used to be called
| "ChallengeResponseAuthentication", which is another password
| protocol.
| pphysch wrote:
| 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.
| R0b0t1 wrote:
| Superficially this sounds good but if you don't trust the
| security of SSH you need to ask why you trust TLS any more.
| pphysch wrote:
| It's not about trusting the security of SSH vs TLS, but
| rather the ergonomics of deploying either technology. All the
| Big Cloud providers offer both, last time I checked.
|
| Point is, you can offer a secure & functional remote shell
| without touching Linux PAM or the Linux authx stack beyond
| `useradd` and a locked-down `sshd_config`. Orgs that already
| offer web services over HTTPS may find this route desirable.
| DarylZero wrote:
| > without touching Linux PAM or the Linux authx stack
|
| ..falsely implying you'd have to "touch" this stuff to set
| up OpenSSH on port 22.
| pphysch wrote:
| If you are exposing SSH to the world or your customers,
| you have to do a _lot_ more than "touch" this stuff to
| achieve reasonable security. That's the point.
| DarylZero wrote:
| No you don't.
|
| Why would you need to modify PAM for SSH on port 22 but
| not SSH over TLS?
| gz5 wrote:
| +1 another way to accomplish (open source):
| https://ziti.dev/blog/zitifying-ssh/
| oofbey wrote:
| 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.
| R0b0t1 wrote:
| It depends what you mean by 2FA. Older definitions allow
| password protected keyfiles. If you mean active 2FA, you need a
| PAM plugin and usually a provider, but you can host your own.
| Look at e.g. Yubikey.
| lnxg33k1 wrote:
| Usually with authentication on linux, pam is a good starting
| point https://duo.com/docs/duounix
| VTimofeenko wrote:
| I set up something like this [1] in the past. It relies on pam
| letting in the user if and only if that user provides the
| generated number. Do note that messing up pam is easy and may
| lock you out, so have a backup/snapshot, rescue shell or an
| open session when you are configuring it.
|
| [1]: https://ubuntu.com/tutorials/configure-ssh-2fa#1-overview
| beermonster wrote:
| Since OpenSSH >=8.2 you can use FIDO2 and security keys. See
| https://www.stavros.io/posts/u2f-fido2-with-ssh/
| [deleted]
| seldomcomment wrote:
| you can do so also without google authenticator
|
| in a previous HN post I've copied my quick 'n dirty notes
|
| [1]: https://pastebin.com/yYzSrM61
___________________________________________________________________
(page generated 2022-01-05 23:01 UTC)