sort of interesting to talk/have a look in a bit more detail about how SSH works.

SSH stands for 'Secure Shell' and it first appeared in the mid 90's as a sort of replacement for/way of connecting to a remote machine over the internet.

Up until that time the technologies you had to connect to a remote machine, Telnet, rlogin, RSH and so on, worked fine

but they transmitted all the data in the clear over the network. So if you logged into a remote machine

anyone with a packet sniffer between you and the remote machine could see everything you were doing on there.

When these protocols first appeared that wasn't a problem because the machines were probably only networked within their computer department of a university

or a company so the people that had access to do that were people who worked there and probably the system administrators who had access to these things.

Anyway, but as the machines got networked to other networks and you started to build the internet, if you had access to the network

Any network that the data was travelling over you could sniff the packets.

And see any of the data that was being transmitted, including passwords and things.

And so in 1995, Tatu Ylonen in Finland (I apologies if I pronounced that wrongly) was concerned about this

so he developed a protocol SSH 'Secure Shell' to sort of encrypt the data so that you couldn't sort of see how/what was being sent over the wire

You could see that data was being transmitted across, you could see how much data

You could see the frequency of it to a certain extent, but you couldn't see what the data was, so you could do

certain types of analysis to see whats happening, but you couldn't see the actual data.

And so SSH was developed as a way of encrypting the connection between two machines

but it actually does a lot more than that, because when you SSH to another machine

The first thing that happens is that you open up a TCP connection between those two machines

like any standard things.

Although it doesn't have to be a TCP connection. You can actually specify that SSH uses any sort of reliable

network connection to make that, so you could theoretically run it over an RS-232 connection.

You could run it over the top of web sockets and things like that.

And I know people who have done that sort of thing.

So you've got a reliable transport between the two machines and so SSH is sending data over there.

And what SSH does is it breaks the data down into a series of packets.

And just like any packet transfer, these things have a few fields at the beginning.

So at the top you have something that tells you how big the packet is, so you have the packet

length, there are 4 bytes saying the packet is 'this big'. After that, you have another byte, which tells you

how much padding you've got. So you've got the packet length. You've got how much padding there is

and then you've got the data you want - the payload.

Then you have the padding that follows that, and so what you do, with each packet after the payload

the data that you want to send that's part of the connection, you add a small amount of padding.

Just random bytes. They don't mean anything, but they sort of force the encryption to sort of make

it harder to detect what's going on because you've got random data in there.

[See some of Mike's videos, for more details on why you might want to do that]

And then, you have some sort of message authentication code there, so that

you know that the data here hasn't been 'monkied' around with

and it's actually what has been sent.

You can the apply compression if you want to - to the payload

so you can compress the payload using standard compression algorithms, such as zlib, or something to compress the data.

And then, the whole of that packet (excluding the length) is then encrypted.

The algorithms used for the encryption and for the message authentication code

are selected by the server and the client. They establish that at the beginning, which ones they offer

which ones they want to use and things, so they are established by the client and the server, so vary from connection to connection.

And you can offer many and you can choose the one that is perhaps best for that connection.

We'll ignore that for the purposes of this video.

So we leave the packet length unencrypted, because obviously we need to know how much data is coming.

We encrypt the padding length. We encrypt the payload. We encrypt the padding

and we send the packet out over the network. At the other end, that's decrypted by the server, and it then knows it's got the packet of data.

And it can piece it back together.

And then the same thing is done for this packet, and this packet, and every packet.

And the encryption is done, so that it's continuous.

You start encrypting this one with the vectors from this one, and so on, so it sort of encrypts it one after the other.

At the server, or the client, which receives this you just reverse that process, so you decrypt the packets

you decompress the payload, and you can extract the data and sort of stitch it back together.

So you start off, you've got your TCP connection and that's unencrypted, and on top of that you've got these

packets, which have been encrypted by the SSH protocol flowing on top of that.

But that's not the end of the story. That's just encrypting the packets.

It's/that's not the connection that say if you're SSH and that's not you connection to the remote machine.

On top of that, you then open a series of channels that you send the data over.

And the reason for that is it enables you to multiplex multiple connections over that thing

so when I start a connection to my machine, it's creating a channel on top of this.

So if this is one computer over here, and this is another one over here, we're creating this channel here for

our shell connection where we can communicate and control things.

But this is actually being actually being represented by a connection through the SSH packets.

And we could have multiple ones of these between the same machines. Or we could have different types

of connections, so for example SSH also allows you to forward any sort of TCP connection over there

so you can connect to a remote service via the SSH tunnel, so you can tunnel that through

and its encrypted and then sent out at the other end. And if we make the connection with

verbose mode on, we can actually see it's setting up that connection. So what we've got here, it's reading the

configuration data, its local protocol string is.

So it connects to the remote machine. It sends back saying I support this version of SSH.

I've sent what my version is. We've then exchanged information about our compatibility

what method it is we are going to use for encrypting the messages - the packets over the network. And so on.

We've checked that we know the machine, and then we get down to here, we're now trying to authenticate

so it's now establishing, ok this is this user on that machine so I can put my password in.

And we're now connected, but if we look here 'Authentication succeeded'

we are authenticated to the remote machine and you see here it has created a new channel.

So it's creating a connection, which again is just going to be 'I send bytes down here' they appear at the other end.

You send bytes the other way, they come back to us over this channel.

And it's then setting up what type of connection it is. It's setting environment variables and things.

And this is done by sending packets of data wrapped up inside the SSH packets which establish that.

Once that's done, we can then communicate and have our interactive session.

So SSH is not just a sort of way of connecting your shell. It's actually got layers of things on top of that

which enable you to do lots of interesting things.

So you can have multiple connections made over this thing.

You don't just have to have one and there are ways you can set SSH up, so that actually, you make

the connection, and it stays connected. When you've finished, so if you make then make another

connection to the same server, it reuses that existing connection and multiplexes the two connections in between things.

It can start and stop forwarded TCP connections to other addresses, in both directions

while the connection is running, just by sending different things over this connection.

The reason why it's got all this functionality is that often

(particularly in the Unix environment, or the Linux environment) when you are connecting to to other

machines, you may just want a remote shell connection, where you just want to type commands and things

that's great. But also, the way the Unix X windows graphical user interface works

is that has a/normally done over a connection usually TCP/IP to port 6000, although it can be done over other things as well

and that could then be forwarded as another connection, so that you could login to another machine and send

the graphics commands back encrypted as well.

Occasionally you may want to connect to a service behind a firewall, and you can do that by tunnelling that

tunnelling it through the SSH connection. So there's lots of reasons why it was built this way.

But it's a nice feature, and I know I've been using this now for 20 odd years, 24 years probably now.

But actually you're still discovering new things you can do with it. For example

that you can keep a connection alive beyond when you've just disconnected from the shell

so they can reuse that TCP connection. The lower level bits, when you create a new connection on top.