Simple SSH Security
disknotifier.com
Simple SSH Security
1–10 of 97 posts
Re: Simple SSH Security
#2Also 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.
Re: Simple SSH Security
#3Re: Simple SSH Security
#4and 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_...
Re: Simple SSH Security
#5and 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_...
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.
Re: Simple SSH Security
#6See also: https://bettercrypto.org/#_openssh https://www.debian.org/doc/manuals/securing-debian-manual/se...
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?
Re: Simple SSH Security
#7Also 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.
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.
Re: Simple SSH Security
#8See also: https://bettercrypto.org/#_openssh https://www.debian.org/doc/manuals/securing-debian-manual/se...
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?
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).
Re: Simple SSH Security
#9Also 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.
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 remo…
You could also deal with updating host keys by signing them and just having clients trust the signing authority.
Re: Simple SSH Security
#10See also: https://bettercrypto.org/#_openssh https://www.debian.org/doc/manuals/securing-debian-manual/se...
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?
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