Simple SSH Security

https://disknotifier.com/blog/simple-ssh-security/

by haarts • 5 years ago

158 94 5 years ago

TiccyRobby• 5 years ago

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.

tialaramex2• 5 years ago

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-h2• 5 years ago

You could also deal with updating host keys by signing them and just having clients trust the signing authority.

teddyh2• 5 years ago

See also:

https://bettercrypto.org/#_openssh

https://www.debian.org/doc/manuals/securing-debian-manual/se...

jimmygrapes• 5 years ago

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?

yjftsjthsd-h2• 5 years ago

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).

lousken2• 5 years ago

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

qw3rty01• 5 years ago

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)

teddyh2• 5 years ago

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.

haarts5• 5 years ago

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.

tialaramex2• 5 years ago

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• 5 years ago

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.

egberts18• 5 years ago

OpenSSL v7.2 is pretty old.

Current version is rocking v8.2.

egberts18• 5 years ago

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_...

egberts18• 5 years ago

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

alphabettsy• 5 years ago

I like to refer to: https://infosec.mozilla.org/guidelines/openssh

haarts5• 5 years ago

That's brilliant!

chasil• 5 years ago

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• 5 years ago

Moduli would be relevant to DH kex, though you’re safe when limiting to ed25519.

kiryin• 5 years ago

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.

haarts5• 5 years ago

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• 5 years ago

...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?

brightball• 5 years ago

I always wonder if something like Teleport is going to catch on to change this conversation a little bit.

https://goteleport.com/

haarts5• 5 years ago

I use https://tailscale.com, Teleport looks similar? Or do you prefer one over the other?

wdella2• 5 years ago

Tailscale and Teleport are similar, but operate at different levels of the network stack. Tailscale governs access and routing at L3 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: L3 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• 5 years ago

When did they stop being called Gravitational?

wdella2• 5 years ago

Roughly a year ago (November 2020):

https://goteleport.com/blog/gravitational-is-teleport/

ryanar• 5 years ago

I would also recommend checking out strongDM (I work there). We go a lot further than teleport does in the zero trust world.

See https://www.strongdm.com/compare for comparisons.

https://strongdm.com

_joel• 5 years ago

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

upofadown5• 5 years ago

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.

grosswait2• 5 years ago

I disagree, you can always go straight to one of the industry recognized hardening benchmarks then. The ssh hardening guidance in the posted article and any number of hardening guidelines are all pretty similar.

The defaults keep the mailing lists from filling up with troubleshooting questions, but anyone with some command line skills can change one parameter at a time and test. If you’re exposing ssh to the internet you should absolutely not be ignoring hardening guides.

jsd1982• 5 years ago

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.

sam_lowry_2• 5 years ago

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.

AviationAtom2• 5 years ago

Even easier: key signature

castillar762• 5 years ago

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• 5 years ago

You're right. Also, you also need to know the password to give sudo.

adamzochowski• 5 years ago

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.

AviationAtom2• 5 years ago

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.

rkeene22• 5 years ago

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).

croutonwagon• 5 years ago

Also, at least in Ubuntu, sudo commands are logged in syslog and are thus auditable.

That’s not necessarily the case if you su as root and run the same commands.

remram• 5 years ago

Turning this on its head, about password sharing.

If 20 people have the root password, there is a single password that will allow your machine to be pwned.

If 20 people have 20 passwords and sudo access, then any of 20 passwords will allow your machine to be pwned.

You can't know which of the 20 people you're trusting to pick a password is reusing it.

miohtama• 5 years ago

A stronger solution to enable two-factor authentication, so that a machine compromise does not compromise SSH access.

aljarry• 5 years ago

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.

flatiron• 5 years ago

But the default for ec2-user doesn’t allow logging into ssh with a password.

BiteCode_dev• 5 years ago

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.

tadbit• 5 years ago

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

This assumes one isn't using password-less sudo (NOPASSWD), which several distros do set by default and many users change to it for convenience.

dumpsterdiver• 5 years ago

Disallowing explicit `root` login makes it harder for attackers to guess the usernames which have sudo access

Or rather, it forces attackers to enumerate other usernames because the default root account isn't available to brute force. In general, when password authentication is in use (which it should never be for SSH), then disabling the default user account acts as a simple way of mitigating brute force attacks. If best practices are followed and passwords are not used to authenticate to SSH servers, then this additional measure might be moot. Even so, I can't think of a reason not to disable root SSH login anyway, even if password authentication is disabled. A layered defense assumes the possibility that other defenses might fail. Noone wants to be the person who wrote off an additional defense measure because they didn't think it was possible to exploit, only to have a new CVE come out to prove them wrong.

grosswait2• 5 years ago

If shared logins are in use attribution can be problematic.

hnarn• 5 years ago

Disallowing explicit `root` login makes it harder for attackers to guess the usernames (...)

Technically correct I guess, but isn't password logins considered bad practice anyway? So if you have passphrase protected, key-based authentication only, is it really relevant whether you have it against root or a user with sudo permissions?

ape4• 5 years ago

File /etc/ssh/moduli is part of openssh. So shouldn't the distros push out an update.

zamadatix2• 5 years ago

Openssh allows "weak" ciphers as long as they are still "strong enough" for some values of weak and strong enough, typically where there is no known or imminent way to attack it even if it isn't as strong as other options.

Switching to only ciphers currently known to be strong puts you a level above that where even if a new weakness was found (publicly or not) it may not be enough to make it breakable.

Whether most really need to worry about any of that is another story. I'd say if you're job task isn't to research how to secure SSH better don't go changing ciphers just because you read it in a blog post. If it is your task consider it one point of data as you dive into understanding the nerd knobs.

egberts18• 5 years ago

Make your own moduli file.

antihero• 5 years ago

I've always just used this guide:

https://sshaudit.com/hardening_guides.html#rhel8

Any reason why I shouldn't?

egberts18• 5 years ago

If you are using DH kex (RSA), then you probably should regenerate the moduli file instead of just taking the distro’s version and filtering it as outline in your link.

To regenerate the moduli, you run:

    ssh-keygen -M generate \
        -O bits=4096 \
        moduli.candidates

    ssh-keygen -M screen \
        -f moduli.candidates \
        moduli.safe
    
    awk '$5 > 3071' moduli.safe \
        | tee /etc/ssh/moduli

source: https://github.com/egberts/easy-admin/blob/main/490-net-ssh/...

omgitsabird• 5 years ago

https://csrc.nist.gov/publications/detail/nistir/7966/final

egberts18• 5 years ago

Seven years old.

Need better updates with the current and present time.

kangaroopouch• 5 years ago

"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.

pmontra• 5 years ago

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.

xxpor• 5 years ago

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.

knorker2• 5 years ago

Doesn't help much when shodan has already portscanned everyone.

I just searched for "ssh -port:22" and found many hits.

But also yes. Switching port (or just blocking China) will vastly reduce SSH probes.

zamadatix2• 5 years ago

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 (completely feasible just more work to not get blocked) 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.

sandreas• 5 years ago

I once wrote something similar for file servers via SFTP: https://pilabor.com/blog/2021/04/how-to-setup-a-secure-file-...

kseistrup• 5 years ago

You can also test your actual configuration with ssh-audit: https://github.com/jtesta/ssh-audit

Simple SSH Security

Related Stories