display | more...

This is how a typical SSH session looks like if you dive pretty deep into the protocol. I am logged into a machine named postmortem, and I will try to log into the 'remote.machine.auth.com' (names changed to protect the innocent machines).

dogganos@postmortem:~$ssh -v dogganos@remote.machine.auth.com

I execute the command with the '-v' switch, so that every detail of the protocol is revealed.

SSH Version OpenSSH-1.2.3, protocol version 1.5.
Compiled with SSL.

This is the version of my ssh client, running on a Debian linux machine.

debug: Reading configuration data /home/dogganos/.ssh/config
debug: Applying options for *
debug: Reading configuration data /etc/ssh/ssh_config
debug: Applying options for *
debug: ssh_connect: getuid 1000 geteuid 0 anon 0
debug: Connecting to remote.machine.auth.com (145.108.113.69) port 22.
debug: Allocated local port 813.
debug: Connection established.

The ssh preferences from my machine's /etc/ssh/ssh_config are read, and my client establishes a connection to the remote box.

debug: Remote protocol version 1.99, remote software version OpenSSH_3.4p1 Debian 1:3.4p1-1

Here's something like a negotiation, so that client and server show to each other that they can speak the same language (protocol). This is the version 1.99 of the SSH protocol that the remote host is running again on a Debian linux machine.

debug: Waiting for server public key.
debug: Received server public key (768 bits) and host key (1024 bits).
debug: Host '
remote.machine.auth.com' is known and matches the host key.

Here we get into the cryptography part. After the connection is established, the SSH server is sending its host key to the client. In our case this host key looks like:

remote.machine.auth.com, 145.108.113.69 1024 35
114768216408552342789702774982169357824004352268955037965109351130782110637
911752034963797655054314287199133903318157934320419521478185916922302198251
677011391458140193530725154119089272605744539769813299743459834947948203647
362772806636840828372001638304780701641367329119270492895436257615609131275
358679653

The number in the second line is a 1024 bit prime number (309 digits x log10/log2). The client is crosscheking it with its known_hosts database and verifies it. Then the server is sending its public key (which changes hourly or so).

debug: Encryption type: 3des
debug: Sent encrypted session key.

The client selects triple DES as the symmetric algorithm to be used for enciphering the session. The client also selects a random 256-bit session key that will be used with the selected symmetric algorithm. Then, the client encrypts the session key with the public key of the server and sends it to the server.

debug: Installing crc compensation attack detector.
debug: Received encrypted confirmation.

The server decrypted the encrypted session key using its private key and now knows the session key that will be used. Now the server is going to authenticate the client with public-key cryptography, since no password will be used.

debug: Trying RSA authentication with key 'dogganos@postmortem'
debug: Received RSA challenge from server.

The server sends to the client a challenge (a randomly selected byte sequence) encrypted with the public key of the client which has already stored in its database.

debug: Sending response to host key RSA challenge.

The client receives the encrypted challenge, decrypts it using its private key and sends it back to the server.

debug: Remote: RSA authentication accepted.
debug: RSA authentication accepted by server.

The server verifies that what the client sent is same with the original challenge selected, so the client is indeed the one who claims to be.

debug: Requesting pty.
debug: Requesting shell.
debug: Entering interactive session.
Linux hal 2.2.17 #1 Tue Nov 21 18:24:25 EET 2000 i686 unknown

You have new mail.
Last login: Wed Dec 18 22:55:31 2002 from xxx.xxx.xxx.xx

"Experience has proved that some people indeed know everything."
-- Russell Baker

dogganos@remote:~$

A shell is opened at the remote machine, ready to accept commands.

A simpler type of session is if the client is authenticated using passwords. Then the 'challenge' part is omitted:

debug: Trying RSA authentication with key 'dogganos@postmortem'
debug: Server refused our key.
debug: Doing password authentication.
dogganos@
remote.machine.auth.com's password:
debug: Requesting compression at level 6.
debug: Enabling compression at level 6.
debug: Requesting pty.
debug: Requesting shell.
debug: Entering interactive session.
Linux hal 2.2.17 #1 Tue Nov 21 18:24:25 EET 2000 i686 unknown

You have new mail.
Last login: Wed Dec 18 22:55:31 2002 from xxx.xxx.xxx.xx

"Experience has proved that some people indeed know everything."
-- Russell Baker

dogganos@remote:~$


We (the admins ;-) are trying to  convince everyone on campus to use ssh to read their mails (with pine mostly) but they insist doing it with telnet. They do not know that my friend Tolis is dsniffing all day using his laptop...

Log in or register to write something here or to contact authors.