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.
S
SH 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...