It's in the FAQ under section 9. I'll make sure I add your changes
later today.
-Anne
On Thu, May 25, 2000 at 10:35:00AM -0700, Gregor Mosheh wrote:
>
> Here's the HOWTO I wrote up on setting up hostbased authentication. I
> don't know whether it was posted to the FAQ yet. I've updated the "Doesn't
> work on Solaris" paragraph to include the newer patches to SSH 2.1.0
>
> --
> Gregor Mosheh
> [EMAIL PROTECTED]
> Systems Admin, Humboldt Internet
> 707.825.4638
>
>
> ---------- Forwarded message ----------
> Date: Wed, 29 Mar 2000 17:23:25 -0800 (PST)
> From: Gregor Mosheh <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]
> Subject: For the FAQ: Hostbased HOWTO
>
>
> 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
> with libwrap enabled, unless you're using at least SSH 2.1.0 with the
> latest patches.
>
>
> 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 (at the time this was written, SSH 2.1.0 with patches fixed it),
> 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
>
>
>
>
>
>
------------------------------------------------------------------------
Anne Carasik, Principal Consultant | Any two consenting adults can rub
SSH Communications Security, Inc. | two primes together to create
Email: [EMAIL PROTECTED] | a public keypair" - R. Thayer
------------------------------------------------------------------------
Unless stated otherwise above, the opinions expressed herein are my own,
not of my employer.
