https://www.youtube.com/watch?

v=zlv9dI-9g1U

SSH replaces TELNET

Telnet is a network protocol that allows a user to communicate with a remote device. It is a
virtual terminal protocol used mostly by network administrators to remotely access and manage
devices. Administrator can access the device by telnetting to the IP address or hostname of a
remote device.
To use telnet, you must have a software (Telnet client) installed. On a remote device, a Telnet
server must be installed and running. Telnet uses the TCP port 23 by default.
One of the greatest disadvantages of this protocol is that all data, including usernames and
passwords, is sent in clear text, which is a potential security risk. This is the main reason why
Telnet is rarely used today and is being replaced by a much secure protocol called SSH.

SSH
is a network protocol used to remotely access and manage a device and other secure network
services over an insecure network. The key difference between Telnet and SSH is that SSH uses
encryption to Secure channel between two computers, which means that all data transmitted over
a network is secure from eavesdropping.
Like Telnet, a user accessing a remote device must have an SSH client installed. On a remote
device, an SSH server must be installed and running. SSH uses the TCP port 22 by default.
Open source implementations:
 OpenSSH – common on UNIX systems
 SSH Tectia – commercial implementation
  PuTTY – client only, Windows
 MindTerm – client only, Java applet
Here is an example of creating an SSH session using Putty, a free SSH client:

Many uses for SSH other than remote shell:

• secure interactive shell sessions
• TCP port forwarding
• carrying X11 connections
X11 connections
The X Window System (also known as X11, or just X) is a software package and network
protocol that lets you interact locally, using your personal computer's display, mouse, and
keyboard, with the graphical user interface (GUI) of an application running on a remote
networked computer.
You can use X forwarding in an SSH session on your personal computer to securely run
graphical applications (X clients) installed on other university.
For X forwarding in SSH to work, your personal computer must be running an X server program.
The X server program manages the interaction between the remote application (the X client) and
your computer's hardware.
Most Linux distributions have the X server installed, but if your personal computer is running
Windows or macOS, you will most likely need to install and run an X server application. For
example:
  For Windows, download and install Xming . For X forwarding to work, you'll need to
start Xming before connecting to the remote system with your SSH client (for example,
PuTTY).

SSH protocols
It is composed of three layered components:
 The transport layer protocol provides algorithm negotiation and a key exchange. The key
exchange includes server authentication and results in a cryptographically secured
connection: it provides integrity, confidentiality and optional compression.
 The user authentication protocol uses the established connection and relies on the
services provided by the transport layer. It provides several mechanisms for user
 authentication. These include traditional password authentication as well as public-key or
host-based authentication mechanisms.
 The connection protocol multiplexes many different concurrent channels over the
authenticated connection and allows tunneling of login sessions and TCP-forwarding. It
provides a flow control service for these channels. Additionally, various channel-specific
options can be negotiated.

SSH process

Install the openssh-server package on the server :

Creating host keys: Creating a host key for a Secure Shell server is usually done only once. The
server software creates the host key automatically during installation and configuration. Less
commonly, an administrator can elect to manually generate a host key and select the encryption
algorithm and key length. For those of you familiar with Secure Shell's public-key
authentication, the choice of algorithms (DSA or RSA) and the key length (usually between 1024
and 2048 bits long) is identical to the options for those user authentication keys. A host key
consists of two components, a private and a public component. The public component is sent to
the client when the client connects. The private component should be protected so that only
the administrator and the Secure Shell server have access to it.
The basic purpose of the host key is to ensure that when you connect to a remote host, it is
actually the host that you intended to connect to.

Open a console on the client side and use the command ssh

If you've never connected to the host before, how do you know the host you are connecting to is
the right one?
Accepting a new host key
The illustrations below describe how the client application and the host perform a host key
exchange when connecting for the first time.

If the host key does not match an existing key in the client application’s host key database, a
challenge message is generated by the client application. An example text message and dialog
box are shown below

If you’re using a Windows client, you may see a dialog such as:

Before accepting the new host keys, the user should use a secure method to verify that the host
key corresponds to the actual server using of these models:
 The client has a local database that associates each host name with the corresponding
public host key
  The host name – to – key association is certified by a trusted CA and the server provides
the necessary certificates or the client obtains them from elsewhere
 Check fingerprint of the key over an external channel (e.g., phone)
 Best effort:
• accept host key without check when connecting the first time to the server
• save the host key in the local database, and
• check against the saved key on all future connections to the same server

Known hosts
After the client connects to the server for the first time and accepts and saves the host key, it is
stored in a local database. For example, under Linux or UNIX, a common set of known host keys
can be found in:

Transport Layer Protocol-Packet Exchanges

If the client requests the user authentication, normally, the server should ask you after a few
seconds for your password.

You can enter it safely, the communication is encrypted. ;-)

The server should display a welcome message and then a prompt that corresponds to your PC
console. Well done, you are connected!
Authentication using Publickey
It is possible to avoid being asked each time thanks to a special key authentication. This
authentication method is more complex to set up, but it is then more practical.
With this new authentication method, it is the client who will generate a public key and a private
key. The roles are a little reversed. The advantage is that you will not be asked for your password
each time to log in.

You must now send your public key to the server so that it can encrypt messages to you.
Without SSH or Port Forwarding: Example: HTTP traffic

With SSH and local forwarding