The document provides an overview of cryptography and SSH (Secure Shell) protocol basics. It discusses encoding vs encryption, symmetric and asymmetric encryption, digital signatures, certificates and PKI. It then describes problems like eavesdropping, spoofing and replay attacks that SSH aims to mitigate using encryption, host key verification, and unique session keys. Finally, it outlines the SSH protocol layers and authentication process using public key or PAM methods.

1. Hasan Sharif
* Cryptography Basics to SSH
A long story cut short

2. 1. Encodingvs. Encryption
2. Types of encryption
3. Public Key Cryptography
4. Digital Signing / Certificates/ PKI / Certificate Chain
5. What are the problems of making communicationsecure?
6. How SSH mitigatesthem
7. SSH protocol Basics
8. SSH must know files – known hosts, authorized keys, configuration files.
*

3. Encoding: It is just another way of representation. Not intended for
security. That’s why you’ll not see a mention of “key” in this context. Anyone
having the right decoder can decode the encoded message.
Example of encoding algorithms: Base-64, PEM, DER, etc..
Encryption: The intention here is secrecy of the message. That’s why
there is a “secret key” involved. Knowing the algorithm used to encrypt the
message is not enough to decrypt it. The decryptor must also possess the right
key to decrypt the message correctly.
Example: AES, DES, 3-DES, Bluefish, RSA, DSA, etc.
*

4. But first what is a key?
A key is just a secret big number which is used while encrypting or decrypting a message.
Symmetric Encryption: The same key is required to encrypt as well as decrypt the message.
Example: DES.
+: very fast
-: Key being the same, needs to be transferred to the recipient risking exposure on the
communication channel.
Asymetric Encryption: Key used to encrypt is different than the key used to decrypt. Both
the keys are related mathematically which makes the magic possible. However guessing one
key from the other is computationally very hard. These are also known as public key
cryptography.
+: No need to transfer the key over communication channel
-: Slow
Hybrid Encryption: Best of both world. The bulk data is transferred using SE. So data
transfer is fast. This symmetric key is protected in communication channel using AE.
SSH uses this mechanism.
*

5. • This is related to asymmetric keys.
• One key encrypts, the other decrypts.
• Normally the user encrypts a message using the intended
receiver’s public key which is as name says “public”.
• The receiver decrypts it using her own private key which is
not shared with anyone.
• The security lies on the secrecy of the private key of the
recipient.
• The beauty is: since to decrypt the message user needs her
own private key, there is no need to send the private key
over communication channel.
*

6. • Gives a reason to believe that the claimed sender is the real
sender of the document.
• The digital document is encrypted by the user’s private key not
public key.
• The authenticity of the signed document is verified by
decrypting the document using her public key.
• Alice runs the message through a digest algo which produces a
fixed length output say S.
• She then encrypts the S using her private key.
• Sends both the message and the encrypted hash (S).
• Bob runs the same digest algo on the message, gets output A.
• He then tries to decrypt the received hash S with Alice’s public key
and finds the hash as B.
• If A == B, Bob knows message came from Alice.
*

7. *
* It is just a digital document having standardized format.
* A certificate is mostly used to claim authenticity of a web server running secure transport
scheme HTTPS.
* Claims that the webserver user has connected to is really the one it claims to be (provided
the user trust the signer of the certificate).
* Issuer: The entity signing the certificate.
* Subject: The entity being certified.
* Self signed Certificate:
* The issuer and subject are same. Onus is on the user to trust. Verisign certifies others. Who’ll
certify verisign?
* Self signed certificate authorities are also called Root CA as it is the last one in the
certificate chain. Trust chain ends here.
* Certificate Chain:
* The ROOT CA certifies a subject. The subject may in turn be the issuer of another sub
subject.
* All the certificates are there in the certificate chain.
* Browsers have public keys of well known certificate authorities (CA). That’s why when we
open sites like gmail, the site is said to be trust worthy. The certificate presented by the
website is verified to be signed by verisign.

8. *
* Think of a situation:
* An office has 300 people, each has her own private/public key pair.
* NCH joins, she has to collect everyone’s public key and verify they are
not forged in any way. She also has to let others know her public key if
she wants to communicate.
* Few security paranoids might have a hard time trusting the keys of the
NCH.
* PKI solves this by placing an infrastructure where an entity serves as
the certification authority (CA).
* NCH goes to CA and submits application for keys.
* CA verifies her identity by checking her PAN card/PP/DL.
* CA creates a key pair for her. Gives her the private key. Sends all the
public key. CA signs her public key by its own private key.
* Since everyone trusts the CA, any communication from the NCH can
be validated against her certificate.

9. *
*Meet the bad guy: PC
*IP Spoofing: Alice(client) wants to talk to Bob (server). But before
Bob knew it, PC poses himself as Bob and Alice has no reason to not
trust him.
*PC gets to know about all secret things Bob was supposed to know.
*If Alice is waiting for some info from Bob, this gig is over for PC.
*MITM: Same as above. But PC now acts as a middleman. Any info
coming from Alice goes to PC. PC sends that info to Bob. Bob
responses back to PC. PC responds back to Alice.
*PC gets all secret info, no one detects that and he lives happily ever
after.
*Eavesdropping: Tapping into the communication channel, PC gets all
the info.
*Only solution is to encrypt the channel with secret key(s).
*But encrypted channels can also be under attack.

10. *
*The attacks are now about getting the key that is needed to
decrypt the message:
*Known plaintext attack: PC sends known plaintext in the
communication channel and observes the cipher text. With
tenacity and enough opportunity to test, he can figure out the
key.
*Replay attack: PC does not have to decrypt the message. He
has the encrypted byte chunks from the channel what Alice
used as her password. In suitable time PC might just send
those byte chunks to pose as Alice.
*Brute force attack: Given a fixed size key length and enough
time, every possible key can be tested and eventually found
out. That’s why a longer key is more secure.

11. • Eavesdropping: Mitigates by encrypting the channel. The bulk
data is transferred using symmetric Key. The symmetric key is
protected in the channel by use of Public/Private key pair in both
ends of the connection.
• IP/DNS spoofing/ MITM: Prevents by maintaining a database of
known server identification string (known as host key). If the
client connects to a fake server, the host key won’t match and
SSH would disconnect the session. The caveat is you have to have
the host key beforehand. So if you are connecting a server for the
first time, you are exposed to MITM.
• Replay Attack: Each SSH session is encrypted using a session key
unique to the session. Replaying encrypted data of one session
will not make any sense in any other session. This is also called
forward secrecy - being able to decrypt one session does not give
any advantage in decrypting future sessions.
*

12. • Funny, I wonder what happens if I just copy the
public key of Bob’s server and put it in my own
Server to impersonate Bob? Public Key is public,
right? And SSH will not know if its public and
private keys are matching or not as you said it is
computationally infeasible!
• The answer to above is that, private key actually contains all the
information required to know the public key. And SSH server
reads public key part from the private key file only. Replacing
public key from the system won’t make much difference.
*

13. *
*The SSH protocol is a layered architecture. There are a
number of RFCs associated with it.
*RFC 4251 ( Protocol Architecture ) – Discusses the layers.
*RFC 4253 ( Transport ) – Layer on top of TCP. Discusses
server authentication, key exchange. At end of this the
connection between server and client is secure.
*RFC 4252 ( User Authentication ) – Layer on top of
Transport Layer. Discusses client authentication. At end
of this user is authenticated over a secure channel.
*RFC 4254 ( Connection ) – Layer on top of User
Authentication. Discusses how multiple connections can
be created (channels), tunnel forwarding, etc. This can
be compared with Application layer.

14. *
* Client connects to port 22 of server.
* Server Authentication
* Server sends its public key to the client.
*Client checks if the public key is listed in its own file based data
base.
*If it is not, based on configuration, the client can close the
connection or prompt the user if she wants to accept the key.
* Session Key generation:
*In SSHv1 the session key is generated using a random number,
host’s public key and server’s public key.
*In SSHv2 the session key is generated using Diffie-Hellman
Algorithm.
*The session key generated is unique to every session and is used
for encryption.

15. *
* Session Key Generation:
* Server and Client negotiates a large prime number P.
* The client generates a large prime number which is less then P.
* Using this number and P client creates its own private and public keys.
* The server generates its own private and public key pair the same way.
* The client and server exchange their public keys.
* The client takes its private key and server’s public key and using a
mathematical equation, gets a key (KC).
* The server takes its private key and client’s public key and using a
mathematical equation, gets a key (KS).
* Amazingly KC and KS are same!
* This KC or KS is used to encrypt the channel.
* See that this is a symmetric key but the key is derived using Asymmetric keys
where the private keys were never on the channel.
* Since both Client and Server derives the key independently, there is no need
to share the key over the insecure channel.
* The encryption used has to be symmetric encryption as the key is symmetric.
Example: AES, Blowfish, 3DES, etc.

16. *
*User Authentication happens over a secure
channel.
*There are many forms of user authentication.
Important ones are:
*Public Key based authentication - User does not
have to provide any password. The
authentication is based on user’s keys.
*PAM based authentication – The authentication
job is delegated to server’s PAM module. It’s
success determines user’s entry.

17. *
*Client sends user’s public key identifier to the server.
*Server checks if the identifier matches any entry in her file based data
base (authorized_keys file).
*If entry is found then:
*Server generates a random number (SR). Calculates a digest on the
random number. Say the digest is (SD).
*Server Encrypts SR using user’s public key and sends back to the client.
*Client decrypts the encrypted R using user’s private key and gets CR.
*Client runs digest on CR.. Gets CD.
*Client sends the CD to server.
*Server checks if CD == SD.
*If they match client is passed through. If these don’t match, falls back
to next available authentication method.
*If entry is not found:
*Falls back to next available authentication method.