Configuring SSH
Copyright 2002, 2003 Andy Barclay
OpenContent License (OPL)
pre-built solaris packages for openssh are available at the
http://www.unixpeople.com web-site
NOTE: The version of ssh that comes with Solaris 9 uses the
same authentication as openssh - in other words, use ssh-keygen
then populate the $HOME/.ssh/authorized_keys file.
Automating logins with openssh
------------------------------
When using ssh version 2 protocol (recommended)
***********************************************
Generate an rsa key on the host that will be initiating the connection
$ ssh-keygen -t rsa
(just accept the defaults for the questions it asks)
You should either enter nothing as the pass-phrase or see the section
at the bottom of this document on ssh-agent.
Copy the public part of the key from the host where the keypair was generated
over to the destination host.
Create the authorized_keys file on the host where we will be logging into
$ cd .ssh
$ cp id_rsa.pub authorized_keys
Permissions must be restrictive enough
$ chmod 755 $HOME $HOME/.ssh
-rw-r--r-- 1 abarclay wheel 224 Dec 8 23:35 authorized_keys
-rw------- 1 abarclay users 668 Feb 13 21:06 id_rsa
-rw-r--r-- 1 abarclay users 606 Feb 13 21:06 id_rsa.pub
To automate logins ON commercial SSH version 1.2.x
-----------------------------------------------------------
Assume we have a user called bvuser who needs to ssh without supplying
a password from host "pluto" to host "mars".
First, generate a key pair on host pluto
***********************************
bvuser@pluto$ ssh-keygen
Initializing random number generator...
Generating p: ..........................++ (distance 382)
Generating q: ................++ (distance 254)
Computing the keys...
Testing the keys...
Key generation complete.
Enter file in which to save the key (/home/bvuser/.ssh/identity):
Your public key is:
1024 37 10516359229421917113127705539478811879024498618426995803874534444
9945585988140096363802304628177693619418269871760392433499372348462869326
6646739162315779703799898551312046155191269923057968062945587691489139800
2932736577837917690970915466994613481217933907543219365668158001138849551
0768330121196117806139671 bvuser@pluto
Your public key has been saved in /home/bvuser/.ssh/identity.pub
***********************************
Accept the defaults for the file to save the key in
Do NOT use a pass phrase (just press enter)
Now, ftp the file /home/bvuser/.ssh/identity.pub over to host "mars" and
add it to the bottom of the file /home/bvuser/.ssh/authorized_keys
(You may have to create this file if it does not exist)
MUST ensure permissions are correct on both machines:
$ chmod 755 $HOME $HOME/.ssh
$ chmod 600 $HOME/.ssh/identity $HOME/.ssh/authorized_keys
Try it!
****************************************
bvuser@pluto$ ssh mars
Last login: Fri Jun 9 17:32:08 2000 from ushqseng99
No mail.
Sun Microsystems Inc. SunOS 5.6 Generic August 1997
Using Terminal type: xterm
bvuser@mars$
****************************************
NOTE: This only gives bvuser access from pluto to mars. In order
to have the reverse be true, you would need to generate keys on
mars and ftp the public key to pluto.
Alternatively, you could simply copy over the entire .ssh directory
from pluto to mars. That would preserve the same key.
Of course, this would not be necessary if the home directories are
automounted.
Automating logins ON commercial ssh 2.4
---------------------------------------
(Version 3.2.9 works too, but the default keylengths are 2048)
generate a dsa key
$ ssh-keygen -t DSS
(just accept the defaults for the questions is asks)
create the .ssh2/identification file (on the source host) with the
following contents
-----------------------------
IdKey id_dss_1024_a
-----------------------------
Copy the keys from the host where the keys were generated
over to the host where we will be logging into, placing
them into the directory $HOME/.ssh2
create the .ssh2/authorization file (on the destination host) with
the following contents
-----------------------------
Key id_dss_1024_a.pub
-----------------------------
MUST ENSURE THE PERMISSIONS ARE CORRECT
$ chmod 755 $HOME $HOME/.ssh2
$ chmod 600 $HOME/.ssh2/id_dss_1024_a
Automating logins from openssh to commercial ssh 2.4
-------------------------------------------------------
generate a dsa key (no need to do this if you already have one)
$ ssh-keygen -d
convert the openssh dsa PRIVATE key to commercial ssh2 public key format
$ cd .ssh
$ ssh-keygen -x -f id_dsa >commercialSSH2key.pub
now move this file to the destination machine and put it in the
$HOME/.ssh2 directory. Then put an entry in the .ssh2/authorization file
--------------------------------------
Key commercialSSH2key.pub
--------------------------------------
MUST ENSURE THE PERMISSIONS ARE CORRECT
$ chmod 755 $HOME $HOME/.ssh2
$ chmod 755 $HOME $HOME/.ssh
$ chmod 600 $HOME/.ssh2/commercialSSH2key.pub
NOTE: If you want scp to work from openssh to commercial ssh, then you
will need to copy the binary /usr/local/bin/scp to the commercial ssh
machine, placing it at /usr/local/bin/scp1
Automating logins from commercial ssh 2.4 to openssh
-----------------------------------------------------
generate a keypair ON the commercial ssh host:
$ ssh-keygen -t DSS
create the .ssh2/identification file with the following contents
-----------------------------
IdKey id_dss_1024_a
-----------------------------
copy the key pair back to the openssh host, placing the key pair in
$HOME/.ssh
On the openssh host, convert the commercial ssh keys into openssh format
$ ssh-keygen -X -f id_dss_1024_a >id_dsa
$ ssh-keygen -X -f id_dss_1024_a.pub >id_dsa.pub
create the authorized_keys file
$ cp id_dsa.pub authorized_keys
MUST ENSURE CORRECT PERMISSIONS
$ chmod 755 $HOME $HOME/.ssh2
$ chmod 755 $HOME $HOME/.ssh
$ chmod 600 $HOME/.ssh/id_dsa
$ chmod 600 $HOME/.ssh/authorized_keys
=====================================================
Automating bidirectional connections between commercial ssh 2.4 and openssh
---------------------------------------------------------------------------
Follow the steps above "from commercial ssh to openssh"
Additionally, do the following:
ON the commercial ssh box, create the .ssh2/authorization file
with the following contents:
-----------------------------
Key id_dss_1024_a.pub
-----------------------------
The largest issue with this bi-directional communication is that scp version
2 is proprietary to the commercial ssh version, so in order to scp files from
the openssh box to the commercial ssh box, you must install the openssh
version of scp as /usr/local/bin/scp1 on the commercial box.
In order to scp files from the commercial ssh box to the openssh box, you
must use "scp1" rather than plain "scp" (plain scp will hang).
When using ssh version 1 protocol
*********************************
Generate a key for the user that will be automatically logging in:
$ ssh-keygen
(just accept the defaults for the questions it asks)
You should either enter nothing as the pass-phrase or see the section
at the bottom of this document on ssh-agent.
Copy the public part of the key (identity.pub) from the host where the
key was generated over to the destination host (placing it in
$HOME/.ssh/identity.pub).
Add identity.pub to the file authorized_keys (create the file if it doesn't
exist).
Permissions must be restrictive enough
$ chmod 755 $HOME $HOME/.ssh
$ ls -l $HOME/.ssh
-rw------- 1 abarclay wheel 338 Jul 24 2000 authorized_keys
-rw------- 1 abarclay users 534 Jun 23 2000 identity
-rw-r--r-- 1 abarclay users 338 Jun 23 2000 identity.pub
What if you have assigned a pass-phrase to the private part of your key pair?
==============================================================================
Well, its a good idea to do this because if you don't, whomever has root
or sudo access on any machine where this key exists can read the private
key and hence masquerade as you. In addition, if some hacker compromises
your machine, then you will essentially have to scrap all your keys.
Ok, but it sucks to have a pass-phrase, because then you are prompted
for it every time you ssh to another machine!
Ah, there is a solution.
If you run ssh-agent, on the machine where you are ssh'ing FROM, you can
use ssh-add to decrypt your private key, and store it in the running
program. When you initiate an ssh transaction with another system, the
ssh-agent intercepts the request from the remote system for your private
key and provides it. You only have to start ssh-agent and call ssh-agent
and provide your pass-phrase once after each system reboot.
Here is the snippet of code that I use in my .profile to handle this
for me:
--------------------------------------------
if [ -f /tmp/ssh-agent.$USER.sh ]
then
. /tmp/ssh-agent.$USER.sh
else
# changing to /tmp first avoids the problem of nfs busy
cd /tmp
ssh-agent |grep -v "echo" >ssh-agent.$$
. ./ssh-agent.$$
# only create the special file if ssh-add works
[ -f $HOME/.ssh/identity ] && ssh-add $HOME/.ssh/identity && result=TRUE
[ -f $HOME/.ssh/id_rsa ] && ssh-add $HOME/.ssh/id_rsa && result=TRUE
[ -f $HOME/.ssh/id_dsa ] && ssh-add $HOME/.ssh/id_dsa && result=TRUE
[ "$result" = "TRUE" ] && mv ssh-agent.$$ ssh-agent.$USER.sh
cd $HOME
fi
--------------------------------------------
Its a little complex in case I need to use ssh version 1 (identity), or
ssh version 2 with either an RSA or DSA key.