Managing Secure Connections with SSH

ssh - Secure Shell

SSH or Secure Shell is a network protocol that allows data to be passed between two networked servers using a secure channel. The main use for ssh is to obtain a secure remote shell on a networked server, however, it is also commonly used for copying files between servers (SCP). To use ssh to obtain a secure remote shell, the remote shell must be running "sshd" (secure shell daemon). Generally "ssh" uses "port 22" for its communication, however, many system administrators will change to an alternative port as a means of adding extra security. Changing the port however doesn't offer much in security gains. If you need to secure your ssh communications you should consider using a firewall to only allow known traffic.

On Linux the general implementation of ssh is known as "OpenSSH". Most modern Linux distributions should have OpenSSH installed by default. The standard location for OpenSSH configuration files is "/etc/ssh". Here you will find the ssh_config file for the client side and the sshd_config file for the server side.

Below is an example of the files found under "/etc/ssh on a CentOS system.


# cd /etc/ssh

# ls -l
total 600
-rw-r--r--. 1 root root     577388 Apr 27  2020 moduli
-rw-r--r--. 1 root root       1770 Apr 27  2020 ssh_config
drwxr-xr-x. 2 root root         28 Apr  5 14:25 ssh_config.d
-rw-------. 1 root root       4269 Apr 27  2020 sshd_config
-rw-r-----. 1 root ssh_keys    480 Apr  5 14:31 ssh_host_ecdsa_key
-rw-r--r--. 1 root root        162 Apr  5 14:31 ssh_host_ecdsa_key.pub
-rw-r-----. 1 root ssh_keys    387 Apr  5 14:31 ssh_host_ed25519_key
-rw-r--r--. 1 root root         82 Apr  5 14:31 ssh_host_ed25519_key.pub
-rw-r-----. 1 root ssh_keys   2578 Apr  5 14:31 ssh_host_rsa_key
-rw-r--r--. 1 root root        554 Apr  5 14:31 ssh_host_rsa_key.pub

Generating a SSH key

SSH gives you the ability to create keys that can be exchanged with other servers which allow you access without having to type a password. The utility for creating these keys is called "ssh-keygen". To create a key quickly we can simply issue the command "ssh-keygen -t rsa". This will then step through several interactive prompts asking for confirmation or for additional information to be entered. Below is an example of a "Public Key" being generated.

The following key has been generated on a Linux Mint system.


tux@mint01a:~$ ssh-keygen -t rsa

Generating public/private rsa key pair.
Enter file in which to save the key (/home/tux/.ssh/id_rsa): 
Created directory '/home/tux/.ssh'.
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/tux/.ssh/id_rsa
Your public key has been saved in /home/tux/.ssh/id_rsa.pub
The key fingerprint is:
SHA256:QdfQJfNmO2eixOQOrjKYKcmsVNbPdpJ+C8VGev10BhI tux@mint01a
The key's randomart image is:
+---[RSA 3072]----+
|        . oEo..  |
|       . .  ++   |
|        .. ...+  |
|    .   +..+.o.. |
|   o . .S=..+.+oo|
|  o   o =. +o.o= |
| + . + B .. o.   |
|. = + = +o       |
|.. .   +o..      |
+----[SHA256]-----+

In the above example we chose to use the "rsa" (Rivest, Shamir, Adleman) algorithm to create our digital signature. We could have chosen "dsa". Next we were prompted to supply a directory where we would like the key to be saved. In the example I pressed "Enter" to accept the default location of "/home/tux/.ssh/id_rsa". Next, We were asked to enter a passphrase. I chose not to enter a passphrase. All that is required now is to distribute our public key to our desired remote server.


tux@mint01a:~$ cd /home/tux/.ssh

tux@mint01a:~/.ssh$ ls -l
total 8
-rw------- 1 tux tux 2602 May 23 11:32 id_rsa
-rw-r--r-- 1 tux tux  565 May 23 11:32 id_rsa.pub

Copying Public keys to remote servers

In the above example of the "ssh-keygen -t rsa" command we can see that a public key was created.

My public key has been saved in /home/tux/.ssh/id_rsa.pub

To use the public key, we have to first copy the contents of the file "id_rsa.pub" to a file called "authorized_keys" on the remote server. Whenever copying a new key to a remote servers authorized_keys file, always use the append option. If you copy your files content, you could overwrite the file and destroy any other keys that may be located there. The easiest way to transfer the key to the remote server is to issue a command similar to the one below.

Note, the "authorized_keys" key file must already exist on the remote server under the account you are logging into.

In the example below, I will create the directory structure and authorized_keys file on the remote server as follows:


[tux@centos8a ~]$ pwd
/home/tux

[tux@centos8a ~]$ ls -al
total 12
drwx------. 2 tux  tux   62 May 23 11:31 .
drwxr-xr-x. 4 root root  29 May 23 11:31 ..
-rw-r--r--. 1 tux  tux   18 Jul 21  2020 .bash_logout
-rw-r--r--. 1 tux  tux  141 Jul 21  2020 .bash_profile
-rw-r--r--. 1 tux  tux  376 Jul 21  2020 .bashrc

[tux@centos8a ~]$ mkdir .ssh

[tux@centos8a ~]$ chmod 700 .ssh/

[tux@centos8a ~]$ cd .ssh
[tux@centos8a .ssh]$ touch authorized_keys

[tux@centos8a .ssh]$ chmod 600 authorized_keys 

[tux@centos8a .ssh]$ ls -l
total 0
-rw-------. 1 tux tux 0 May 23 11:46 authorized_keys

Note, I had to create the ".ssh directory first, set its permissions to "700" and then create the empty "authorized_keys" file using the "touch" command. The permissions on the "authorized_keys" file are also set to "600".

Once the above is in place, I can copy the contents of our public key to this file.


$ cat $HOME/.ssh/id_rsa.pub | ssh 192.168.122.75 'cat >> .ssh/authorized_keys && echo "Contents Copied Successfully"'
tux@192.168.122.75's password: 
Contents Copied Successfully

The above command simply appends the key on our local server to the "authorized_keys" file on the remote server. (Amend IP address to match your remote server)

Testing Access

Once the public key has successfully been copied to the correct location on the remote server, you should now be able to login to the remote server without specifying a password.


tux@mint01a:~$ ssh 192.168.122.75
Last login: Sun May 23 11:45:49 2021

[tux@centos8a ~]$ uname -n
centos8a

From the above, we can see that we were able to login successfully without being prompted for a password. I then issued the command "uname -n" to confirm the identity of the remote connection.

ssh -vvv - debugging the authentication process

If you would like to see the authentication process in action we can add an extra parameter to the "ssh" command. By adding "-v" to the ssh command we get "verbose" output of the authentication process. If we add an extra "v" so that we now have "-vv" we get "very very verbose" output. And if we were to add another "v" to the command we get, you guessed "very very very verbose" output. Below is an example of the "-v" option being used. (If you are having problems authenticating, it is always a good idea to use these flags to help with debugging):


tux@mint01a:~$ ssh -v 192.168.122.75
OpenSSH_8.2p1 Ubuntu-4ubuntu0.2, OpenSSL 1.1.1f  31 Mar 2020
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: include /etc/ssh/ssh_config.d/*.conf matched no files
debug1: /etc/ssh/ssh_config line 21: Applying options for *
debug1: Connecting to 192.168.122.75 [192.168.122.75] port 22.
debug1: Connection established.
debug1: identity file /home/tux/.ssh/id_rsa type 0
debug1: identity file /home/tux/.ssh/id_rsa-cert type -1
debug1: identity file /home/tux/.ssh/id_dsa type -1
debug1: identity file /home/tux/.ssh/id_dsa-cert type -1
debug1: identity file /home/tux/.ssh/id_ecdsa type -1
debug1: identity file /home/tux/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/tux/.ssh/id_ecdsa_sk type -1
debug1: identity file /home/tux/.ssh/id_ecdsa_sk-cert type -1
debug1: identity file /home/tux/.ssh/id_ed25519 type -1
debug1: identity file /home/tux/.ssh/id_ed25519-cert type -1
debug1: identity file /home/tux/.ssh/id_ed25519_sk type -1
debug1: identity file /home/tux/.ssh/id_ed25519_sk-cert type -1
debug1: identity file /home/tux/.ssh/id_xmss type -1
debug1: identity file /home/tux/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.2p1 Ubuntu-4ubuntu0.2
debug1: Remote protocol version 2.0, remote software version OpenSSH_8.0
debug1: match: OpenSSH_8.0 pat OpenSSH* compat 0x04000000
debug1: Authenticating to 192.168.122.75:22 as 'tux'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC:  compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC:  compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:EkKgxlJwA8ad3pGQV49yoIJkvW1xGP8vZ3MaIoHAS64
debug1: Host '192.168.122.75' is known and matches the ECDSA host key.
debug1: Found key in /home/tux/.ssh/known_hosts:1
debug1: rekey out after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey in after 134217728 blocks
debug1: Will attempt key: /home/tux/.ssh/id_rsa RSA SHA256:QdfQJfNmO2eixOQOrjKYKcmsVNbPdpJ+C8VGev10BhI
debug1: Will attempt key: /home/tux/.ssh/id_dsa 
debug1: Will attempt key: /home/tux/.ssh/id_ecdsa 
debug1: Will attempt key: /home/tux/.ssh/id_ecdsa_sk 
debug1: Will attempt key: /home/tux/.ssh/id_ed25519 
debug1: Will attempt key: /home/tux/.ssh/id_ed25519_sk 
debug1: Will attempt key: /home/tux/.ssh/id_xmss 
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure.  Minor code may provide more information
No Kerberos credentials available (default cache: FILE:/tmp/krb5cc_1001)


debug1: Unspecified GSS failure.  Minor code may provide more information
No Kerberos credentials available (default cache: FILE:/tmp/krb5cc_1001)


debug1: Next authentication method: publickey
debug1: Offering public key: /home/tux/.ssh/id_rsa RSA SHA256:QdfQJfNmO2eixOQOrjKYKcmsVNbPdpJ+C8VGev10BhI
debug1: Server accepts key: /home/tux/.ssh/id_rsa RSA SHA256:QdfQJfNmO2eixOQOrjKYKcmsVNbPdpJ+C8VGev10BhI
debug1: Authentication succeeded (publickey).
Authenticated to 192.168.122.75 ([192.168.122.75]:22).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: pledge: network
debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0
debug1: Remote: /home/tux/.ssh/authorized_keys:1: key options: agent-forwarding port-forwarding pty user-rc x11-forwarding
debug1: Remote: /home/tux/.ssh/authorized_keys:1: key options: agent-forwarding port-forwarding pty user-rc x11-forwarding
debug1: Sending environment.
debug1: Sending env LANG = en_GB.UTF-8
Last login: Sun May 23 12:00:18 2021 from 192.168.122.1