What is SSH? How does it work? Your complete Guide with Simple Practical Solution – Linux / Unix / Windows.

I was reluctant to squeeze my mind to understand the nuance of SSH trust key setup until now. Yesterday, forced to learn during our go-live, I had the 12 hours experience with SSH Trust keys and I am sharing the experience. Unlike my old thought, this is not complex or arcane secret, but a simple and straightforward solution.
To simplify the concept, here is the analogy using Post Box (Mail box) and Bank Locker (or lock box or safe box):

What is SSH? How does it work? – Analogy / Public experience

Mail Box = Telnet

You rent a Mail box. When you rent it, they provide a key. Whenever you need to collect your items or keep your items, you can open the box using the key and get the materials you want. If someone steal your key or rob you and get the key, that person can go and get all your materials and fly away. Alas! You can not stop him even if you know the person or no security is attached when your key is taken. They can do anything in your box inheriting all your privileges!

In network areas, this is similar to telnet. You will be given account (Mail box like) and a password (key for mail box). If your password is stolen or broken they can do anything in your account inheriting all your privileges!

Bank Safe / Locker = SSH Secured Login
Assume you have a bank safe deposit locker. It has two locks attached to it. You will be provided a key (private key) and the other key (public key) is with the bank officer. If the bank has 100 lockers, the officer may not have 100 different keys, but will have a common single key. Hence, this is called a public key and the individual keys are 100 different keys – each box one key. Hence, this is the private key. If you want to open the locker, you need the bank officer key along with your key. Neither of you can open the locker individually. If your key is stolen or robbed, they can not open your safe locker as they need bank officer key! Hence, it is secured!!

In network areas, this is similar to SSH protocol. You will be given account (Safe box like) and a password (private key for mail box) and a public key is setup with a system. If your password is stolen or broken they can do anything in your account inheriting all your privileges!

Following article is from Informit Guide

Encryption is playing a larger role as people finally understand that data is not secure by design. Gone are the days when you can transmit emails, instant messages, and files as plaintext. Whether it is your local system administrator who is snooping, a malicious hacker who has gained control of a router, or some government agency that has given themselves the power to snoop — your data sessions can not be assume to be secure.

What is SSH -in technical terms?

Early networked computer systems used a protocol known as TELNET by which a remote administrator could connect and configure, update, monitor and perform software-based maintenance on the system. While this protocol was effective, it suffered a serious security shortcoming in that it is plaintext. The end result is that anyone with a sniffer could monitor the packets and collect the username/password along with the contents of the entire session.

In fact, it was because of such a compromise that SSH was born. Like many solutions from the security community, the original idea went through some development, evolved into a better and more secure program/protocol, and was turned into a product. However, and also like many security solutions, the protocol was turned back into a freely available solution, which in this case is known as OpenSSH. While this summarizes the process and outcome greatly, the end result is a protocol known formally as SSH-2 that provides end-to-end encryption that can be used to secure remote control sessions, file transfer, tunneling, and more.
How does SSH Work?

SSH is designed to provide a secure method of authentication and data transport. This is accomplished via three main stages during the connection setup: SSH-TRANS, SSH-AUTH, and SSH-CONN. The following describes each in more detail.

Stage 1: SSH Transport Protocol

Prior to a connection, it can be assumed that neither the client nor the host has any information about the other party. This raises a problem: how can you establish a trusted connection with a remote system without a pre-established password? This is the function of the SSH-TRANS protocol.

The following breaks down the various functions of the SSH-TRANS connection.

The client connects to the server via a TCP session. This is outside the scope of anything related to SSH, but it is important to know that a successful TCP/IP connection must be made before the SSH-TRANS protocol can be of any value.

The server and client send each other their protocol information (ie. SSH-2.0-OpenSSH_4.3) to establish which protocol they should communicate with (SSH 2.0 vs. SSH 1.0). In addition to the protocol information, the client and server often pass application version information, which can help with troubleshooting and/or help work around application specific quirks.

Next the server and client will exchange information about what types of keys, encryption, and integrity hashes they support via KEXINIT messages. Each side will select a combination from the others list and will send back the results. Note, the selected combination does not need to match.

At this point the client sends the server a Diffie-Hellman GEX Init request that includes the initial challenge message of the key exchange, along with a specification of the type of key exchange that will be used.

The client then listens for the server’s response, which will include the server’s public key and a challenge value that has been signed by the server’s private key, which is supposed to provide a validation that the packet could only have come from the server that sent it.

The client checks its list of known hosts by searching the .ssh/known_hosts file in the home directory of the account requesting the connection. If the public key is listed, the client assumes that the data is valid and the server is considered trusted. If the public key is not in the list, a warning is presented to the user that asks them to verify the finger print

This fingerprint will be useless to you unless you can confirm that it belongs to the server you are connecting to. To do this, you will need local shell access (preferably) at which you will use the ssh-keygen command to print out the fingerprint. Be sure to specify the correct public key encryption type (RSA vs DSA). Figure 2 provides the results of a check on our server.

The returned challenge and signature are then verified using the public key from the server. At this point both the server and client have all the information needed to create a master key that will encrypt the session. Note that this key is not related to any user credentials that may be passed at a later point in the SSH session.

Both the client and server send one more message indicating that encryption is now in place.

At this point, the user has not done anything but pointed the client application at the server and started the connection process. However, behind the scenes, the client and server have established a secure session through which the rest of the SSH protocols will pass their data.

Stage 2: SSH Authentication Protocol

The client now needs to provide some form of authentication to the server to prove the user is authorized to access the server’s resources. This is accomplished via the SSH-AUTH protocol and transpires as following.

The client will send a request for access to the SSH server using a “none” option, which is basically asking the server to allow access without any form of authentication. In rare cases you might find this to work, in which case the server would respond with a “success” message. However, it is highly unlikely to the point that OpenSSH does not even support the “none” form of authorization.

Assuming “none” is not permitted, the server will respond with a list of acceptable forms of authentication (ie. publickey, password, keyboard-interactive).

The client will systematically attempt to authentication using the options listed. For publickey, the client will check to see if there is a public key stored locally and it will send it. It will next check to see if there is a private key associated with the server, and will send that. In this case, we have our SSH server setup to accept a password, which the client prompts for and then sends in a padded packet.

The server will work with the client and accept the various authentication data and either confirm or reject it based on local information.

The following outlines how to setup and establish a password-less connection to an SSH server using public/private keys for authentication. This is very useful if you have numerous servers to administer.

On client, you will need to create a private/public key pair using the following command:

Then using some form of secure communications, take the newly created id_rsa.pub file from the client and copy it to your server.

On server, insert the contents of the newly created id_rsa.pub file into the authorized_keys file using the following command:

On the client, simply type: ssh root@server.com to gain remote shell.

Stage 3: SSH-Connection Protocol

At this point in the connection process, the SSH client has created a secure tunnel through which it could authenticate with the server. As we mentioned, this might be accomplished via the “none” request, which would basically bypass all authentication and drop the user into the SSH-CONN stage of the connection. However, chances are that stage 2 is required for most clients.

In stage 3 the client interacts with the server to gain access to the remote resources. Typically this is limited to shell access; however, the SSH-2.0 protocol supports several extra features that need to be noted.

* X-11 Client: X-11 is the graphical program that exists on most Linux/Unix based system. What makes it unique and of value is that the graphical data can be piped to a remote system via X forwarding.
* Port Forwarding: SSH can be used to tunnel data from local ports to the remote system and on to other remote systems. This ability can be used to securely tunnel RDP traffic into a remote network and to allow remote desktop access to a Windows system. You can also setup the server to do the opposite, meaning a port on the server can be forwarded back to the client.

The other major item to keep in mind about the SSH-CONN stage is that it can host multiple sessions. File transfer, shell access, pty access, port forwarding, remote command execution, etc. each require a session.

Summary

SSH is one of the most commonly used applications in my toolkit. Whether it is remote administration, file transfer, web development or penetration testing, the power and flexibility of SSH makes it invaluable to my daily needs. However, despite its functionality, it is its security that makes all the difference in the world.

Reference:http://www.informit.com/guides/content.aspx?g=security&seqNum=336