This first short lesson will teach us how to generate a key without a passphrase, and use it in a console.
When you want to use ssh with keys, the first thing that you will need is a key. If you want to know more about how this mechanism works you can have a look more into SSH essentials. Hence there are 2 versions, I will show examples for both of them.
To create the most simple key, with the default encryption, open up a console, and enter the following command :
[steve@hig002 steve]$ ssh-keygen
Will output the following :
Generating public/private rsa1 key pair. Enter file in which to save the key (/home/steve/.ssh/identity): /home/steve/.ssh/identity Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/steve/.ssh/identity. Your public key has been saved in /home/steve/.ssh/identity.pub. The key fingerprint is: 22:bc:0b:fe:f5:06:1d:c0:05:ea:59:09:e3:07:8a:8c steve@hig002
When asked for a "passphrase", we won't enter one. Just press enter twice.
The ssh-keygen program will now generate both your public and your private key. For the sake of this first simple tutorial I will call these files by their default names "identity" and the public key "identity.pub".
Your keys are stored in the .ssh/ directory in your home directory, but you can store them where ever you'd like. Good practice is to backup your keys on a floppy. If you do so, guard this floppy with your life!
Lets have a look at your keys.
cd ~.ssh; ls -l -rw------- 1 steve steve 526 Nov 2 01:33 identity -rw-r--r-- 1 steve steve 330 Nov 2 01:33 identity.pub
identity contains your private key. YOU SHOULD GUARD THIS KEY WITH YOUR LIFE! This key is used to gain access on systems which have your private key listed in their authorized keys file. I cannot stress this enough, dont have your keys drifting around. Also, make sure your private key always is chmod 600, so other users on the system won't have access to it.
identity.pub contains your public key, which can be added to other system's authorized keys files. We will get to adding keys later.
Creating a version 2 keypair is much like creating a version 1 keypair. Except for the fact that the SSH protocol version 2 uses different encryption algorithms for its encryption. In this case we can even choos it ourselves! Huray! To find out which versions are available on your system I'd advise you to have a look in the ssh-keygen manpage.
In our example we wil create a keypair using dsa encryption. This can be done by passing the key encryption method type to ssh-keygen. This is done in the following way :
[steve@hig002 steve]$ ssh-keygen -t dsa
Which will output the following :
[steve@hig002 steve]$ ssh-keygen -t dsa Generating public/private dsa key pair. Enter file in which to save the key (/home/steve/.ssh/id_dsa): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/steve/.ssh/id_dsa. Your public key has been saved in /home/steve/.ssh/id_dsa.pub. The key fingerprint is: 7b:ab:75:32:9e:b6:6c:4b:29:dc:2a:2b:8c:2f:4e:37 steve@hig002
Again, we will retain the default locations, and we will not use a passphrase either.
Your keys are stored in the .ssh/ directory in your home directory.
Lets have a look at your keys.
cd ~.ssh; ls -l -rw------- 1 steve steve 526 Nov 3 01:21 id_dsa -rw-r--r-- 1 steve steve 330 Nov 3 01:21 id_dsa.pub
id_dsa contains your version 2 private key.
id_dsa.pub contains your version 2 public key, which can be added to other system's authorized keys file.
Again, I have listed a full ls -l with permissions, make sure you have the permissions set up correctly, otherwise other users may be able to snatch it from you. It is also a good idea to give your keys a non-standard name, since it makes guessing the name of your keypair files more easy.
To be able to log in to remote systems using your pair of keys, you will first have to add your public key on the remote server to the authorized_keys (for version 1) file, and the authorized_keys2 (for version2) file in the .ssh/ directory in your home directory on the remote machine.
In our example we will assume you don't have any keys in the authorized_keys files on the remote server. (Hint: If you do not have a remote shell, you can always use your own useraccount on your local machine as a remote shell (ssh localhost))
First we will upload the public keys to the remote server :
[steve@hig002 steve]$ cd .ssh/ [steve@hig002 .ssh]$ scp identity.pub email@example.com:./identity.pub identity.pub 100% |*****************************************************| 526 00:00 [steve@hig002 .ssh]$ scp id_dsa.pub firstname.lastname@example.org:./id_dsa.pub identity.pub 100% |*****************************************************| 614 00:00
This will place your keys in your home directory on the remote server. After that we will login on the remote server using ssh or telnet the conventional way... with a password.
When you are logged in you should create a .ssh directory, and inside the .ssh/ directory create an authorized_keys and an authorized_keys2 file and add the keys to the files. Make sure the files are not readable for other users/groups. chmod 600 authorized_keys* does the trick.
Adding the public key for version 1 works like this:
[steve@hig002 steve]$ ssh 126.96.36.199 -v [I edited out the verbose output, and entered the password] [Remember folks, always use -v argument to see messages...] [steve@hig001 steve]$ mkdir .ssh [steve@hig001 steve]$ chmod 700 .ssh [steve@hig001 steve]$ cd .ssh [steve@hig001 .ssh]$ touch authorized_keys [steve@hig001 .ssh]$ chmod 600 authorized_keys [steve@hig001 .ssh]$ cat ../identity.pub >> authorized_keys [steve@hig001 .ssh]$ rm ../identity.pub
Placing the key for version 2 works about the same :
[steve@hig001 steve]$ cd .ssh [steve@hig001 .ssh]$ touch authorized_keys2 [steve@hig001 .ssh]$ chmod 600 authorized_keys2 [steve@hig001 .ssh]$ cat ../id_dsa.pub >> authorized_keys2 [steve@hig001 .ssh]$ rm ../id_dsa.pub
If you take a little peek inside your public key files, you will find it to be a bunch of crypto, separated over a couple of rules. The public key is *1 line*. It is worth to note that the entire public key file should be one line in the authorized_keys files. So using >> is preferred over copying and pasting it from one document to another. This could put line breaks in your key which makes it useless.
Either way, your keys are in place, you are ready to go to the final step and log in using your keys.
To log in using your key use the ssh command. We will add -1 to make sure we are using SSH Protocol version 1.
ssh -1 -v email@example.com
This logs you into a system using your version 1 key.
Try it again, now for version 2
ssh -2 -v firstname.lastname@example.org
Have a look in the output of both ssh logins and you will be able to see some differences between version 1 and 2.