Password-less Encrypted Connections with OpenSSH

Posted by tadelste on Jan 7, 2006 8:35 AM
systhread; By Jason (Jay) R Fink

Believe it or not a lot of users out there do not know how to set up password-less encrypted connections with OpenSSH.

While there are many sites (and manual pages) with this information, it is getting put up here as a quick [1] need to reference. [2]



Public Keys



Setting up a no-password needed secure shell connection involves public keys. A public is the the id needed on both ends to agree upon a session - at least that is the short short version. The basic steps of setting up SSH keys is:



  1. Generate the keys on the client host.
  2. Copy or deposit the keys on the server.


  3. Test the connection.


Conventions



While the typographic are inline with what the site usually uses, the host conventions need to be clarified.



client


The system that a user is connecting from and that the full ssh directory will reside on.
server
The system that the client is connecting to and will only have the files within the ssh directory that are needed.


Generating Keys



First the type of key needs to be determined, as of this writing there are two types:



  • RSA
  • DSA


More recent versions of OpenSSH default to version two DSA keys. In this example sshv2 and DSA will be used.



jdoe@client: ssh-keygen -t dsa


When the passphrase comes up, since this is for no-pass connections, hit enter for each prompt (including the passphrase). Now in jdoe's home directory, a .ssh directory exists with the following files:



jdoe@client: ls -al /home/jdoe/.ssh
-rw-------   1 jdoe jdoe  668 2005-12-22 04:52 id_dsa
-rw-r--r--   1 jdoe jdoe  598 2005-12-22 04:52 id_dsa.pub


The public key file to be used is, id_dsa.pub.



Sending the pub key to the Server



Ideally, this could be done via some sort of ultra secure method. In most cases sending the key file over is simply a matter of secure copying it. The problem with just secure copying it is that the directory bits may not be in place on the server. To make sure they are, at least one semi-interactive session is required. Assuming that jdoe's home directory is in the same place on the server as the client then the following works with the exception that jdoe will be prompted for a confirmation to connect then a password for each operation. Note that the connect confirmation is only requested once:



jdoe@client: ssh server mkdir /home/jdoe/.ssh
The authenticity of host 'server.server.srv (192.168.0.50)' can't be established.
DSA key fingerprint is xxsomereally:long:list
Are you sure you want to continue connecting (yes/no)? 
yes
jdoe.server.srv's password:
jdoe@client: ssh server chmod 0600 /home/jdoe/.ssh
jdoe.server.srv's password:


Now that the permissions and structure are in place, it is time to send the public keys:



jdoe@client: scp .ssh/id_dsa.pub server:/home/jdoe/.ssh/authorized_keys
jdoe.server.srv's password:


That is it, from now one when jdoe types:



jdoe@client: ssh server


As long as the client and server are on the same version (again - nowadays v2) of the protocol - the connection will no longer require a password. This applies to scp as well.



What about Version Differences?



That is simple enough, newer versions now pass along the information and automatically adjust. In the worst case scenario, run ssh in verbose mode (-v) to see what protocol is on the server and then change the client connection to use it with the -o -NUMBER

where NUMBER is the version. If the keys are incompatible, the verbose option will say which keys to use, to use RSA simply run

jdoe@client: ssh-keygen -t rsa


Which will create key files named id_rsa and id_rsa.pub. The pub file is still copied to server:$HOME/.ssh/authorized_keys.



The Quick Guide



Following is a simple summary with user jdoe and their $HOME being the same on the client and server as well as using v2 with DSA:



jdoe@client: ssh-keygen -t dsa
jdoe@client: ssh server mkdir /home/jdoe/.ssh
The authenticity of host 'server.server.srv (192.168.0.50)' can't be established.
DSA key fingerprint is xxsomereally:long:list
Are you sure you want to continue connecting (yes/no)? 
yes
jdoe.server.srv's password:
jdoe@client: ssh server chmod 0600 /home/jdoe/.ssh
jdoe.server.srv's password:
jdoe@client: scp .ssh/id_dsa.pub server:/home/jdoe/.ssh/authorized_keys
jdoe.server.srv's password:
jdoe@client: ssh server


Summary



OpenSSH offers a lot of capabilities not documented here (yet?) - in the least, setting up password less accounts is pretty straightforward and easy enough for just about any *NIX user.



Footnotes


  1. A reader sent a question in regarding SSH.


  2. There is an excellent article over at Linux Journal about this as well.


This article also appears at systhread. Special thanks to Jay Fink.

Return to the LXer Features

Subject Topic Starter Replies Views Last Post
Moderated thread title: Poster recommends alternative method. timlinux 4 1,499 Jan 5, 2006 2:22 PM

You cannot post until you login.

LXer

  Latest Features
Scott Ruecker (Phoenix, U.S.): LXer Weekly Roundup for 26-Oct-2014
Oct 27, 2014

Scott Ruecker (Phoenix, U.S.) : Interview With Richard Kenner of AdaCore
Aug 29, 2014

Carla Schroder: Test Sites for Heartbleed OpenSSL Vulnerability
Apr 09, 2014

penguinist: Better Than a Quad-Head Display: My Adventures with "4K" 2160p and Linux
Mar 31, 2014

Dr Tony Young: Replacing KDE4 with Xfce
Mar 07, 2014

Dr Tony Young: Removing/Disabling The Semantic Deskop in KDE4 Running on openSUSE 13.1 Part 2
Feb 18, 2014

Dr Tony Young: Removing/Disabling The Semantic Deskop in KDE4 (and firing up Thunderbird) Part 1
Feb 08, 2014

Dr Tony Young: KMail Complexity - and a little Patience
Jan 26, 2014

Carla Schroder: Linux Nerd New Year's Resolutions
Dec 29, 2013

Carla Schroder: Fedora 20 Released With New, Newer, and Newest
Dec 17, 2013


View all

  Search Features

Search LXer Features:

[ Copyright © LXer | All times are recorded in Central Daylight Time (CDT) ]

[ Contact Us | Privacy Policy | Terms of Service | About us | rss | Mobile ]

Login