Secure OpenSSH
I’ve been continuously learning OpenSSH (since 2006) and closely following its changes since version 6.7.
I personally consider start using Public Key Authentication and Host-based Authentication a milestone from a beginner to intermediate (experienced, power user, whatever appropriate).
NOTE: TCP Forwarding (SSH Tunneling), Agent Forwarding, X11 Forwarding are considered advanced.
To understand Roaming through the OpenSSH client: CVE-2016-0777 and CVE-2016-0778 better, I started reading OpenSSH manual to learn how its implementation works internally.
I once thought I had done an excellent job hardening OpenSSH server and client configurations until I came across this article Secure Secure Shell. It simply blew my mind. I didn’t regain my confidence until RTFM again ;-D
Below is a sample ~/.ssh/config
-> Gist inspired by stribika
‘s post, with comments.
My personal ssh client configuration file has never been so long ;-D
I don’t really understand why OpenSSH includes broken/weak algorithms, at least disable them by default for security sake. Fortunately users can specify unbroken (yet) algorithms to use in server/client configuration files.
NOTE: Remember to make necessary changes to the
sshd_config
on server side to make things work.sshguard
is strongly recommended for Linux servers running in the cloud with public IPs.
Last but not least, there is NO perfect security, we have to stay alert and keep learning / adopting new best practices. Thanks to Edward Snowden, who raised our security awareness and skills to an all new high level ;-D
Trust me, OpenSSH Manual is worth reading if you are interested in knowing more about OpenSSH. Below is something I didn’t know before RTFM
For SSH protocol 2, Forward Secrecy (PFS) is provided through a Diffie-Hellman key agreement. This key agreement results in a shared session key (ephemeral).
OpenSSH supports the use of certificate for authentication (option
CertificateFile
).OpenSSH certificates consist of a public key, some identity information, zero or more principal (user or host) names and a set of options that are signed by a Certification Authority (CA) key. They are different, and much simpler format to the X.509 certificates used in SSL/TLS.
Verifying host key can be done using DNS and SSHFP resource record. Use
VerifyHostKeyDNS
to configure.SSH-based VPN
ssh -Q {cipher,cipher-auth,mac,kex,key,key-plain,key-cert,protocol-version}
to query supported algorithmsssh -o VisualHostKey=yes
to display a ASCII art graph of the host keysshd
Authentication internals
References
- OpenSSH Manual (RTFM)
- Secure Secure Shell
- Security Guidelines Openssh - MozillaWiki
- SSH implementation comparison
- SSH: Best practices
- OpenSSH @ Wikibooks
- O’Reilly - SSH, The Secure Shell: The Definitive Guide