22 ms·

Simple SSH Security

158 points by haarts 5y ago

upofadown 5y 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.
- grosswait 5y 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.
sandreas 5y ago
I once wrote something similar for file servers via SFTP: https://pilabor.com/blog/2021/04/how-to-setup-a-secure-file-server-with-ssh-sftp/ https://pilabor.com/blog/2021/04/how-to-setup-a-secure-file-...
kseistrup 5y ago
You can also test your actual configuration with ssh-audit: https://github.com/jtesta/ssh-audit https://github.com/jtesta/ssh-audit
TiccyRobby 5y 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.
- tialaramex 5y 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-h 5y ago
    You could also deal with updating host keys by signing them and just having clients trust the signing authority.
    - haarts 5y ago
      I liked this article about it: https://smallstep.com/blog/use-ssh-certificates/ https://smallstep.com/blog/use-ssh-certificates/
      - egberts1 5y ago
        Does it work with closed network like in a whitlab?
teddyh 5y ago
See also: https://bettercrypto.org/#_openssh https://bettercrypto.org/#_openssh https://www.debian.org/doc/manuals/securing-debian-manual/sec-services.en.html#id-1.6.6 https://www.debian.org/doc/manuals/securing-debian-manual/se...
- jimmygrapes 5y 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-h 5y 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).
  - lousken 5y 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
    - slaymaker1907 5y ago
      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...
      - 5y ago
egberts1 5y 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_keys.html https://egbert.net/blog/articles/fine-tuning-ssh-authorized_...
- egberts1 5y 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 https://github.com/egberts/easy-admin/tree/main/490-net-ssh
alphabettsy 5y ago
I like to refer to: https://infosec.mozilla.org/guidelines/openssh https://infosec.mozilla.org/guidelines/openssh
- haarts 5y ago
  That's brilliant!
- chasil 5y 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 5y ago
    Moduli would be relevant to DH kex, though you’re safe when limiting to ed25519.
kiryin 5y 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.
- haarts 5y 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 5y 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?
    - antod 5y ago
      > 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.
    - ayushnix 5y ago
      > 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.
    - shikoba 5y ago
      What? RSA keys are insecure?
brightball 5y ago
I always wonder if something like Teleport is going to catch on to change this conversation a little bit. https://goteleport.com/ https://goteleport.com/
- rzzzt 5y ago
  When did they stop being called Gravitational?
  - wdella 5y ago
    Roughly a year ago (November 2020): https://goteleport.com/blog/gravitational-is-teleport/ https://goteleport.com/blog/gravitational-is-teleport/
- ryanar 5y 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 https://www.strongdm.com/compare for comparisons. https://strongdm.com https://strongdm.com
- haarts 5y ago
  I use https://tailscale.com https://tailscale.com, Teleport looks similar? Or do you prefer one over the other?
  - wdella 5y 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.
_joel 5y 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
ape4 5y ago
File /etc/ssh/moduli is part of openssh. So shouldn't the distros push out an update.
- zamadatix 5y 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.
- egberts1 5y ago
  Make your own moduli file.
jsd1982 5y 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_ 5y 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.
  - AviationAtom 5y ago
    Even easier: key signature
  - castillar76 5y 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. :)
antihero 5y ago
I've always just used this guide: https://sshaudit.com/hardening_guides.html#rhel8 https://sshaudit.com/hardening_guides.html#rhel8 Any reason why I shouldn't?
- egberts1 5y 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/495-net-ssh-moduli.sh https://github.com/egberts/easy-admin/blob/main/490-net-ssh/...
deleted 5y ago
[deleted]
omgitsabird 5y ago
https://csrc.nist.gov/publications/detail/nistir/7966/final https://csrc.nist.gov/publications/detail/nistir/7966/final
- egberts1 5y ago
  Seven years old. Need better updates with the current and present time.
kangaroopouch 5y 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/misc/if.html 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/8605fbd737e526c40ff8f01219db42b5d0076e23/nixos/modules/services/networking/ssh/sshd.nix#L148 https://github.com/NixOS/nixpkgs/blob/8605fbd737e526c40ff8f0... * Sets ciphers according to Mozilla's recommendations: https://github.com/NixOS/nixpkgs/blob/8605fbd737e526c40ff8f01219db42b5d0076e23/nixos/modules/services/networking/ssh/sshd.nix#L312 https://github.com/NixOS/nixpkgs/blob/8605fbd737e526c40ff8f0... Other distros, cfgmgmt, and container systems could do this too.
pmontra 5y 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 5y 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.
  - knorker 5y 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.
    - egberts1 5y ago
      Don’t forget to block Brazil And Romania And Kazakhstan And …
      - gary_0 5y ago
        Last time I looked at the IPs spamming my websites, a lot of them were from Europe, surprisingly.
      - knorker 5y ago
        I'm not saying there aren't non-China probe spam. But without China it's just non-stop to the point of consuming noticeable amount of hard drive space for logs, and making it annoying to read logs looking for other things. At least that's my experience.
      - User23 5y ago
        Back in the EFNet days everyone with a lick of sense autobanned all of Eastern Europe, Asia, and South America. It was literally nothing but script kiddies.

158 points by haarts 5y 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.

grosswait 5y 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.

sandreas 5y ago

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

kseistrup 5y ago

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

TiccyRobby 5y 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.

tialaramex 5y 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-h 5y ago
  You could also deal with updating host keys by signing them and just having clients trust the signing authority.
  - haarts 5y ago
    I liked this article about it: https://smallstep.com/blog/use-ssh-certificates/ https://smallstep.com/blog/use-ssh-certificates/
    - egberts1 5y ago
      Does it work with closed network like in a whitlab?

teddyh 5y ago

See also: https://bettercrypto.org/#_openssh https://bettercrypto.org/#_openssh https://www.debian.org/doc/manuals/securing-debian-manual/sec-services.en.html#id-1.6.6 https://www.debian.org/doc/manuals/securing-debian-manual/se...

jimmygrapes 5y 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-h 5y 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).
- lousken 5y 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
  - slaymaker1907 5y ago
    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...
    - 5y ago

egberts1 5y 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_keys.html https://egbert.net/blog/articles/fine-tuning-ssh-authorized_...

egberts1 5y 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 https://github.com/egberts/easy-admin/tree/main/490-net-ssh

alphabettsy 5y ago

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

haarts 5y ago
That's brilliant!
chasil 5y 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 5y ago
  Moduli would be relevant to DH kex, though you’re safe when limiting to ed25519.

kiryin 5y 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.

haarts 5y 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 5y 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?
  - antod 5y ago
    > 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.
  - ayushnix 5y ago
    > 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.
  - shikoba 5y ago
    What? RSA keys are insecure?

brightball 5y ago

I always wonder if something like Teleport is going to catch on to change this conversation a little bit. https://goteleport.com/ https://goteleport.com/

rzzzt 5y ago
When did they stop being called Gravitational?
- wdella 5y ago
  Roughly a year ago (November 2020): https://goteleport.com/blog/gravitational-is-teleport/ https://goteleport.com/blog/gravitational-is-teleport/
ryanar 5y 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 https://www.strongdm.com/compare for comparisons. https://strongdm.com https://strongdm.com
haarts 5y ago
I use https://tailscale.com https://tailscale.com, Teleport looks similar? Or do you prefer one over the other?
- wdella 5y 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.

_joel 5y 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

ape4 5y ago

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

zamadatix 5y 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.
egberts1 5y ago
Make your own moduli file.

jsd1982 5y 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_ 5y 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.
- AviationAtom 5y ago
  Even easier: key signature
- castillar76 5y 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. :)

antihero 5y ago

I've always just used this guide: https://sshaudit.com/hardening_guides.html#rhel8 https://sshaudit.com/hardening_guides.html#rhel8 Any reason why I shouldn't?

egberts1 5y 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/495-net-ssh-moduli.sh https://github.com/egberts/easy-admin/blob/main/490-net-ssh/...

deleted 5y ago

[deleted]

omgitsabird 5y ago

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

egberts1 5y ago
Seven years old. Need better updates with the current and present time.

kangaroopouch 5y 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/misc/if.html 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/8605fbd737e526c40ff8f01219db42b5d0076e23/nixos/modules/services/networking/ssh/sshd.nix#L148 https://github.com/NixOS/nixpkgs/blob/8605fbd737e526c40ff8f0... * Sets ciphers according to Mozilla's recommendations: https://github.com/NixOS/nixpkgs/blob/8605fbd737e526c40ff8f01219db42b5d0076e23/nixos/modules/services/networking/ssh/sshd.nix#L312 https://github.com/NixOS/nixpkgs/blob/8605fbd737e526c40ff8f0... Other distros, cfgmgmt, and container systems could do this too.

pmontra 5y 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 5y 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.
- knorker 5y 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.
  - egberts1 5y ago
    Don’t forget to block Brazil And Romania And Kazakhstan And …
    - gary_0 5y ago
      Last time I looked at the IPs spamming my websites, a lot of them were from Europe, surprisingly.
    - knorker 5y ago
      I'm not saying there aren't non-China probe spam. But without China it's just non-stop to the point of consuming noticeable amount of hard drive space for logs, and making it annoying to read logs looking for other things. At least that's my experience.
    - User23 5y ago
      Back in the EFNet days everyone with a lick of sense autobanned all of Eastern Europe, Asia, and South America. It was literally nothing but script kiddies.