Linux and Windows IT Support  

dedicated-technology-experts

Windows, Apple and Linux IT support and services.

For Software and Web Development.

SSH and Authorized keys

This is a short HOWTO on setting up secure shell access without a password

Generating Keys

Protocol version 1 key generation

To create the most simple key, with the default encryption, open up a console, and enter the following command :

[dave@caprice dave]$ ssh-keygen

Will output the following :

Generating public/private rsa1 key pair.
Enter file in which to save the key (/home/dave/.ssh/identity): /home/dave/.ssh/identity
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/dave/.ssh/identity.
Your public key has been saved in /home/dave/.ssh/identity.pub.
The key fingerprint is:
22:bc:0b:fe:f5:06:1d:c0:05:ea:59:09:e3:07:8a:8c dave@caprice

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 dave dave 526 Nov 2 01:33 identity
-rw-r--r-- 1 dave dave 330 Nov 2 01:33 identity.pub

The file 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.

The file identity.pub contains your public key, which can be added to other system's authorized keys files. We will get to adding keys later.

Protocol version 2 key generation

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 :

[dave@caprice dave]$ ssh-keygen -t dsa

Which will output the following :

 

[dave@caprice dave]$ ssh-keygen -t dsa
Generating public/private dsa key pair.
Enter file in which to save the key (/home/dave/.ssh/id_dsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/dave/.ssh/id_dsa.
Your public key has been saved in /home/dave/.ssh/id_dsa.pub.
The key fingerprint is:
7b:ab:75:32:9e:b6:6c:4b:29:dc:2a:2b:8c:2f:4e:37 dave@caprice

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 dave dave 526 Nov 3 01:21 id_dsa
-rw-r--r-- 1 dave dave 330 Nov 3 01:21 id_dsa.pub

The file id_dsa contains your version 2 private key.

The file 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.

Placing the public key on the remote server

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 :

 

[dave@capricedave]$ cd .ssh/
[dave@caprice .ssh]$ scp identity.pub This e-mail address is being protected from spambots. You need JavaScript enabled to view it .1.3:./identity.pub
[dave@caprice .ssh]$ scp id_dsa.pub This e-mail address is being protected from spambots. You need JavaScript enabled to view it .1.3:./id_dsa.pub

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:

 

[dave@caprice dave]$ ssh 192.168.1.3 -v
[I edited out the verbose output, and entered the password]
[Remember kids, always use -v so dont try this at home :) ]
[dave@julia dave]$ mkdir .ssh
[dave@julia dave]$ chmod 700 .ssh
[dave@julia dave]$ cd .ssh
[dave@julia .ssh]$ touch authorized_keys
[dave@julia .ssh]$ chmod 600 authorized_keys
[dave@julia .ssh]$ cat ../identity.pub >> authorized_keys
[dave@julia .ssh]$ rm ../identity.pub

Placing the key for version 2 works about the same :

 

[dave@julia dave]$ cd .ssh
[dave@julia .ssh]$ touch authorized_keys2
[dave@julia .ssh]$ chmod 600 authorized_keys2
[dave@julia .ssh]$ cat ../id_dsa.pub >> authorized_keys2
[dave@julia .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.

Log in using your key

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 This e-mail address is being protected from spambots. You need JavaScript enabled to view it .1.3

This logs you into a system using your version 1 key.

Try it again, now for version 2

ssh -2 -v This e-mail address is being protected from spambots. You need JavaScript enabled to view it .1.3

Have a look in the output of both ssh logins and you will be able to see some differences between version 1 and 2.

 

Comments (1)
project on linux
1 Wednesday, 01 February 2012 02:52
mirza ammar haider
very thanks sir.
becoz its help me very mush in project on ssh linux.
i am student of MIT.

Add your comment

Your name:
Subject:
Comment:
  The word for verification. Lowercase letters only with no spaces.
Word verification:
yvComment v.1.24.0
   
Copyright © 1999 - 2024 Virtual Helpme | Techical Support and Maintenance | Original Template: Allrounder