Archived from http://marc.theaimsgroup.com/?l=secure-shell&m=95439323531405&w=2 List: secure-shell Subject: For the FAQ: Hostbased HOWTO From: Gregor Mosheh Date: 2000-03-30 1:23:25 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 gregor@humboldt1.com Systems Admin, Humboldt Internet 707.825.4638