SSH
SSH
stands for “Secure Shell”.
What is SSH?
Secure
Shell (SSH) is a protocol for secure network communications designed to be
relatively simple and inexpensive to implement.
Purpose of SSH
SSH
provides a secure remote logon facility to replace TELNET and other remote
logon schemes that provided no security. SSH also provides a client/server
capability and can be used for such network functions as file transfer and
e-mail.
SSH Protocol Stack
Figure: SSH Protocol Stack |
SSH is
organized as three protocols that typically run-on top of TCP: SSH User
Authentication Protocol, SSH Connection Protocol, SSH Transport Layer Protocol.
SSH Transport Layer Protocol: It
is responsible for server authentication, Confidentiality and
integrity, compression.
SSH User Authentication Protocol: It is responsible for authenticates client (user) to the server.
SSH Connection Protocol: It
is responsible for multiplexes the encrypted tunnel into several
logical channel.
SSH Transport Layer Protocol
SSH
transport layer protocol focus on main 3 functions: Host Keys, Packet Exchange
and Key Generation.
Host Keys (Watch video to understand using animation)
Server authentication occurs at the transport layer, based on the server possessing a public/private key pair. A server may have multiple host keys using multiple different asymmetric encryption algorithms. Multiple hosts may share the same host key. In any case, the server host key is used during key exchange to authenticate the identity of the host. (Below Figure)
For this
to be possible, the client must have apriori knowledge of the server’s public
host key. Two alternative trust models that can be used:
The client has a local database (as per above figure) that associates each host name (as typed by the user) with the corresponding public host key. This method requires no centrally administered infrastructure and no third-party coordination. The downside is that the database of name-to-key associations may become burdensome to maintain.
The host
name-to-key association is certified by a trusted certification authority
(CA) (as per above figure). The client only knows the CA root key and
can verify the validity of all host keys certified by accepted CAs. These
alternative eases the maintenance problem, since ideally, only a single CA key
needs to be securely stored on the client. On the other hand, each host key
must be appropriately certified by a central authority before authorization is
possible.
Packet Exchange
SSH
Packet Format
Figure: SSH Packet Format |
Packet
length: Length of the packet in bytes, not including the packet
length and MAC fields.
Padding
length: Length of the random padding field.
Payload: Useful
contents of the packet. Prior to algorithm negotiation, this field is
uncompressed. If compression is negotiated, then in subsequent packets, this
field is compressed.
Random
padding: Once an encryption algorithm has been negotiated, this field
is added. It contains random bytes of padding so that that total length of the
packet (excluding the MAC field) is a multiple of the cipher block size, or 8
bytes for a stream cipher.
Message
authentication code (MAC): If message authentication has been
negotiated, this field contains the MAC value. The MAC value is computed over the
entire packet plus a sequence number, excluding the MAC field. The sequence number
is an implicit 32-bit packet sequence that is initialized to zero for the first
packet and incremented for every packet. The sequence number is not included in
the packet sent over the TCP connection.
SSH Packet Exchange Scenario
Figure: SSH Packet Exchange Scenario |
Establish
TCP Connection: Above figure illustrates the sequence of events in
the SSH Transport Layer Protocol. First, the client establishes a TCP
connection to the server. This is done via the TCP protocol and is not part of
the Transport Layer Protocol. Once the connection is established, the client
and server exchange data, referred to as packets, in the data field of a TCP
segment.
Identification
of String Exchange: The first step, the identification string
exchange, begins with the client sending a packet with an identification string
of the form: SSH-protoversion-softwareversion SP comments CR LF. where SP, CR,
and LF are space character, carriage return, and line feed, respectively. An
example of a valid string is SSH-2.0-billsSSH_3.6.3q3<CR><LF>. The
server responds with its own identification string. These strings are used in
the Diffie-Hellman key exchange.
Algorithm
Negotiation: Next comes algorithm negotiation. Each side sends
an SSH_MSG_KEXINIT containing lists of supported algorithms in the order of
preference to the sender. There is one list for each type of cryptographic
algorithm. The algorithms include key exchange, encryption, MAC algorithm, and
compression algorithm. Table shows the allowable options for encryption, MAC,
and compression. For each category, the algorithm chosen is the first algorithm
on the client’s list that is also supported by the server.
Figure: SSH Transport Layer Cryptographic Algorithms |
SSH Key
Exchange: The next step is key exchange. The specification
allows for alternative methods of key exchange, but at present, only two
versions of Diffie-Hellman key exchange are specified. The following steps are
involved in the exchange. In this, C is the client; S is the server; p is a
large safe prime; g is a generator for a subgroup of GF(p); q is the order of
the subgroup; V_S is S’s identification string; V_C is C’s identification
string; K_S is S’s public host key; I_C is C’s SSH_MSG_KEXINIT message and I_S
is S’s SSH_MSG_KEXINIT message that have been exchanged before this part
begins. The values of p, g, and q are known to both client and server as a
result of the algorithm selection negotiation. The hash function hash() is also
decided during algorithm negotiation.
Client-Side
Secret Key Calculation: Random
value x is selected by client. Then client calculates e = gx
mod p (share value “e” with server).
Client calculates
secret key K = f x mod p.
Server-Side
Secret Key Calculation: Random
value y is selected by server. Then server calculates f = gy
mod p (share value “f” with client).
Server calculates
secret key K = e y mod p.
H = hash (V_C ||V_S || I_C || I_S ||K_S || e || f || K)
Sign = (K_S || f
|| s)
End of
Key Exchange: The end of key exchange is signaled by the
exchange of SSH_MSG_NEWKEYS packets. At this point, both sides may start using
the keys generated from K.
Service Request: The final step is service request. The client sends an SSH_MSG_SERVICE_REQUEST packet to request either the User Authentication or the Connection Protocol. Subsequent to this, all data is exchanged as the payload of an SSH Transport Layer packet, protected by encryption and MAC.
Key Generation
The keys
used for encryption and MAC (and any needed IVs) are generated from the shared
secret key K, the hash value from the key exchange H, and the session
identifier, which is equal to H unless there has been a subsequent key exchange
after the initial key exchange. The values are computed as follows.
Initial
IV client to server: HASH (K || H || "A“ || session_id)
Initial
IV server to client: HASH (K || H || "B“ || session_id)
Encryption
key client to server: HASH (K || H || "C" || session_id)
Encryption
key server to client: HASH (K || H || "D" || session_id)
Integrity
key client to server: HASH (K || H || "E" || session_id)
Integrity
key server to client: HASH (K || H || "F" || session_id)
SSH User Authentication
Protocol
SSH user
authentication protocol focus on main 3 functions: Message Types and Formats, Message
Exchange and Authentication Methods.
Message Types & Formats
Three
types of messages are always used in the User Authentication Protocol.
Authentication requests from the client have the format:
byte SSH_MSG_USERAUTH_REQUEST
(50)
string
user name
string
service name
string
method name
where
user name is the authorization identity the client is claiming, service name is
the facility to which the client is requesting access (typically the SSH Connection
Protocol), and method name is the authentication method being used in this
request. The first byte has decimal value 50, which is interpreted as SSH_MSG_USERAUTH_REQUEST.
If the
server either (1) rejects the authentication request or (2) accepts the request
but requires one or more additional authentication methods, the server sends a
message with the format:
byte SSH_MSG_USERAUTH_FAILURE
(51)
name-list
authentications that can continue
Boolean
partial success
where the
name-list is a list of methods that may productively continue the dialog. If
the server accepts authentication, it sends a single byte message: SSH_MSG_ USERAUTH_SUCCESS
(52).
Message Exchange (Watch video to understand using animation)
The message exchange involves the following steps:
Figure: SSH User Authentication Protocol Message Exchange |
Step-1: Client
Send SSH_MSG_USERAUTH_REQUEST
Step-2: Username
is not valid then server send SSH_MSG_USERAUTH_FAILURE
Step-3: Server
send list of authentication method.
Step-4: Client selects
one of the methods from the list & again send request to server.
Step-5: If more
authentication method is required then server send partial success value true.
Step-6: When all
required authentication methods succeed, the server sends a
SSH_MSG_USERAUTH_SUCCESS message.
Authentication Methods (Watch video to understandusing animation)
The
server may require one or more of the following authentication methods.
Public key: The
details of this method depend on the public-key algorithm chosen. In essence,
the client sends a message to the server that contains the client’s public key,
with the message signed by the client’s private key. When the server receives
this message, it checks whether the supplied key is acceptable for
authentication and, if so, it checks whether the signature is correct.
Password: The
client sends a message containing a plaintext password, which is protected by
encryption by the Transport Layer Protocol.
Host based: Authentication
is performed on the client’s host rather than the client itself. Thus, a host
that supports multiple clients would provide authentication for all its
clients. This method works by having the client send a signature created with
the private key of the client host. Thus, rather than directly verifying the
user’s identity, the SSH server verifies the identity of the client host—and
then believes the host when it says the user has already authenticated on the
client side.
SSH Connection Protocol
The SSH
Connection Protocol runs on top of the SSH Transport Layer Protocol and assumes
that a secure authentication connection is in use. That secure authentication connection,
referred to as a tunnel, is used by the Connection Protocol to multiplex a
number of logical channels. SSH user connection protocol focus on main 3
functions: Channel Mechanism, Channel Types and Port Forwarding.
Channel Mechanism
All types of communication using SSH, such as a terminal session, are supported using separate channels. Either side may open a channel. For each channel, each side associates a unique channel number, which need not be the same on both ends. The life of a channel progresses through three stages: opening a channel, data transfer, and closing a channel.
Figure: SSH Connection Protocol Message Exchange |
Open a
new Channel: When either side wishes to open a new channel, it
allocates a local number for the channel and then sends a message of the form:
byte SSH_MSG_CHANNEL_OPEN
string
channel type
uint32
sender channel
uint32
initial window size
uint32
maximum packet size
where
uint32 means unsigned 32-bit integer. The channel type identifies the
application for this channel, as described subsequently. The sender channel is
the local channel number. The initial window size specifies how many bytes of
channel data can be sent to the sender of this message without adjusting the
window. The maximum packet size specifies the maximum size of an individual
data packet that can be sent to the sender. For example, one might want to use
smaller packets for interactive connections to get better interactive response
on slow links.
If the
remote side is able to open the channel, it returns a SSH_MSG_CHANNEL_OPEN_CONFIRMATION
message, which includes the sender channel number, the recipient channel
number, and window and packet size values for incoming traffic.
Otherwise,
the remote side returns a SSH_MSG_CHANNEL_OPEN_FAILURE message with a reason
code indicating the reason for failure.
Data
Transfer: Once a channel is open, data transfer is performed
using a SSH_MSG_CHANNEL_DATA message, which includes the recipient channel
number and a block of data. These messages, in both directions, may continue as
long as the channel is open.
Close a Channel:
When
either side wishes to close a channel, it sends a SSH_MSG_CHANNEL_CLOSE message,
which includes the recipient channel number.
Channel Types
Four
channel types are recognized in the SSH Connection Protocol specification.
Session: The
remote execution of a program. The program may be a shell, an application such
as file transfer or e-mail, a system command, or some built-in subsystem. Once
a session channel is opened, subsequent requests are used to start the remote
program.
x11: This
refers to the X Window System, a computer software system and network protocol
that provides a graphical user interface (GUI) for networked computers. X
allows applications to run on a network server but to be displayed on a desktop
machine.
Forwarded-tcpip: This is
remote port forwarding, as explained in the next subsection.
Direct-tcpip: This is
local port forwarding, as explained in the next subsection.
Port Forwarding (Watch video to understandusing animation)
One of the most useful features of SSH is port forwarding. In essence, port forwarding provides the ability to convert any insecure TCP connection into a secure SSH connection. This is also referred to as SSH tunnelling. We need to know what a port is in this context. A port is an identifier of a user of TCP. So, any application that runs on top of TCP has a port number. Incoming TCP traffic is delivered to the appropriate application on the basis of the port number. An application may employ multiple port numbers.
Figure: Connection via TCP |
Above figure illustrates the basic concept behind port forwarding. We have a client application that is identified by port number x and a server application identified by port number y. At some point, the client application invokes the local TCP entity and requests a connection to the remote server on port y. The local TCP entity negotiates a TCP connection with the remote TCP entity, such that the connection links local port x to remote port y.
Figure: Connection via SSH Tunnel |
To secure this connection, SSH is configured (above figure) so that the SSH Transport Layer Protocol establishes a TCP connection between the SSH client and server entities, with TCP port numbers a and b, respectively. A secure SSH tunnel is established over this TCP connection. Traffic from the client at port x is redirected to the local SSH entity and travels through the tunnel where the remote SSH entity delivers the data to the server application on port y. Traffic in the other direction is similarly redirected.
SSH supports two types of port forwarding: Local Port Forwarding and Remote Port Forwarding.
Local
Port Forwarding: The following example should help clarify local
forwarding. Suppose you have an e-mail client on your desktop and use it to get
e-mail from your mail server via the Post Office Protocol (POP). The assigned
port number for POP3 is port 110. We can secure this traffic in the following
way:
Step-1: The SSH
client sets up a connection to the remote server.
Step-2: Select
an unused local port number, say 9999, and configure SSH to accept traffic from
this port destined for port 110 on the server.
Step-3: The SSH
client informs the SSH server to create a connection to the destination, in
this case mail server port 110.
Step-4: The
client takes any bits sent to local port 9999 and sends them to the server inside
the encrypted SSH session. The SSH server decrypts the incoming bits and sends
the plaintext to port 110.
Step-5: In the
other direction, the SSH server takes any bits received on port 110 and sends
them inside the SSH session back to the client, who decrypts and sends them to
the process connected to port 9999.
Remote Port
Forwarding: With remote forwarding, the user’s SSH client acts
on the server’s behalf. The client receives traffic with a given destination
port number, places the traffic on the correct port and sends it to the
destination the user chooses. A typical example of remote forwarding is the
following. You wish to access a server at work from your home computer. Because
the work server is behind a firewall, it will not accept an SSH request from
your home computer. However, from work you can set up an SSH tunnel using
remote forwarding. This involves the following steps.
Step-1: From the
work computer, set up an SSH connection to your home computer. The firewall will
allow this, because it is a protected outgoing connection.
Step-2: Configure
the SSH server to listen on a local port, say 22, and to deliver data across
the SSH connection addressed to remote port, say 2222.
Step-3: You can
now go to your home computer, and configure SSH to accept traffic on port 2222.
Step-4: You now have an SSH tunnel that can be used for remote logon to the work server.
To learn more about Socket Programming Functions, Click here
Watch more videos click here.