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"' email@example.com'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)
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: firstname.lastname@example.org MAC:
compression: none debug1: kex: client->server cipher: email@example.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 firstname.lastname@example.org debug1: Entering interactive session. debug1: pledge: network debug1: client_input_global_request: rtype email@example.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