Provides a secure replacement for rlogin, rcp, and telnet

Why use ssh?

• Uses cryptographic authentication
• telnet sends your password across the network in the clear
• rlogin allows a session on a remote host without authentication via Berkeley rhosts mechanism
• Encrypts communication between two machines
• No encryption is done during telnet session

What is Encryption?

• Encryption can be built into applications 
• Data passes through a mathematical formula called an algorithm
• The algorithm converts it into encrypted data called ciphertext
• The formula requires a variable from you called the key
• The key makes it next to impossible for anyone to crack the encrypted data

Symmetric Encryption

Asymmetric Encryption

• Referred to as a shared-key  or single-key algorithm
• one key which both encrypts and decrypts the message
• called the secret key
• How do you distribute the secret key to all parties in a secure manner?
• Therein lies the problem with Symmetric key encryption

• Referred to as public-key algorithm
• one key to encrypt and a different but related key to decrypt
• one key, the public key, is disclosed to any party who needs to send you data (you give them your public key)
• the other key, the private key, is only known to you and never shared or distributed
• the sender uses your public key to encrypt the data
• You use your private key to decrypt it
• This algorithm was developed to overcome the problem of passing secret keys over insecure channels
• Not as fast as symmetric algorithm
• typically used to:
1. encrypt secret keys for transmission over network
2. generate digital signatures

• Passwords are hashed not encrypted on your Linux systems
• Data is sent through a mathematical transformation to produce the hash
• variable sized data produces a fixed size hash
• Computationally impractical to comput the original data from the hash
• would take too many years...
  

Hash Algorithms: MD3, MD5, RSA, SHA-1, DSA

Authentication process

User logs in and types in their password

A hash is computed from user's password input

This hash is compared to the hash stored on your system (in the /etc/shadow file)

How SSH authenticates
SSH can use serveral different ways to authenticate users

1. Using ~.rhosts, ~.shosts, /etc/hosts.equiv, or /etc/shosts.equiv 

• If the name of the remote host from which the user is logging in is listed in these files -- bad!
• This is the old rhosts mechanism which we want to avoid
• No password is required
• Never use this method!

2. Using Host-Based authentication with RSA

• Similar to method 1
• uses public key cryptography to identify the remote host
• The remote host's public key must be in users ~/.ssh/known_hosts file or /etc/ssh_known_hosts
• The public key gets into this file either by
1. a user accepting the host as legitimate
2. or by distributing these keys manually 

• If security is compromised on the originating host, the trusting user's site will also be compromised
  

• The user is authenticated without a password
• Then entire session is encrypted with an agreed-upon symmetric cipher between the client and the server (session-key)
• Details:
• The server's Public Host Key and Public Server Key is encrypted with a 256-bit random number generated by the client. We use Blowfish encryption in the US. This produced the Session Key used to encrypt all further communication.

3. Authenticating the user with RSA Authentication (most secure)

• SSH used public key cryptography to verify the user's identity
• The user must have created a private key and must know the password to decrypt it
• Most secure and most complicated to set up
• if the user travels they must bring a copy of their private key with them
• done using ssh-keygen on a per-user basis
• The private user key is stored in $HOME/.ssh/identity
• This file can be encrypted by the user
• The public user key is stored in $HOME/.ssh/identity.pub
• Each machine the user connects to must have the user's User Keys.
• Details:
• The server looks for the clients's Public User Key in $HOME/.ssh/authorized_key and encrypts it with a 256-bit random number. This is the challenge
• The user has to enter his Public User Key in his authorized_key file on the server exactly as it appears in his identity.pub file on the client.
• We are assuming he has a home directory on each of these machines.
• The challenge is sent to the client
• The client decrypts the challenge with the user's Private User Key, computes a 128-bit MD5 hash of the extracted random number and sends it back ot the server
• The server also computes the 128-bit MD5 hash of the random number and compares it to the hash sent by the client
• If they match, the user is authenticated
• If PasswordAuthentication is turned on in the server's sshd_config file: failure to authenticate via RSA will enable sshd to prompt the user for a password

4. by authenticating the user with their normal login password

• similar to telnet except the password and session are both encrypted

• sshd: server daemon
• ssh: user command for login
• scp: user command for secure copy
• ssh-keygen: generates key pairs for user
• sftp: secure ftp
  

$ ssh -l pattyo mammoth
$ scp pattyo@mammoth:/home/pattyo/testfile .
$ ssh -v remote-server
$ sftp 192.168.1.20
Connecting to 192.168.1.20...
pattyo@192.168.1.20's password:
sftp>

• There must be an ssh server in order for a client to connect

Here are some key entries:

RhostsAuthentication no
RhostsRSAAuthentication no
RSAAuthentication yes
PasswordAuthentication yes
IgnoreRhosts yes

• SSH1:  rsa1
• SSH2:  rsa or dsa
• Below the -t specifies SSHv2 using RSA
• The -b is for number of bits used to create the key
• The longer, the more secure, the slower the authorization

$ ssh-keygen -t rsa
$ ssh-keygen -b 2048 -t rsa
 
• This operation generates RSA keys for SSH2 (see ssh-keygen man page)
• The files created are id_rsa and id_rsa.pub
• check your ~/.ssh directory for the newest files created

$ ls -lt | head

• Check ssh man page to find out where the machine your are trying to ssh into expects to find the keys
• Your Linux machine is going to look in $HOME/.ssh/authorized_keys2

$ sftp mammoth
Connecting to mammoth...
pattyo@mammoth's password:
sftp> cd .ssh
sftp> get id_rsa.pub id_rsa.pub.mam
Fetching /home/pattyo/.ssh/id_rsa.pub to id_rsa.pub.mam
sftp> quit

$ cat id_rsa.pub.mam >> authorized_keys2

$ ssh ponto
Last login: Tue Apr 29 11:55:53 2003 from ponto.example.com

• SSH is not going to trust you unless you have permissions restricted on your home directory, your .ssh directory, and the key files within it
• They should not be group or world readable or writeable!
  

ls -ld .ssh
chmod 400 .ssh
chmod 400 .ssh/*

• Use the -v option to troubleshoot connection problems

$ ssh -v remote-host

SSH1

work finished by end of 1998

SSH2

• complete rewrite, very different from SSH1
• more secure, supports additional encryption methods
• backward compatible

This picture is from "SSH, The Secure Shell, The Definitive Guide", by Daniel J Barrett and Richard Silverman.

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.



www.vandyke.com/solutions/ssh_overview/ssh_overview_threats.html

• The client, Bob, thinks he is connected to the server, Alice.
• Actually, Eve, has intercepted Bob's communication and authenticated herself as Alice.
• Eve also sets up a conncetion with Alice, posing as Bob.
• Eve is now reading all the data passing between Bob and Alice.
• This can happen if a secure host is compromised.