The SSH Protocol

#ssh

(This Blog post is part of a collaborative work between Me and Mustapha El Idrissi, Consult his devTo page for more information: https://dev.to/appsbymuss)

What is SSH

Secure Shell (SSH) is a cryptographic network protocol used for secure data communication, remote shell services, and command execution between two networked computers. Developed as a replacement for older, less secure protocols like Telnet and rlogin, SSH provides a robust layer of security by encrypting the connection and ensuring data integrity.

SSH is widely used in various domains, including system administration, software development, and network engineering. It enables administrators to manage servers, configure devices, and transfer files securely over an insecure network. The protocol is also instrumental in automating scripts and processes, making it a critical tool in modern IT environments.

One of the most significant advantages of SSH is its ability to facilitate secure remote access. By using SSH, users can log into remote machines, execute commands, and manage systems as if they were physically present, all while maintaining a high level of security. This feature is particularly valuable in today's distributed work environments, where remote access to servers and devices is a necessity.

Setting up an OpenSSH server

An OpenSSH server is setup in a way that a machine can be accessed using the SSH protocol.
It can be setup on any Windows, Macintosh or Linux machine.
To set it up on a Linux machine of the Ubuntu distro, we must install the necessary packages.

1- Update Package List

sudo apt update

2- Install OpenSSH

sudo apt install openssh-server

3- Adjust firewall rules (Optional, but Highly encouraged due to security concerns)

# This allows incoming traffic on OpenSSH (by default it's port 22)
sudo ufw allow ssh
# If the port is changed (not 22), Do this instead:
sudo ufw allow <custom_port_for_openssh>

# This enables the Host-Firewall if it isn't enabled yet.
sudo ufw enable

4- Turning ON the Service

# For systemctl machines:
sudo systemctl start ssh
# otherwise
sudo service ssh start

Server-Side Configuration

On Debian-based machines, the configuration file can be found in: /etc/ssh/sshd_config

# by default
Port 22
MaxAuthTries 10
MaxSessions 5
PasswordAuthentication yes
PubkeyAuthentication no

Banner none
X11Forwarding no

Port: We can choose a port (as long as it isn't being used by another service) from 1 to 65535
MaxAuthTries: is an important parameter for controlling how many times a client can attempt to authenticate before being disconnected. Setting it to a reasonable value helps improve the security of your SSH server by reducing the risk of unauthorized access through brute-force attacks.
MaxSessions: this is a SSH server parameter that limits the number of simultaneous sessions a single SSH connection can establish.

PasswordAuthentication: choose if a user can or can not authenticate to the server with a password.
PubkeyAuthentication: choose if a user can or can not authenticate to the server with a Private key (which is from a previously generated Public/Private key value pair).
Banner: This parameter isn't really of any security meaning, but rather one could customize their server's welcoming Banner.
If set, it should point to the file that should be echo'ed, otherwise leave it as "none"
X11Forwarding: This allows users to have the GUI apps on the remote server virtually executed on the actual Host machine using something called the "X Window System".
AllowTcpForwarding: This setting allows TCP forwarding, which means that users can create SSH tunnels to forward arbitrary TCP connections over the SSH connection. This is used for port forwarding, which includes both local and remote forwarding.

-> Example: You have mysql-server installed on the remote server, but you didn't expose the port of that mysql server outside of that machine (one can't connect to it with a GUI tool remotely with a Client tool like "MySQL Workbench"), and instead of making the port of that DB service exposed, we just want to use the mysql-workbench gui app on the remote machine itself, and have that graphical interface "forwarded" to us to see and manipulate. X Window comes in handy here.

at the end, we need to restart the openssh server:
sudo service ssh restart

SSH Key Management (PubkeyAuthentication)

When it comes to Authentication in SSH, there's multiple ways, such as Password, Public Key and PAM.
When it comes to "PubkeyAuthentication" (which is the more secure option than Password), we are talking about Asymmetric Encryption, Public and Private key pairs.
In order to securely authenticate as a user to an SSH server, asymmetric encryption is used.
To utilize this method of Authentication, the user should add this modification to the SSH server's config file: PubkeyAuthentication yes

The user has to generate a key pair, and then they have to append the contents of the "public key" to the end of the server's "authorized_keys" file.

Client Setup

1- Generate Key Pair

ssh-keygen -t rsa/ecdsa/ed25519... -b 2048 -c "email@gmail.com"

-t: This parameter specifies which asymmetric encryption algorithm to use, there are multiple such as rsa, ecdsa ect...
-b: This parameter specifies the number of bits of the key (the correct values depend on which algorithm is choosen, ex: rsa accepts "2048" or "4096".
-c (optional): you can associate a custom description with your key, ex: Your email.

2- Once it is generated, by default the private and public keys are both gonna be in under the "USERNAME/.ssh" folder, That means:
- C:/Users/USERNAME/.ssh (on Windows)
- /home/USERNAME/.ssh (on Linux)

The Public key is the one with the extension ".pub" and the Private one is the one without any extension. ex: id_rsa and id_rsa.pub

3- Once generated, we need to declare it to the SSH server, in a way that we add Our Public key to the SSH Server's "whitelist" (aka the authorized_keys file).

The process is fairly simple, we have to copy the content of the Public key, and add it to the SSH Server's "authorized_keys" file.

Since we have Linux as our SSH Server, there's already a command that could faciltate this process:

ssh-copy-id -i ~/.ssh/mykey.pub user@remote_host

-i: specifies the path to the public key that has to be allowed by the SSH Server

4- We can then easily connect to our SSH Server with our private key like so:

ssh -i ~/.ssh/myprivatekey user@remote_host

-i: specifies the path to the private key

5 (optional)- We can create a file that remembers the key path with its correspondant username and remoteHost ect with config:

This "config"-named file has to be created in the ".ssh" folder that we previously discussed.
The contents are like so:

Host customHost1
  User ubuntu
  HostName test.host.com
  Port 22

Host customHost2
  User ubuntu
  HostName test2.host.com
  IdentityFile PATH/TO/id_rsa
  IdentitiesOnly yes

Host customHost3
  User root
  HostName server.mydomain.tech
  IdentityFile PATH/TO/id_rsa

Host: This defines the "profile" or "alias" to connect to a specific server with a specific Hostname ect..
User: Specify the username
HostName: Specify the hostname (or host ip)
Port: Specify the port (if not specified, PORT 22 is assumed)
IdentityFile: Set the Path of where the Private Key is. (If the server uses PubKeyAuthentication)

LocalForward: The LocalForward parameter sets up a local port on your machine to forward to a port on a remote machine. This is known as "port forwarding" or "tunneling" and is often used to access services running on a remote machine as if they were running locally.
(syntax: LocalForward <local_port> <remote_host>:<remote_port>)
RemoteForward: The RemoteForward parameter works similarly to LocalForward, but in the opposite direction. It forwards a port on the remote machine to a port on your local machine. This can be useful for making services on your local machine accessible to the remote machine.
(syntax: RemoteForward <remote_port> <local_host>:<local_port>)
DynamicForward: The DynamicForward parameter sets up a local port to act as a SOCKS proxy. When you connect to this port, SSH will dynamically forward the traffic to the appropriate remote host and port, based on the connections made by the SOCKS proxy. This is useful for creating a secure tunnel for a variety of protocols and services.
(syntax: DynamicForward <local_port>)