In the previous post, we revisited SSH public key authentication protocol that brought passwordless SSH to life. We perused and summarized the RFCs. To visualize the authentication process, we drew the arrows that highlight the sequences of messages exchanged between the client and the server.
Not to get overwhelmed with theories, we set up a mini lab to demonstrate how a client should authenticate itself against a remote server with passwordless SSH. We ran the experiment in a cloud environment provided by Digital Ocean.
And probably you may ask this question, “Why running the experiment in the cloud?”
The very simple answer to this is “to emulate the situations when passwordless SSH shines”.
Let’s go into more details by reviewing the use cases.
Secure Shell (SSH) as defined in RFC4251 is a protocol for secure remote login and other secure network services over an insecure network. SSH consists of three main components: transport layer protocol, user authentication protocol and the connection protocol.
The transport protocol for SSH 2.0 as elaborated in RFC4253 provides a secured channel over an insecure network by performing host authentication, key exchange, encryption and integrity protection, and also deriving unique session ID that can be used by higher-level protocols.
The authentication protocol as elaborated in RFC4252 provides a suite of mechanisms that can be used to authenticate the client user to the server. There are three authentication mechanisms for SSH: public key authentication, password authentication, and host-based authentication.
The connection protocol as elaborated in RFC4254 specifies a mechanism to multiplex multiple data channels into a single encrypted tunnel over the secured and authenticated transport. The channels can be used for various purposes such as interactive shell sessions, remote command executions, forwarding arbitrary TCP/IP ports/connections over the secure transport, forwarding X11 connections, and accessing the secure subsystems on the server host.