Setting up SSH – Part 3

Intro

In Part 1 of this amazing multi-part article I explained how to configure a basic SSH set-up. Part 2 dealt with PublicKey which is safer. Part 3 deals with what to do once your local machine is upgraded and you are left with a broken SSH service. Not to worry: this latest article should help set things right!

The Problem

The SSH Daemon configuration on your machine may have been wiped out during upgrade. Oops!

Rather than try to preserve this configuration during upgrade it is wiser to choose the Package Maintainer’s version as there are likely critical new parameters. Opting to keep your old configuration will mean missing out on new parameters which may have security implications. I do not recommend this.

Other options during upgrade may involve triple-diffing old and new configuration files but this is all wayyyyy beyond the scope of this article. Stay tuned for Part 4?????

Steps to Get Back on Track with SSH

The following steps should help re-configure your SSH service on a newly-upgraded machine.

Be sure take additional precautions to harden your server and its SSH configuration if you ever plan on exposing your machine outside of a local home network!

Assumptions

We are going to treat our newly-upgraded machine as the server.

The client machine and server are all connected on a home network.

Connections should be made using Ethernet cables to help assure things do not go wonky.

Wifi has a tendancy to make stuff go sideways at the absolute worst possible time.

Ask me how I know this.

You will want to have a keyboard and monitor connected to both your client and server machines.

Trust me it makes this whole thing a heck of a lot easier!

If you have a back-up of your old SSD daemon configuration on your server, now would be a good time to open this file to help restore the various configuration values.

Search ‘added’ to identify each value needing to be re-added, assuming you made comments to this effect earlier. This is where a little bit of documentation can really help!

Initial SSH Testing Following Re-configuration

Try testing your SSH log-in on server:

ssh <server_user>@<server_hostname>

Should get permission denied (PublicKey, Password) following three failed log-in attempts.

Re-edit configuration values in sshd_config on your server to temporarily allow passwords:

sudo nano /etc/ssh/sshd_config

Un-comment or insert the following values:

PermitRootLogin yes

PasswordAuthentication yes

AllowUsers <server_user> <client_user>

Cntl-O to save, Cntl-X to exit.

Re-start SSH

Re-start SSH service:

sudo service ssh restart

Attempt Connection to SSH

Try SSH log-in on server:

ssh <server_user>@<server_hostname>

You should now be logged in after entering password for <server_user>.

Try SSH log-in from client:

ssh <server_user>@<server_hostname>

You should now be logged in after entering password for <server_user>.

Log-out SSH from both server and client.

Configure PublicKey Login

Generate a new set of SSH keys on client:

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>

Specify a passphrase as applicable (no passphrase if planning on using rsync).

Hit ‘y’ for ‘yes’ to overwrite an existing PublicKey.

Copy new key to server, enter password when prompted:

ssh-copy-id -i ~/.ssh/id_rsa_<server_user> <server_user>@<server_hostname>

Re-try SSH login from client using PublicKey.

Harden SSH Configuration on Server

Edit sshd_config on server to comment-out password-based log-in values:

#PermitRootLogin yes

#PasswordAuthentication yes

Cntl-O to save, Cntl-X to exit.

Re-start SSH

Re-start SSH service:

sudo service ssh restart

Attempt Connection to SSH via PublicKey

Re-try SSH login from server using PublicKey.

Re-try SSH login from client using PublicKey.

You should not be prompted for any password if all settings were successful.

Enable SSH on Startup

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

sudo systemctl enable ssh

Troubleshooting “no route to host” Error

When attempting SSH to your server you may receive the following error:

ssh: connect to host port <port>: No route to host

If this happens there are a couple of things you can do to help resolve the issue.

Ping

Use ping <server_IP> to test the connection to your server, type Cntrl-C to stop pinging.

If you receive a response, it indicates that the network connection is working properly.

For example:

ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=8.17 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=5.86 ms
64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=1.70 ms
64 bytes from 192.168.1.1: icmp_seq=4 ttl=64 time=1.69 ms
^C
--- 192.168.1.1 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3006ms
rtt min/avg/max/mdev = 1.685/4.352/8.167/2.781 ms

Check IP Address or Hostname

Make sure that you specify the correct IP for your server.
It is possible that one server has multiple IP addresses.

Multiple connections may be used for redundancy or to communicate over different networks.

For this step you will need to be logged into your server directly such as via VNC.

Use ifconfig on your server to view one or more IP addresses of a server on a Linux system.

Check Firewall Configuration

Firewalls are great as long as they are configured properly.

Nothing like having your system locked down to the point where it is unusable!

Check to ensure you have the appropriate services allowed in your firewall rules.

There are two popular Firewall services available in Ubuntu: ufw and firewall-cmd.

Confirm ufw is running via:

sudo ufw status

Alternatively, confirm firewall-cmd is running via:

sudo firewall-cmd --state

Assuming firewall-cmd is running, confirm your services and zone via:

sudo firewall-cmd --list-all

Ensure ssh is one of the allowed services.

If you default firewall is set to ‘Public’ you likely will not have access to ssh.

You can include ssh as an allowed service in Firewall Configuration:

sudo apt install firewall-config

Perform the following steps for each connection to your home network such as wired and wireless

Provided you are on your local network you can adjust the zone to home:

Change configuration to Permanent.

• Add ssh as an Allowed Service in the Permanent configuration.
• Edit and save custom selections as ‘Home_<user>_Update’.
• Reload Firewall via ‘Options’, ‘Reload Firewalld’.
• In Terminal, confirm ssh is allowed via: sudo firewall-cmd --list-all

Once your firewall is configured, re-attempt to re-connect to your server via:

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

You should now be connected to your server if all went well with the above steps.

Additional Troubleshooting

No luck with re-configuring SSH? Here are some additional steps to try:

• Turn your client off and back on again to purge any cached keys stored in environment variables.
• 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.
• 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 both username and hostname are correct.
• Try connecting to your server from the client with a specific identity as in: ssh -o IdentitiesOnly=yes -i ~/.ssh/id_rsa_<server_user> <server_user>@<server_ip>

Postscript

If all went well you should be logged into your Server via SSH!