The protocol that I use on almost a daily basis...

SSH

The protocol is broadly structured as follows:

| User Auth | Conn |
| Transport Layer  |
|       TCP        |
|        IP        |

Transport layer protocol

Each server has a public-private key pair. ssh-keygen for openSSH. The keys are used for verifying the authenticity of the server during key exchange.

There are two alternative trust models:

• Local database of hostname - public key
• This is certified by a certification auth
• client only knows the root CA certificate and can verify the validity of all host keys certified by accepted CAs
• There's an initial handshake which is mostly uninteresting
• Following which is a set of key-exchange init messages
• The actual key exchange is based on DH
• They exchange IVs, enc keys and MAC keys

The packet structure is as follows:

seq | [packet-len | pad-len | compressed-payload | padding ] | MAC

The contents in square brackets are encrypted. Everything is MAC'd.

Auth modes

• Password: Sent encrypted via the transport layer protocol
• Client public key, signed with the client private key (Server had client's public key beforehand)
• Client's host's private key creates a signature and there is no verification on the client host

Connection Protocol

• Runs on top of the transport layer protocol
  • The secure connection is called a tunnel.
  • Each tunnel is used by the connection protocol to multiplex a number of logical channels.

Channels

• All comms using SSH supported using different channels
• Either side may open a channel
• Stages include opening, data transfer and closing of a chan.
• Each channel is given a unique number by each side
• Window mechanism: no data can be sent unless the window is partly free.
• 4 types of channels: session (regular), X11 (display), forwarded tcpip (remote port-forward), and direct tcpip (local port-forward)
• Any TCP is converted to a secure SSH connection.
• TCP is delivered to the application based on the port number.

Local Port forwarding

• Local port forwarding: ssh -L <localport>:<remote>:<remoteport>
• When we connect to the server, we create a secure channel for the session and a new one for the
• now the ssh client on the client machine will intercept any call to <localport> on the client machhine and forward the request to the remote machine's <remoteport>.
• The remote machine will respond to this request on <remoteport>, and the ssh server on the remote machine will intercept that and send it over to the client.
• The ssh client will receive this and show it at port 8080.
• A similar thing happens if the port we forwarded was not on the same ssh'ed machine but rather on its LAN. The ssh server on the remote will forward our request to that machine and finally tunnel the response back to our machine, where the client will send it to <localport>

Remote/Reverse port forwarding

• This enables the client to expose its own services to the server.
• We ssh into the remote machine from the client using ssh -R <remoteport>:<addr-reachable-by-server>:<port> ...
• Now, the ssh server starts listening on <remoteport> on its own system and forwards any incoming requests to the <port> of <addr-reachable-by-server>.
• This is the reverse of what we were doing in Local Port forwarding
• This even allows us to reverse ssh into the client. Simply forward <port> 22 of the localhost (<addr-reachable-by-server>) to some other <remoteport> of the server (say 2222). Keep this connection alive and then from the server ssh into localhost at 2222

Dynamic port forwarding

These work on the basis of forwarding traffic from the port that's not blocked by the firewall. The thing that's dynamic is the port on the remote machine. It sets up a SOCKS proxy server and then forwards all connection requests to the SSH server via the secure SSH tunnel. The SSH server then sends the requests to the final destination.

SOCKS is needed here as applications negotiate the final destination address and port using SOCKS which the server later forwards the request to.