Mark Loveless, aka Simple Nomad, is a researcher and hacker. He frequently speaks at security conferences around the globe, gets quoted in the press, and has a somewhat odd perspective on security in general.

Locking Down Accounts

Locking Down Accounts

Mark Loveless
The Network

Photo by Jonathan Chng on Unsplash

I have several public-facing Linux servers, and one of the things I do to protect these servers is to lock down the user accounts. I use a combination of complex passwords, SSH public key authentication, and for Multi-Factor Authentication (MFA) I use Duo Security's Duo Unix with PAM support. This way I do not use my Linux password for SSH access and rely on the SSH key, and I still get the benefit of MFA. With this setup, if I have to use “sudo” I not only have to enter in my Linux password, I am again prompted to use Duo's MFA.

Obviously this is not a 100% guarantee against some type of security breach, but it is a nice step forward in account security. I'll go over my configuration so you can get an idea of how to set things up yourself. Bear in mind I’m running Ubuntu Server 22.04, although one of the internal systems I'm using is Ubuntu Desktop 22.04. It works out the same either way. Also note that my client is also Linux.

If you just want to see config files, you can go here, otherwise the same info is more or less discussed in this blog post.

Prepwork

These are the steps I do whenever I change or update the authentication system. If you are going to do such changes, I'd advise the following to prevent locking yourself out of your own server (don’t ask me how I know this). Here are the steps.

  • Have one terminal active on the system you are changing at all times. It should already be running root, so if you mess things up you can fix it. This is your "break glass" scenario, and it is especially important if you are configuring and updating a remote system (such as a hosted server).

  • Have a second terminal that is used solely to test the remote connection. Each time you edit a file or restart your SSH daemon, you'll want to test things out, noting (and Googling) errors.

  • Your third terminal is a terminal into the system where you are making changes. Use it solely for changes.

  • Before you alter a configuration file, make a copy of the file with the current date in the name. This way you have a backup of a known working copy of your config file. Do this for every file you are going to edit.

SSH Public Key Authentication

My SSH file is near the end of the blog in its entirety, and it includes the bits needed to get public key authentication going. If you’ve never done it before, feel free to Google for particulars, but you can also use the settings below as a method to get things working in a fairly locked down state.

I create a keypair on the client using ssh-keygen. I’ve included both a fairly secure option and a FIPS-compliant option, I personally use the former on home systems. For the ED25519 key, I increase the KDF (Key Derivation Function) rounds to 64 from the default of 16 via the “-a” option, which makes it more resistant to brute force attacks (yes this is probably overkill, old habits and all). Note that the -C option can be anything you'd like as it is a comment:

$ ssh-keygen -a 64 -t ed25519 -f ~/.ssh/id_ed25519 -C "ED25519 Key"
$ ssh-keygen -t rsa -b 4096 -f ~/.ssh/id_rsa -C "RSA FIPS-compliant Key"

While I know one can manually upload the key, I typically use ssh-copy-id which will by default upload the last key created:

$ ssh-copy-id user@install.key.to.this.server

If you want more details on either command, try man ssh-keygen and man ssh-copy-id respectively (or search Google). Once I have everything set, I test out my setup to ensure everything is working fine and I can SSH into the system.

Adding Duo Unix

I usually install the Duo Unix software from source. You can find all of the instructions on how to do this here. It doesn’t give all of the prerequisites you need, so I make sure I install the following packages (again note this is for Ubuntu):

$ sudo apt install make gcc libssl-dev libpam-dev

I had to comment out an existing line in /etc/pam.d/common-auth and two lines added underneath. I had to use the full path to pam_duo.so so PAM can find it.

.
.
.
#auth   [success=1 default=ignore]      pam_unix.so nullok
auth    requisite       pam_unix.so nullok_secure
auth    [success=1 default=ignore]      /lib64/security/pam_duo.so
.
.
.

Since SSH public key authentication is being used, /etc/pam.d/sshd needs an existing line commented out and three lines added underneath. Again, the full path to pam_duo.so is included.

.
.
.
#@include common-auth
auth  [success=1 default=ignore] /lib64/security/pam_duo.so
auth  requisite pam_deny.so
auth  required pam_permit.so
.
.
.

I run a mail server, and clients use IMAPS to retrieve mail (from the internal network only). The authentication is done via dovecot, and as there is no way to use Duo Unix with dovecot, the authentication will fail. To correct this, I had to edit the /etc/pam.d/dovecot file. Three lines were commented out, and two were added.

.
.
.
#@include common-auth
#@include common-account
#@include common-session
auth    required        pam_unix.so nullok
account required        pam_unix.so
.
.
.

The Whole File

The stock /etc/ssh/sshd_config is filled with every possible feature listed as a comment, so I've simply listed my sshd_config as it is easier than trying to explain each and every line. Basically, I've included everything I turn off that is on by default that I don't want, and everything needed for public key authentication and Duo Unix to work.

Probably the thing that will raise the most eyebrows is the “protocol adjustment” section. I specify Protocol 2 as ages ago I was trying to prevent certain attacks that SSHv1 uses. SSHv2 is much safer with a number of advances over SSHv1. I don’t know if this is still considered a valid attack vector, but I’ve left it in as it certainly doesn’t hurt.

My choices for ciphers and algorithms are also to prevent potential attacks. Granted, access to the servers from the open Internet are limited, but there are some NMRC members that access the system remotely, so it is not like I’ve completely shut off SSH traffic from the outside, and considering NMRC’s history and some of the attackers we have faced, it seems like the right choice.

#
# The NMRC sshd config file. This works with Duo using PAM.
#
PubkeyAuthentication yes
PasswordAuthentication no
ChallengeResponseAuthentication yes
UsePAM yes
UseDNS no
AllowTcpForwarding no
X11Forwarding no
PrintMotd no
PermitTunnel no
# For Duo to work:
ForceCommand /usr/sbin/login_duo
# Allow client to pass locale environment variables
AcceptEnv LANG LC_*
# override default of no subsystems
Subsystem       sftp    /usr/lib/openssh/sftp-server
# NMRC-specific protocol adjustments
Protocol 2
Ciphers aes128-ctr,aes192-ctr,aes256-ctr
HostKeyAlgorithms ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521
KexAlgorithms ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521
Macs hmac-sha2-256,hmac-sha2-512

Conclusion

These settings provide a solid base for Linux account security for remote access. Having these particular settings has a side benefit of invoking Duo Unix whenever I run sudo. Like I said, this doesn’t fix everything on every system, but every bit of improvement helps.

Solar Frequently Asked Questions

Solar Frequently Asked Questions
A Real Look at EMPs

A Real Look at EMPs