Setting up SSH - Part 2 – steadynotion.com

In Part 1 of this article I do a quick walk-through to set up a very basic SSH configuration. Part 2 picks up the pace by learning how to connect via PublicKey on Ubuntu. This is a better option than relying on a SuperUser password to remote-in.

Initial Set-up

Log-in to your server using a monitor and keyboard.

You can also log-in via password-based SSH assuming you have configured it in Part 1 of this article.

Run ssh -V to check the OpenSSH version.

If not already installed, install openssh-server via:

sudo apt install openssh-server

Confirm SSH is running:

sudo service ssh status

Edit Configuration for SSH Service

Edit the SSH daemon configuration via:

sudo nano /etc/ssh/sshd_config

Enter or adjust the following values:

# Added YYYY-MM-DD by <author>.
PermitRootLogin no
PermitEmptyPasswords no
PubKeyAuthentication yes
PasswordAuthentication yes
AllowUsers <user_1> <user_2> etc
# AllowGroups ...

Save by hitting Cntl-O then Cntl-X to exit.

Confirm the values you changed in sshd_config are GTG:

sudo sshd -t

Re-open and correct any syntax errors in the config file as appropriate, then save and close.

Restart your SSH daemon:

sudo service ssh restart

Confirm SSH is working on your server via:

ssh -v localhost

Next, try to connect to your server from a client on the local network via:

ssh -v <server_user>@<server_ip>

You *should* be able to specify <server_hostname> in lieu of <server_ip> provided it is configured in Client Settings in your router.

If you do not get ‘Welcome to blah blah’ message in the above tests, proceed with Troubleshooting.

Generate Keys on Client

From your client, generate a new set of SSH keys via:

ssh-keygen

During key generation, specify the path and rename the new key file along the lines of:

/home/<client_user>/.ssh/id_rsa_<server_user>

Choose a passphrase or leave blank if majority of connection will be done via services such as rsync.

Generate a secondary key such as /home/<client_user>/.ssh/id_rsa_<server_user_wifi> if there is an alternate connection to the server via WIFI.

Copy New Key to Server

Copy new key to the server via:

ssh-copy-id -i ~/.ssh/id_rsa_<server_user> -o 'IdentitiesOnly=yes' <server_user>@<server_IP>

The embedded option 'IdentitiesOnly=yes' specifies which file(s) the SSH agent should look for. With this value set, SSH will only look for specific identities such as those listed on the command line. Any of the identities automatically provided by the SSH agent will be ignored.

(Optional) Copy Secondary Key to Server

Copy secondary key to server via:

ssh-copy-id -i ~/.ssh/id_rsa_<server_user_wifi> -o 'IdentitiesOnly=yes' <server_user>@<server_IP_wifi>

Connect to Server

We should now be at a point where:

SSH keys are generated, and
SSH PublicKey is issued to the server.

ssh -o IdentitiesOnly=yes -i ~/.ssh/id_rsa_<server_user> <server_user>@<server_ip>

You will be asked for your passphrase assuming you set one up.

The system should log-in without issue.

Attempt SSH log-in with the alternate PublicKey provided you have configured it.

See Troubleshooting section if there are issues with logging in via PublicKey.

Disable Password Log-in for SSH

With PublicKey enabled it is time to harden SSH by disabling password-based log-in.

Log-in via SSH from your client then edit the SSH daemon configuration on your server via:

sudo nano /etc/ssh/sshd_config

Important: If you already have your sshd_config file open on your server, you will get the following notification: File /etc/ssh/sshd_config is being edited by root (with nano 6.2, PID 25121); open anyway? Save then close the version on your server before attempting to modify it through an SSH session on your client!

Edit the following section you inserted earlier in this tutorial:

# Modified YYYY-MM-DD by <author>.
PermitRootLogin no
PermitEmptyPasswords no
PubKeyAuthentication yes
PasswordAuthentication no
AllowUsers <user_1> <user_2> etc
# AllowGroups ...

Hit Cntl-O to save, Cntl-X to exit then restart your SSH daemon:

sudo service ssh restart

Log-out and log-in to a new SSH session from the client to confirm PublicKey still works.

You may get a message prompting you to restart your machine:

*** System restart required ***

If this happens you can do:

sudo /sbin/reboot

Wait for your server to reboot and then re-attempt log-in via SSH.

Enable SSH on Startup

Configure your server to run SSH daemon on start-up via:

sudo systemctl enable ssh

PublicKey Troubleshooting

There are a few things you can try not if but when things go sideways during your initial PublicKey set-up. Speak with your System Administrator before deleting any items from your client or server!

SSH is very finnicky about log-ins, as well it should be.

Mis-configured IP address: If your server is brand-new (or has recently been re-imaged), the Client Settings in your router may not be configured properly. Visit the Client Settings page in your router to ensure the alias (ie: <server_hostname>) are set along with a static IP. Set these if not already done so, then re-boot your server. Refresh the Client Settings page to confirm the static IP as assigned by your router, then make changes as appropriate to the SSH settings in your client.

The Stale Hostname Problem

During authentication you may receive cryptic error messages.

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

Remove stale hostnames via:

ssh-keygen -f "/home/<client_user>/.ssh/known_hosts" -R "<server_ip>"

Too many Authentication Failures

You may receive a Too Many Authentication Failures error. If this occurs, specify -o IdentitiesOnly=yes when attempting to SSH into your server:

ssh -o IdentitiesOnly=yes <server_user>@<server_ip>

Additional Troubleshooting

Still no luck with SSH’ing into your server using PublicKey? Here are some additional steps to try:

Confirm SSH is running on server: sudo service ssh status
Restart SSH on server: sudo service ssh restart
Delete authorized_keys on the server, they are located in the /.ssh folder.
Delete your OpenSSH keys from the Ubuntu Passwords and Keys aka seahorse app on your client.
Turn your client off and back on again to purge any cached keys stored in environment variables.
Re-generate keys for the server and client, use nil passphrase by hitting enter when prompted.
Use ssh-add -l to confirm newly-generated keys, ensure that both username and hostname are correct.
Try connecting with a specific identity as in: ssh -o IdentitiesOnly=yes -i ~/.ssh/id_rsa_<server_user> <server_user>@<server_ip>

Postscript

I strongly recommend you take additional steps to harden your system following this tutorial, particularly when it comes to SSH. There are several posts that go into further detail in this regard such as this one. And also this. This one too.

What steps have you taken to set up SSH on your server?

Setting up SSH – Part 2