Hardening SSH:

Overview:

0. Intention
1. Generate Client Key
2. Test Your Key
3. Configure Server
4. Restart Services
5. Closing Thoughts

0) Introduction & Intention

This write-up is intended to be a walkthrough for configuring and hardening SSH. I'll be configuring OpenSSH on a Debian box hosted by Digital Ocean. While there are many other great options out there, this is simply my preferred platform and should provide some fairly solid guidelines for most distributions.

1) Generate an ssh key on your local box

Instituting SSH keys is a key foundation to hardening your ssh configuration. This will be a 3 step process.

A) The first thing you need to do is generate the keypair. By default,

 ssh-keygen -t rsa -b 4096 -C "VPS to catch Meterpreter shells"

All of these arguments are optional. If you execute ssh-keygen without specifying any options, it will create a 2048-bit RSA key.

-t to set the encryption type (rsa is recommended, version 2 is the default. other options include dsa, ecdsa, ed25519, and rsa1 for rsa version 1)

-b is for the size of the key in bits. For rsa, the default size is 2048 bits. 4096 is a rather paranoid size, but it never hurts to future proof...

-C is an optional comment field. You can use this to give some context to a key. For example "Login for backdoor at EvilCorp"

-f will let you choose a file name

When given the option, enter a strong password for your key.

If you decide to remove or change that password in the future, you can do so with:

ssh-keygen -p

B) Upload your *public* key to your box. There are multipl methods to accomplish this.

• My preferred method is with ssh-copy-id

 ssh-copy-id haxor@ipaddress 

• You can cat your public key over ssh.

 cat ~/.ssh/id_rsa.pub | ssh haxor@ipaddress "mkdir -p ~/.ssh && cat >> ~/.ssh/authorizedkeys" 

• Copy/paste also works just as well. You cat/echo your key to the screen, highlight and copy it. Then just ssh into the server, open the auth

C) On your server, you should verify the permissions of the ssh folder and the authorized_keys files. You want to ensure the key is only accessible by you. Also we'll be setting the ssh server to strictmode, this will be a requirement for the keys to work anyway.

Check with:

ls -al ~/.ssh

The .ssh folder should have read/write/execute (rwx) permissions set for your user account and no permissions for anyone else. The authorized_keys file should have read/write (rw-) permissions set for your account and no permissions for anyone else. If this is not the case, you can set the permissions like this:

 
	chmod 700 ~/.ssh
	chmod 600 ~/.ssh/authorized_keys
								

2) Test Your Key

At this point, i STRONGLY recommend that you ssh into your box with your new user account, to ensure that your account and key are working properly. If you break your ssh setup, you'll have to login through a console to fix it.

 
	ssh haxor@ipaddress
	passwordy stuff....
								

3) Configure Your Server

Now that the keys have been generated and uploaded, it's time to focus on the configuration file for the ssh server. Below are the changes I recommend, along with a description of what those changes accomplish. Some of these settings may seem a little redundant but are included here anyway for completeness.

	Port 22
	AddressFamily inet
	PermitRootLogin no
	StrictModes yes
	HostbasedAuthentication no
	IgnoreRhosts yes
	PasswordAuthentication no
	PubkeyAuthentication yes
	ChallengeResponseAuthentication no
	UsePAM no
	AllowUsers haxor
	AllowGroup sshusers
	Protocol 2
								

The configuration file for the ssh server is located in /etc/ssh/sshd_config. Open this file with your preferred text editor. Within the configuration file, comments are created using a '#' symbol. Many of these options are commented out be default; you can simply delete the comment symbol to activate the option, and change it to your preferred value.

By default, SSH runs on tcp port 22. You can change this to any port you like. While may help obscure your ssh server from the casual hacker, it is important to remember that security-by-obscurity is not security at all. Additionally, this may cause issues with some security appliances that don't expect ssh traffic on non-standard ports.

Port 22

This setting instructs the server to only utilize IPv4. Alternatively, you can specify IPv6 traffic with AddressFamily inet6

AddressFamily inet

The prevents the root users from logging in via ssh. However, if a user logs in via ssh, this does NOT prevent them from becoming root via su

PermitRootLogin no

This is another setting that is set to yes by default, but we are still going to specify it. This setting tells the server to only let a user log

StrictModes yes

This is another means of using the knownhosts file for authentication. It gets disabled as we only want the ssh server to accept keys.

HostbasedAuthentication no

By default, relying on the Rhosts file should already be disabled. It is an outdated and unreliable mechanism. We will spell it out anyway, for the sake of being thorough.

IgnoreRhosts yes

This prevents users from using a password to log in. This forces the user to log in via an ssh key. However, this does NOT affect the password set on the ssh key.

PasswordAuthentication no

This is another way to force the use of ssh keys.

PubkeyAuthentication yes

Users should *never* be allowed to create accounts without a password. But even if a user did slip by, this option prevents them (and more importantly, anyone else) from logging in via ssh without a password. This is another setting to stop users from using a password to log in. This forces the user to log in via an ssh key. However, this does NOT affect the password set on the ssh key.

ChallengeResponseAuthentication no

PAM is Pluggable Authentication Module. It is another means of utilizing passwords to log in, so should also be turned off.

UsePAM no

This lets you specify precisely which users are allowed to connect via ssh. To allow more than one user, list them separated by a space, like this:

#AllowUsers haxor moarhaxor

AllowUsers haxor

Alternatively, you don't have to specify each user. You can add users to an ssh group, and tell the ssh server to only allow the group. In this case the group is called sshusers, however you can give it any name you like.

AllowGroup sshusers

Forces the server to utilize SSH version2, as version1 has some weaknesses.

Protocol 2

4) Restart the SSH Service

 sudo service sshd restart 

5) Closing Thoughts

This breakdown should hopefully give you a solid understanding of the common configurations options used to harden an SSH server. These are the settings that I recommend, although it is important to keep in mind that your needs and your environment will determine which, if any, of these recommendations work for you. You should always keep your threat model in mind when implementing configuration changes, and never blindly follow advice on the internet. Remember: Trust, but verify! Do you think I missed something? Did a step not work? Could this simply be the most bestest article you've ever seen on the interwebz? Feel free to stop by the channel and let us know what you think. You can send your flames or flattery for this article to PrettyKittie via IRC or email.

Recommended Reading

• OpenSSH Home