SSH mastery book review

I just finished reading “SSH mastery 2nd edition” by Michael W. Lucas. It was part of the “Run you own mailserver” kickstarter bundle.

He covers many of the interesting things you can do with SSH. Port forwarding, reverse port forwarding, keepalives, and more. The list of options is long.

There are a lot of options for locking down what users are allowed to do. This is configured either in the servers config file or per-user in authorized_keys (or certs). This is highly relevant for automation and service accounts.

SSH certificates are covered, and seems to be a good solution for some of the challenges I have with SSH keys. I have not been managing a fleet of hosts, so scaling issues with SSH keys have not been an issue for me yet.

Sharing SSH host keys can be done using SSHFP entries in DNS. This obviously requires DNSSEC. I am unsure when I would want to use SSHFP records. It seems like a solution for when you have a lot of people connecting to your SSH server, like they would with a web server. I am not seeing that happening any time soon.

Using SSH certificates (which is something else than “normal” x509 certificates) looks like a nice multitool for both users and hosts.

Since I am already running ansible, I can set up my servers to trust the SSH CA key, and sign other SSH host keys using that one. That will reduce the size of known_hosts.

User certs may be generated also. The book talks about a lot of the ways you can limit a user using ssh, like disabling forwarding, limiting commands, limiting login by ip and so on. This can be embedded into a certificate, so the configuration on the host is minimal.

He has the following example for a backup service user.

ssh-keygen -s user-mwlca-key -I user_backup \
 -n backup -V +52w -O clear -O \
 force-command=”/usr/local/scripts/backup.sh” backup.pub

The certificate limits the backup user to run only one command. Something like that would solve my long-standing issue about how to have centralized backup server that can use a “pull” style backup without having the master key for all hosts.

Talking about automation and SSH keys, he suggest rolling the SSH keys frequently. For my home lab, that is probably not relevant, but in production, you will be testing yous CA system and automation at regular intervals, and that makes sense. SSH certificates, as opposed to just keys, have expiry dates, and that reduces the need manual updates of authorized_keys across devices or long revocation lists.

The book is from 2017, and as with most security and software related book, there is a large caveat about obsolescence. I did know SSH in advance, and I think the book still is highly relevant. Of course you should check up on relevant changes in SSH, but the general introduction and the mindset, as well as most of the way of using it is still spot on. We have had heartbleed since then, and with the increase attention, changes have been made.

Anyway, I really must get on with my idea of making an LXC container SSH jump host. Probably with tor also, since that would make out-of-band access easy even though NAT. And also the certificate thing.