How to use Secure Shell tools for Secure Client Server Communication

Linux

How to use Secure Shell tools for Secure Client Server Communication

By novicejava1 0
fedora_ssh_server

Here is this article we will try to understand how to use the secure shell tools provided by OpenSSH packages for secure communication between client and server. We will check the required packages that need to be installed and the service that need to be started to make a linux machine act as a SSH server and use a set of client tools to communication with the SSH server in a secure manner.

Test Environment

Fedora 39 server (server)
Fedora 37 workstation (client)

What is OpenSSH

OpenSSH is a open source implementation of SSH (Secure SHell) protocol version 2. SSH (Secure SHell) is a program for logging into and executing commands on a remote machine. SSH is intended to replace rlogin and rsh, and to provide secure encrypted communications between two untrusted hosts over an insecure network. X11 connections and arbitrary TCP/IP ports can also be forwarded over the secure channel.

If you are interested in watching the video. Here is the YouTube video on the step by step procedure outlined below.

Procedure

Step1: Ensure OpenSSH packages installed

By default Fedora server comes is openssh packages installed and the service enabled for secure ssh communication with the linux server. There are the list of packages that are required to be installed on a Linux server to act as a SSH server.

$ sudo dnf list installed | grep -i "openssh"
openssh.x86_64                         9.3p1-9.fc39                    @anaconda
openssh-clients.x86_64                 9.3p1-9.fc39                    @anaconda
openssh-server.x86_64                  9.3p1-9.fc39                    @anaconda

The openssh packages includes the core files necessary for both the OpenSSH client and server. To make this package useful, you should also install openssh-clients, openssh-server, or both. The openssh-clients package includes the clients necessary to make encrypted connections to SSH servers. The openssh-server package contains the secure shell daemon (sshd). The sshd daemon allows SSH clients to securely connect to your SSH server.

If the above packages are not installed on a linux server. You need to install as shown below.

$ sudo dnf install openssh openssh-clients openssh-server

Step2: Ensure SSH daemon running

By default on Fedora server the sshd daemon is enabled for startup of reboot and its up and running as shown below.

$ sudo systemctl status sshd.service 
● sshd.service - OpenSSH server daemon
     Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled; preset: enabled)
    Drop-In: /usr/lib/systemd/system/service.d
             └─10-timeout-abort.conf
     Active: active (running) since Mon 2023-11-27 04:12:10 IST; 5h 14min left
...

If the above service is not running. You can start and enable the service on startup as shown below.

$ sudo systemctl start sshd.service
$ sudo systemctl enable sshd.service

By default on Fedora server the SSH port 22 is open and host public and private keys are located at the following location.

$ ls -ltr /etc/ssh/*key*
-rw-r--r--. 1 root root  162 Nov 25 05:49 /etc/ssh/ssh_host_ecdsa_key.pub
-rw-------. 1 root root  492 Nov 25 05:49 /etc/ssh/ssh_host_ecdsa_key
-rw-r--r--. 1 root root   82 Nov 25 05:49 /etc/ssh/ssh_host_ed25519_key.pub
-rw-------. 1 root root  387 Nov 25 05:49 /etc/ssh/ssh_host_ed25519_key
-rw-------. 1 root root 2578 Nov 25 05:49 /etc/ssh/ssh_host_rsa_key
-rw-r--r--. 1 root root  554 Nov 25 05:49 /etc/ssh/ssh_host_rsa_key.pub

Step3: SSH Remote Server

Assuming you have a freshly installed Fedora server with a user account named “admin” already created.

Now if we try to SSH onto this remote server for the first time from the client machine, it will prompt us to if we are sure to connect to this server. By default, all of the SSH-related tools authenticate using standard Linux usernames and passwords, all done over encrypted connections.

SSH also supports key-based authentication, which can be used to configure key-based and possibly passwordless authentication between clients and SSH servers.

$ ssh admin@fedres.stack.com 
The authenticity of host 'fedres.stack.com (192.168.122.6)' can't be established.
ED25519 key fingerprint is SHA256:Hiq/UmlHFNUXG6RBCSg3YyomwpZAIS+uyyXJjsAgt9M.
This key is not known by any other names
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'fedres.stack.com' (ED25519) to the list of known hosts.
admin@fedres.stack.com's password: 
Web console: https://fedres.stack.com:9090/ or https://192.168.122.6:9090/

Last login: Sun Nov 26 22:42:24 2023 from 192.168.122.1
[admin@fedres ~]$

For the first time login when you accept to connect to the remote server. The remote server public key (ie. /etc/ssh/ssh_host_rsa_key.pub) is added on the client machine in the client’s ~/.ssh/known_hosts file as shown below.

$ cat ~/.ssh/known_hosts | grep fedres
fedres.stack.com ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIC/kKtMv+RfFB8b7akylzYnyEhnoWWXSFgROSXrWzLVR
fedres.stack.com ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQC0n6DscwXg9n7n6zIswvIayqXeUSlz9WbvGnbP0uAZps+/EvAsPmRilg4gqUe56qvwd/T9abyKf9y8ko9pTkW26iKmUfbigobH25PH3UAWeSZoIuGTDFdr1deCWWDHGkdtmUkccXZBaavxLR9NnxXqYfeQmRX45ZPvR8Fkm1YRXPAkhRF+oQ6bM0AEDf/7ptu3QzjHQDSszXRHb9sf7BxQuVnv5yURtXH27CFv6UXekPzt2VN4bw376dWyAa3rJUBZpoo0IEfdc6MEs9BAZimHN+BFnvAstvJxfASsvdsVCtXUaSJNWFjZmyjy2UfLJhCHci/l+LvQBFnIFZRi/w0ChVD/cNhhqV/kp528OnrIsNb7mt77CX6dDob/o8EwHMh1baK0Iw2yiTpMHQE9Htp7NQGFHTA21enUsRv5xfzvhyswJyF43x8vblGHCCC61yIgUuNFXSGbSqJXyOYX/wobVAdphJ9khTHifJ97ZjzGqmUEniiwwrIvZK6I/PBuiMk=
fedres.stack.com ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBFMPKnLqnrgXyz2pw7pw/hgoEi3vcT4WE3pc0Z7blCWbIkow+5+fnn7/2zlyJxuRZbFLI+CCEvzYOfCTkHE/H54=

Step4: Secure Copy

SSH utilities provides us with two tools (ie. scp and rsync) for file copy from client to server or source to destination. These tools provide a secure encrypted communication between the two parties.

$ scp /etc/redhat-release admin@fedres.stack.com:/tmp/
admin@fedres.stack.com's password: 
redhat-release

We can also do a recursive copy of files and folders in a directory using the “-r” option as shown below.

$ scp -r /usr/share/man/man1/ admin@fedres.stack.com:/tmp/

scp tool can also be used as a backup utility but there are a few drawbacks which are.

  • Attributes lost
  • Symbolic links lost
  • Copy repeated unnecessarily

The rsync command is a better network backup tool because it can overcome some of the shortcomings of scp just listed.

$ rsync -avl /usr/share/man/man1/ admin@fedres.stack.com:/tmp/mandata/
  • a (recursive archive)
  • v (verbose)
  • l (copy symbolic links)

rsync preservers the permission attributes, symbolic links and does not carry out a duplicate copy of the files.

Step5: Secure FTP

SFTP is useful if we want to navigate the remote server filesystem and upload or download files to/from the remote server as shown below.

$ sftp admin@fedres.stack.com

Now you can try to download a file from the remote server. Here we are trying to download the “redhat-release” file from the remote server. This download file will be present in the current working directory from where the SFTP session was initiated.

sftp> get /etc/redhat-release

Step6: Key Based Authentication (Passwordless)

Until now the remote session that we were able to acquire required us to authentication with the remote user’s password. But as mentioned previously SSH also supports key based or password less authentication to the remote server.

For this we first need to generate the SSH keypair on the client machine using the below.

$ ssh-keygen

Once the SSH public and private key pair is generated. We need to copy the public key across to the user account on the remote host to which you want to do key-based authentication as shown below.

$ ssh-copy-id -i ~/.ssh/id_rsa.pub admin@fedres.stack.com
...
Number of key(s) added: 1

Now try logging into the machine, with:   "ssh 'admin@fedres.stack.com'"
and check to make sure that only the key(s) you wanted were added.

The key’s that are authorized for remote SSH session without password are added to the following location on the remote server.

$ cat ~/.ssh/authorized_keys

Once the public key is copied to the required user accounts location. The remote SSH service compares the public key and the private key and allows you access if the two keys match as shown below.

$ ssh admin@fedres.stack.com 
Web console: https://fedres.stack.com:9090/ or https://192.168.122.6:9090/

Hope you enjoyed reading this article. Thank you..