[HN Gopher] Simple SSH Security
___________________________________________________________________
Simple SSH Security
Author : haarts
Score : 75 points
Date : 2021-11-08 19:31 UTC (3 hours ago)
(HTM) web link (disknotifier.com)
(TXT) w3m dump (disknotifier.com)
| brightball wrote:
| I always wonder if something like Teleport is going to catch on
| to change this conversation a little bit.
|
| https://goteleport.com/
| haarts wrote:
| I use https://tailscale.com, Teleport looks similar? Or do you
| prefer one over the other?
| wdella wrote:
| Tailscale and Teleport are similar, but operate at different
| levels of the network stack. Tailscale governs access and
| routing at L4 in the OSI model. See Hashicorp's Boundary or
| VPNs for alternatives. As a generalization, Teleport works at
| L7 -- doing auth and routing at the application protocol
| (ssh, psql, k8s) level.
|
| There are ups and downs to both: L4 is relatively technology
| agnostic (e.g. you don't need different support for
| connecting to a database vs ssh). L7 auth & routing gives
| greater protocol introspection, but means more work to
| support different use cases.
|
| Depending on your scale and use case, the right answer may be
| both: Do 2FA for both network access (are you allowed to send
| packets to the ip:port) and application access (are the
| packets you send allowed to sign in to the database as an
| intern or a admin?). The most important part is to get a
| hardware token and SSO on the path to access.
|
| Disclosure: I work for Teleport. I also think Tailscale is
| awesome and run it for my home lab.
| rzzzt wrote:
| When did they stop being called Gravitational?
| wdella wrote:
| Roughly a year ago (November 2020):
|
| https://goteleport.com/blog/gravitational-is-teleport/
| _joel wrote:
| Doesn't mention passwording the keys or anything like TOTP, which
| isn't all that hard to setup (albeit a bit more complex for a
| simple guide). Nor any reactive address blocking
| TiccyRobby wrote:
| Also for some of the algorithms, AFAIK you may need some
| configuration changes to the ssh client which you are using to
| connect. Both client and server need to use the same algorithm.
| tialaramex wrote:
| The algorithms used will be negotiated. So, unless your SSH
| client is unwilling to use any of the acceptable algorithms it
| just will work.
|
| For the server's proof of its identity, one gap in older SSH
| versions is that the client doesn't learn other host keys. So
| if your client is content with Archaic-host-key, even though
| the server has been telling anybody new about Shiny-modern-
| host-key, when the server finally removes Archaic-host-key the
| client can't verify this server. In modern OpenSSH
| UpdateHostKeys controls this in clients and defaults to
| learning new host keys in the most obvious cases.
| yjftsjthsd-h wrote:
| You could also deal with updating host keys by signing them
| and just having clients trust the signing authority.
| haarts wrote:
| I liked this article about it:
| https://smallstep.com/blog/use-ssh-certificates/
| [deleted]
| teddyh wrote:
| See also:
|
| https://bettercrypto.org/#_openssh
|
| https://www.debian.org/doc/manuals/securing-debian-manual/se...
| jimmygrapes wrote:
| I have been asking this of colleagues informally for decades
| now, but I will do it again: why is it that, if the majority of
| best practices for security are identical (ie "disable these
| settings asap"), are the default settings the way they are? And
| what would it take to change them to be secure by default?
| tialaramex wrote:
| The defaults assume your appetite for security risk is much
| greater than your appetite for interop failure.
|
| Imagine two products that could easily exist, almost the same
| features:
|
| A by default works just fine, but there's a risk an adversary
| spends $10M to attack you. You can tweak the config and
| replace all the OmniCorp CheapDevices in your estate to get
| rid of that attack which is best practice.
|
| B by default requires that you replace all the OmniCorp
| CheapDevices in your estate or it won't work. You can tweak
| the config and risk that an adversary spends $10M to attack
| you so that the OmniCorp CheapDevices still work.
|
| Which one do you buy? You buy A of course. Nobody is going to
| sign off on the budget to replace all the OmniCorp
| CheapDevices. What's this nonsense about a $10M attack
| anyway?
|
| At some point the risk is judged to be too high, and people
| flip the defaults for those risks. For example OpenSSH
| decided the risk for SHA1 authentication is now too high,
| like the Web PKI had years before, but despite SSH being a
| much less plausible target than the Web PKI for various
| reasons.
| tptacek wrote:
| The defaults support the largest number of client SSH
| implementations. If you're doing a de novo SSH
| implementation, you can almost certainly just support the
| newest clients, and thus get a better config.
| yjftsjthsd-h wrote:
| I'm pretty sure some of those _are_ on by default
| (PermitEmptyPasswords). Some others don 't have a sane
| general setting (AllowUsers) or depend completely on your
| local environment (KerberosAuthentication). Some are
| compatibility issues (PasswordAuthentication, cypher
| selection). And finally, some are ... more controversial than
| defaults should be (Port, PermitRootLogin).
| lousken wrote:
| Which ones aren't secure by default? When you install new OS
| like Debian those defaults will be correctly set (and
| depending on your organization, you may change some settings
| around to fit your needs). However, if you customized your
| config e.g. in debian 6 and updated to 11, you may wanna
| revisit those settings and change them
| slaymaker1907 wrote:
| Not really SSH, but Kerberos on many distros allows
| extremely weak ciphers by default. And when I say weak, I
| mean these should have been disabled a decade ago. On
| Ubuntu 20.04 with the default setup, keytabs using DES are
| allowed...
| qw3rty01 wrote:
| the problem is a lot of the "disable asap" steps require a
| step before that so the machine is still accessible
| afterwards (such as adding a non-root user before disabling
| root login, adding an authorized key before disabling
| password login, etc)
| teddyh wrote:
| The software authors can't change the default settings, since
| many users have config files where a setting isn't specified,
| and these users would, when they upgrade, get an unasked-for
| change, which might break their workflow. The software
| authors can change the defaults in major version releases,
| but even that is frowned upon by those who would be affected
| by the change. Therefore, this usually does not happen until
| a real security issue is caused by the old state of things.
|
| The downstream package maintainers for various operating
| systems or distributions have some more leeway in changing
| the defaults, but here, also, they have to bow to the impact
| which a change might have on real-world users. Indeed, since
| these package maintainers are closer to the actual affected
| end users, it has been known to happen that upstream authors
| have changed a default value to be more secure, but the real-
| world impact has been so large that the package maintainers
| have _reverted this change_ in the packaged versions of the
| software, essentially making the software more insecure in
| the name of compatibility. So, package maintainers are more
| flexible, but are also more beholden to the wishes of users
| who might be adversely affected by any changes.
| haarts wrote:
| I don't think the defaults are bad. I think the defaults are
| generic. And I don't have a generic machine. Nobody has. Old
| SSH clients don't need access to my server. So I think it is
| a good idea to remove old cyphers.
|
| Staying ahead of the pack.
| alphabettsy wrote:
| I like to refer to:
| https://infosec.mozilla.org/guidelines/openssh
| haarts wrote:
| That's brilliant!
| chasil wrote:
| I prefer limiting to DJB ciphers where possible (the AES-GCM
| suites might also be helpful, but otherwise anything below is
| legacy crypto): Ciphers
| chacha20-poly1305@openssh.com KexAlgorithms
| curve25519-sha256@libssh.org
|
| AFAIK, if RSA is off the table, then the moduli file isn't
| necessary. RSAAuthentication no
|
| SFTP-only accounts are advised in "SSH Mastery" by Michael
| Lucas to follow this form: Match Group
| sftponly ChrootDirectory %h ForceCommand
| internal-sftp AllowTcpForwarding no
|
| I'm still seeing the external sftp subsystem in latest loads
| (last seen is Microsoft). Internal is better, and required for
| chroot. Subsystem sftp internal-sftp
|
| I like to put SFTP users on a separate server, just for them,
| and turn some other things off: PermitTunnel
| no X11Forwarding no PermitRootLogin no
| AllowTcpForwarding no
|
| Those are some settings that I would prefer.
| cjcampbell wrote:
| Moduli would be relevant to DH kex, though you're safe when
| limiting to ed25519.
| upofadown wrote:
| These howtos involving cryptography should generally be ignored
| unless you actually understand the issues fairly well. The
| default configuration gets a lot of scrutiny. The stuff from "Big
| Bobs Super Secure" configuration howto mostly comes from the same
| sort of article. The ideas from these things take on a life and
| truth of their own after they circulate around a few times.
| pmontra wrote:
| Port 22: I always change it to something else and bots leave my
| servers alone. I wonder why they don't try all the ports. I
| understand it's 16 bits but they should do it only for the
| addresses that don't answer on port 22.
| zamadatix wrote:
| The real search space is 48 bits (IP+port) 281,474,976,710,656.
| Searching at 1 million destinations per second it'd take ~9
| years. So options are either go build something in the billion
| destinations per second range or just to limit the search
| space. Throwing out unadvertised IP space and throw out around
| 99.998% of the remaining destinations by just doing port 22
| allows you to scan the entire internet extremely quickly with
| the smallest of scanning setups.
| xxpor wrote:
| the vast vast majority of addresses aren't going to respond on
| port 22.
|
| Lets say there's 2,000,000 IPv4 addresses that are being used
| on the internet.
|
| If you scan 64,511 ports on each of them (65536-1024-1), that's
| still 129,022,000,000 connection attempts. Probably not worth
| it.
| jsd1982 wrote:
| Just a quick note on this excerpt:
|
| > Disallowing root login is also frequently recommended. I
| believe this has limited merit in our current landscape since 95%
| of the time, the user you log in with has sudo privileges. Then
| it adds no extra security. But you should really judge this for
| your own situation.
|
| Disallowing explicit `root` login makes it harder for attackers
| to guess the usernames which have sudo access, thus I'd say it
| decreases the attack surface area. Yes, sudo gives them the same
| level of access as root but the path to get there from an
| attacker's perspective is not the same.
| aljarry wrote:
| I haven't seen anyone changing the default user logins for
| their instances in AWS, though - everyone uses ubuntu,
| ec2-user, or whatever is the default of their distribution.
| BiteCode_dev wrote:
| If you are logged in as root, you can do anything.
|
| If you are logged in as a sudo user, provided allowing only an
| ssh key, can you can't do anything unless:
|
| - you know the password
|
| - you trick the user into doing the action for you (E.G: a line
| in the bashrc)
|
| The first one will slow down the attaker, the second one may
| trigger the user BS detector.
| sam_lowry_ wrote:
| The link to Mozilla infosec gives a better reason to disallow
| root login in ssh: auditing in multi-user environments.
|
| I am still unconvinced, though. Auditing can by done by
| recording the IP address, for instance.
| AviationAtom wrote:
| Even easier: key signature
| castillar76 wrote:
| Basing things on source IP is really inexact and easily
| muddied, though. For instance, the source IP is a workstation
| or a laptop--now we have to go through DHCP logs to figure
| out who had that IP address at the time the incident
| occurred. Or if we've properly implemented source limitations
| through a bastion host, all we'll see on the end server is
| the source IP of the bastion host, so we'll need to go to the
| bastion to figure out who was logged in at that time and what
| they were doing--hopefully there was only one engineer logged
| in at the time! And that assumes they didn't just SSH-jump
| through, in which case we just have the transitory SSH
| logs...which leaves us with the DHCP problem above unless
| they used their own userID to connect to the bastion itself.
| If it's a publicly available AWS host (which...oy gevalt),
| was that login from "dhcp-
| host-X.Y.Z.Q-suspiciouscablehosting.regionalisp.net" a hack,
| or an engineer trying to fix something by logging in from his
| home Internet connection?
|
| Ultimately, it's just _much_ easier to force individual
| logins and require sudo. Even just an engineer logging in and
| doing 'sudo su -' is significantly more traceable than
| everyone logging in directly as root. Even better if you can
| force the individual logins and sudo sessions to use multi-
| factor auth--then you can keep root non-multi-factored and
| get in with just a password on the console when your MFA
| solution has gone pear-shaped. :)
| R0b0t1 wrote:
| You're right. Also, you also need to know the password to give
| sudo.
| adamzochowski wrote:
| The goal is to avoid password sharing.
|
| if 20 people have root password, and server supports root
| login, then you can't know which of the 20 people had their
| machines compromised.
|
| if 20 people each have to sudo, then you can trace which user
| was compromised.
| AviationAtom wrote:
| If all users have a unique key for root access, and only
| keyed authentication is possible, then you can match the key
| fingerprint in the logs to a physical user.
| rkeene2 wrote:
| I typically frame this as accounts are for accountability.
|
| Reducing accountability isn't typically a goal for
| organizations so it's strictly better to have 20 accounts
| with sudo versus everyone using a single shared account
| (shared accountability) _UNLESS_ the accountability is
| managed some other way (I think this something Gravitational
| Teleport tries to sell on this forum often).
| omgitsabird wrote:
| https://csrc.nist.gov/publications/detail/nistir/7966/final
| egberts1 wrote:
| and don't forget those embedded options that goes into your
| `~/.ssh/authorized-keys` as well.
|
| I too contributed to the sshd-audit as well.
|
| https://egbert.net/blog/articles/fine-tuning-ssh-authorized_...
| egberts1 wrote:
| I also offer easy setup for a secured SSH server and client
| whose configuration file is full of annotation for each of the
| OpenSSH v8.7 settings.
|
| https://github.com/egberts/easy-admin/tree/main/490-net-ssh
| ape4 wrote:
| File /etc/ssh/moduli is part of openssh. So shouldn't the distros
| push out an update.
| kiryin wrote:
| I belong to the camp that believes in using the defaults when it
| comes to ciphers. I am not an expert in cryptography, nor do I
| like copypasting stuff I don't fully understand. The openssh guys
| know this stuff better than I do and I think that's fine.
| [deleted]
| haarts wrote:
| I was long of that conviction too. But the default install
| optimizes for a different thing, compatibility. Or at least
| emphasizes is more than I would do.
|
| For example I never use RSA keys. So these can go. Less cyphers
| => less attack surface.
|
| But I do agree that I'm sure the defaults picked are sensible.
| zoomablemind wrote:
| > ...For example I never use RSA keys.
|
| Exactly, the default RSA for the keygen is what a lot of
| users accept without realizing the implications. Well, lots
| of HowTos out there suggest "enter, enter, enter.." to get
| your key.
|
| What's the rationale for keeping RSA as a default these days?
| ayushnix wrote:
| > What's the rationale for keeping RSA as a default these
| days?
|
| Can't think of any reason except backwards compatibility
| and regulatory compliance.
|
| I don't use anything except ED25519 in my own setup.
| antod wrote:
| _> What 's the rationale for keeping RSA as a default these
| days? _
|
| I think they recently changed this, but for the longest
| time RSA keys were the only kind AWS supported for EC2
| keypairs.
|
| For staff that weren't deploying EC2 instances, EC keys
| were fine, but for the ops people setting them up where the
| EC2 keypair was the initial access key, they needed RSA
| keys.
| shikoba wrote:
| What? RSA keys are insecure?
| kangaroopouch wrote:
| "If You're Typing The Letters A-E-S Into Your Code, You're Doing
| It Wrong" still applies, even though we now type chacha20.
| https://people.eecs.berkeley.edu/~daw/teaching/cs261-f12/mis...
|
| We should aim for not having to fiddle with SSH config, and
| having sane defaults.
|
| That could involve:
|
| * cryptographers advocating changing OpenSSH defaults
|
| * people refining their threat model to being able to accept
| weaker defaults
|
| * Distributions or config management solutions that improve on
| the defaults in a careful considered way.
|
| I use NixOS which generates my sshd_config. By default, NixOS:
|
| * Disables root login via password:
| https://github.com/NixOS/nixpkgs/blob/8605fbd737e526c40ff8f0...
|
| * Sets ciphers according to Mozilla's recommendations:
| https://github.com/NixOS/nixpkgs/blob/8605fbd737e526c40ff8f0...
|
| Other distros, cfgmgmt, and container systems could do this too.
| antihero wrote:
| I've always just used this guide:
|
| https://sshaudit.com/hardening_guides.html#rhel8
|
| Any reason why I shouldn't?
___________________________________________________________________
(page generated 2021-11-08 23:00 UTC)