BSD DevCenter
oreilly.comSafari Books Online.Conferences.


The SSH Cryptosystem
Pages: 1, 2

Each key in a key pair is stored in a separate file. You can identify the public key files, as they have a .pub extension. Additionally, each public key has an associated fingerprint which is unique to that key. We'll see that fingerprint again.

Not only were the necessary keys generated, the SSH daemon was also started. This can be verified with the sockstat command:

sockstat |grep ssh

root     sshd     69820    3 tcp4   *:22                  *:*                  
root     sshd     69820    3 tcp46  *:22                  *:*

Okay, now that is listening on port 22, let's see what happens when I use the ssh command from as the user genisis:

The authenticity of host ' (' can't be established.
DSA key fingerprint is 22:69:d7:05:23:c6:db:d9:55:2a:20:a3:34:bd:f4:ef.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '' (DSA) to the list of known hosts.

Once I type the correct password for the user genisis, I'll receive my motd and customized prompt. I'll then type "exit" to leave the session:

Connection to closed.

I'll now repeat a second time:


Let's pick apart what happened here. The very first time I used SSH, I was asked to verify the fingerprint of the server's DSA public key. Once I doublechecked that it was correct and typed yes, a copy of the server's public key was placed on the client or

more ~genisis/.ssh/known_hosts ssh-dss AAAAB3NzaC1kc3MAAACBAPiOFgV4PpsbXfkaxGD+hCr02Cv9P3OJDKfaXge059

The next time I used SSH, the server's public key was compared to the copy of that key on the client; since they were the same, SSH knew I was connecting to the correct server so I wasn't asked to re-verify a fingerprint. Instead, I simply received the login prompt on the server.

Let's recap what happens behind the scenes:

  1. The ssh client contacts the ssh server on port 22
  2. The ssh server sends the ssh client a copy of its public key to prove its identity
  3. The ssh client compares the server's public key to its copy of the server's public key. If it does not have a copy of the server's key, it prompts the user to verify the fingerprint
  4. Once the server is authenticated, a key is created that will be used to encrypt and decrypt the data sent between the client and the server
  5. Now it is the user's turn to be authenticated; by default, the server will prompt for the user's password which will be sent encrypted
  6. Once the user authenticates, he will receive his shell on the other system, and all data sent between the two systems will be encrypted

OpenSSH supports other authentication methods, but this is what happens in the default configuration on your FreeBSD system. You may have noticed that the server sent its DSA public key, meaning that it was using SSH version 2. This is a good default, as version 2 is much more secure than version 1.

You may have also noticed that the user doesn't require a key pair in the default configuration, only their password. Let's change that. First, I'll have to generate a key pair for the user genisis by using the ssh-keygen command at

ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/genisis/.ssh/id_rsa): 
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/genisis/.ssh/id_rsa.
Your public key has been saved in /home/genisis/.ssh/
The key fingerprint is:
fd:5a:cc:cf:a9:f0:ea:9c:93:ea:1a:04:48:b1:47:14 genisis@hostname

When using ssh-keygen, you need to use the t switch to specify which type of key pair to create. Since SSH version 2 is more secure than version 1, and since RSA is more secure than DSA, I chose to create a SSH version 2 RSA keypair. I was also prompted for a passphrase which will be used in the future to prove that I am the owner of the key pair, or, more importantly, the private key. A passphrase is similar to a password, but should be longer yet memorable. Whenever I wish to use the private key, I will be prompted for the passphrase. If I ever forget the passphrase, I will need to generate a new key pair.

Remember that the public key in a key pair is meant to be public and it is up to you to ensure the private key is kept private. Let's take a look at the default permissions on those keys:

ls ~genisis/.ssh
total 4
-rw-------  1 genisis  genisis  951 Nov  9 15:00 id_rsa
-rw-r--r--  1 genisis  genisis  247 Nov  9 15:00

The private key, id_rsa, is only accessible by the user genisis. The public key,, is readable by anyone. If I use the file utility, I'll see that both files are ASCII text, meaning they can be viewed with a pager:

file ~genisis/.ssh/*
id_rsa:     ASCII text ASCII text

ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEA1gfc4NRnq9K17TLqhhKT3L6feKUttHTJvM054k+WhjI
H1aYjsgPPSpjulKCLQv263C9KOSpjDrjZ74ZLOlQHtsJINY2c= genisis@hostname

Note that I only showed you my public key, not my private key.

Creating the key pair is not enough. I still need to copy my public key into my home directory on the SSH server. Once the server has a copy of my public key, whenever I use SSH it will ask for my public key so it can compare it to its copy. If they match, I will be authenticated.

I'll use the scp or secure copy command to copy the key to the server. This utility comes with OpenSSH and allows you to transfer files over an encrypted session. Its syntax is similar to the regular old cp command; the only difference is that the destination file starts with the IP address of the machine you want to copy the file to, followed by a full colon, followed by the name you want the file to have once it is copied over.

So, at, I'll issue this command to copy my public key to the server:

scp ~/.ssh/
Password:	100% |***************************|   247	00:00

Note that I was careful to copy over the public key, not the private key; that is, I chose the file with the .pub extension. I also had to change the name of the destination file to ~/.ssh/authorized_keys. I was prompted for my password on the destination system before the actual copy occurred.

Now that my public key is copied over, I'll try another SSH:


This time, I wasn't prompted for a password. Instead, since my public key was correct, I immediately received my shell prompt on the server machine. While it may seem less secure to not be prompted for anything, being authenticated by a public key is more secure than being authenticated by a password. However, the security of the system still depends upon you. Just like you don't give other users your password, don't give other users your private key or your passphrase. If you ever suspect that your private key has been compromised, generate a new key pair using a different passphrase and copy over the new public key to the SSH server.

When using ssh, you don't have to be logged in to the same account on the client machine as you want to access on the server machine. For example, if I'm currently logged in as biko but want to access genisis on the server machine, I can use the l switch or login switch at the client:

ssh -l genisis

I could also use this equivalent command:

ssh genisis@

Since there isn't a copy of genisis' public key in biko's home directory, I'll be prompted for a password. I need to input the password for genisis, not for biko. While it's a little bit harder to remember who I am on each system, it does mean that I don't have to create a user account called genisis on both machines.

Let's see what happens if I try to use SSH from the superuser account:

root@'s password:
Permission denied. Please try again.
root@'s password:

Even though I gave the correct password for the superuser account, access was denied. This is a very good default. Just like you should never login directly as root, you should never ssh into another system from the root account. If you need superuser access on the remote system, ssh using a regular user account which has permission to become the superuser once logged in to the remote system.

In order to change the other defaults, we'll have to take a close look at the parameters in the SSH configuration files. Let's save that for next time. In the meantime, you can get a sneak peek by reading the manpages for ssh_config and sshd_config. You might also find the ssh FAQ interesting.

Dru Lavigne is a network and systems administrator, IT instructor, author and international speaker. She has over a decade of experience administering and teaching Netware, Microsoft, Cisco, Checkpoint, SCO, Solaris, Linux, and BSD systems. A prolific author, she pens the popular FreeBSD Basics column for O'Reilly and is author of BSD Hacks and The Best of FreeBSD Basics.

Read more FreeBSD Basics columns.

Return to the BSD DevCenter.

Sponsored by: