Menu Search Sign up

OpenSSH

Authentication & Encryption

 

SSH solves 2 different problems with regular telnet: authentication and encryption.

Authentication refers to how a server knows that you are who you say you are. In regular telnet, so long as you have the matching password to your username, you are let in. However, when you type your username and password, anyone along the way could be monitoring your connection, capture your username/password, and later use it to log in as you.

SSH allows you to solve this problem in 2 ways. At a very minimum, if you login with username and password, the transmission between your client and the server is encrypted.

Encryption is solved using a variety of encryption algorithms (IDEA is the default for SSH1, 3DES is the default for SSH2, or Blowfish). Everything you type and receive in an ssh connection is encrypted. This would prevent people from seeing what commands you are typing, or from reading your email when you have it open in pine.

SSH also allows you to login with RSA or DSA public/private key authentication. In this case, you generate a public/private key pair. You upload a copy of your public key to a host machine. From now on, when you try to login, the server uses your public key to send you a challenge (a random sequence session key encrypted with the user’s public key), that only the holder of your private key can answer (decrypted with the user’s private key and sent back to the server). While this scheme is much safer, it does have one major flaw, anyone who gets hold of your private key can login as you. Hence you must be very careful about securing your private key. You can use a passphrase to protect your private key.

Preventing Man-in-the-Middle Attack

The first time you log into each machine, you'll be asked if you want to add the host key (the RSA public key of the server) to your known hosts.

From then on, each time you log into a machine using ssh, the client-side of the protocol checks the server’s RSA public key. If the server’s RSA public key doesn't match what your ssh client remembers (or if your client has never connected to this server before), it will ask you if you want to accept that host key.

Why? This is to verify that the machine you are connecting to, is really the machine you think it is. There is a class of attacks known as "man in the middle" attacks. The way they work is that someone sets up a new server, and hijacks a DNS name (perhaps like lennon.cc.gatech.edu). Their goal is to let you login, and hope that they can then steal your password, or modify your account to do things you don't want it to do on other machines.

Luckily SSH will notice if happens, and will tell you. So, when you are asked if you want to accept a host key, you should accept it if you've never connected to that machine from this client before. But if you have connected before, then either the machine has been reinstalled and the key changed, or you are not connecting to where you think you are connecting.

The latest version of the most popular SSH implementation – OpenSSH – is OpenSSH 5.2/5.2p1 released February 23, 2009. For more information on OpenSSH, refer to

http://www.openssh.org/.