Below is a stepwise HOWTO for setting up hostbased authentication for SSH1
or SSH2 or SSH2 with SSH1 compatibility. I didn't see anything in the FAQ
that's this straightforward, and I think it will be a welcome addition to
the FAQ. If you add it in, don't bother crediting me.
To Set Up RSH-Style Hostbased + Public Key Authentication
This is known to work with SSH 1.2.27 under Solaris 2.6 and is likely to
work under any Unix-based SSH1. Where noted below, it should also work
with SSH 2.0.30 if that SSH 2.0.30 is appropriately patched.
Hostbased authentication does not work properly with a Solaris 2.6 server,
as of SSH 2.0.30 and SSH 2.1.0 Public Beta 1 -- a connection will be
established and commands will run, but the connection hangs when the
remote command or shell exits. A workaround using SSH2 with SSH1
compatibility is discussed below.
Here, I'll use the following terms:
* The Server is the SSH server into which you're trying to connect.
* The ServerUser is the username on the Server into which you'd like to
login.
* The Client is the machine running a SSH client.
* The ClientUser is the username on the Client that you'd like to allow to
login to the Server as the Server User.
As an example, our backups are done via username "backup" on host
Tapeserv. On our Authserv server, user "root" is trying to connect to
Tapeserv to make Authserv's backups on Tapeserv's tape drive. This means
that the Server is Tapeserv, the ServerUser is backup, the Client is
Authserv, and the ClientUser is "root".
Step 1.
Of course, install SSH on the Server and Client machines.
Step 2 - SSH1.
On the Client, cat the file /etc/ssh_host_key.pub and copy-n-paste it into
Notepad or some other text editor. It will look something like this:
1024 35 1255908028087833976430... root@authserv
(the actual number will be much longer)
Remove the root@Client from the end and add the Client hostname to the
beginning:
authserv 1024 35 1255908028087833976430...
Then copy-n-paste this single, very long line into Server's
/etc/ssh_known_hosts file
This gives the Server the Client's public key so the Server can verify the
Client's identity based on a public key signature. By contrast, rsh only
uses the IP address for authentication.
Step 2 - SSH2.
Copy the Client's /etc/ssh2/hostkey.pub file over to the Server and name
it /etc/ssh2/knownhosts/authserv.ssh-dss.pub
Of course, since your host isn't named Authserv, use your own hostname.
Generally, you'll want to use the "short" hostname and not the fully
qualified hostname.
This gives the Server the Client's public key so the Server can verify the
Client's identity based on a public key signature. By contrast, rsh only
uses the IP address for authentication.
Step 3.
On the Server, create a file in the ServerUser's home directory named
".shosts". The contents of this file should be the Client hostname, some
tabs or spaces, and the ClientUser username.
For example, to allow root@Authserv to log into backup@Tapeserv, I'd place
this .shosts file into backup's home directory on Tapeserv:
authserv root
Be sure to chown and chmod the .shosts file. The .shosts file must be
owned by the remote user and should be mode 0400.
Step 4 - SSH1.
Make sure that this line exists in /etc/sshd_config:
RhostsRSAAuthentication yes
This enables the SSH1 daemon to do what we need it to do.
For safety, you may also want to verify this line:
RhostsAuthentication no
This disables the use of rhosts-style authentication without corresponding
public key authentisation.
If you had to modify the sshd_config file, you have to HUP the sshd to
make the change take effect.
Step 4 - SSH2.
Check the file /etc/ssh2/sshd2_config and make sure that
AllowedAuthentications contains the word "hostbased" For example, it may
read:
AllowedAuthentications hostbased,password
If you had to modify the sshd2_config file, you'll have to HUP the sshd to
make the change take effect.
Step 5.
You should be all set.
On the Client, log in as the ClientUser and try this:
ssh ServerUser@Server uptime
You should get back the results of "uptime" run on the remote server.
The first time you run ssh to that particular server, you'll have to
answer "yes" when asked if you want to connect to the server. This is
because the local ssh doesn't yet have the remote server's SSH public key.
This will only hapen the first time.
Common Pitfalls
Did you copy the hostkey properly? Did it get mangled when you copied it
over?
With SSH2, did you name the hostkey file appropriately? It should be
/etc/ssh2/knownhosts/HOSTNAME.ssh-dss.pub and HOSTNAME may need to be the
short hostname or the long hostname.
Check your spelling in the .shosts file
Is the .shosts file owned by the ServerUser?
Try running the server with the -v flag (for SSH2) or the -d flag (for
SSH1) and see if anything useful is generated. This is a great way to see
if a hostkey file is missing.
About SSH1 and SSH2 Compatibility
At our site we use SSH2 with password-based authentication for interactive
sessions. Because hostbased authentication doesn't work with SSH2 on
Solaris, we installed SSH2 with SSH1 compatibility and we use SSH1 for
noninteractive hostbased-authenticated backups. It is important to note
that it is SSH1 and not SSH2 which handles the hostbased sessions, which
means the following:
* The Server's SSH2 doesn't need the client's SSH2 hostkey. The Server's
SSH1 needs the Client's SSH1 hostkey.
* The Server's SSH2 doesn't need hostbased authentication enabled.
* There's no need to HUP anything on the Server. The sshd1 is spawned on
demand and will see the changes to /etc/sshd_config at that time.
* On the Client, be sure to use "ssh1" to be sure that the right client is
being invoked, e.g.:
ssh1 backup@authserv uptime
--
Gregor Mosheh
[EMAIL PROTECTED]
Systems Admin, Humboldt Internet
707.825.4638
