home *** CD-ROM | disk | FTP | other *** search
/ linuxmafia.com 2016 / linuxmafia.com.tar / linuxmafia.com / pub / linux / security / ylonen-ssh / ssh-hostbased-authentication-HOWTO.txt < prev    next >
Text File  |  2000-06-02  |  6KB  |  180 lines
  1. Archived from http://marc.theaimsgroup.com/?l=secure-shell&m=95439323531405&w=2
  2.  
  3. List: secure-shell
  4. Subject: For the FAQ: Hostbased HOWTO
  5. From: Gregor Mosheh <gregor@home.humboldt1.com>
  6. Date: 2000-03-30 1:23:25
  7.  
  8. Below is a stepwise HOWTO for setting up hostbased authentication for SSH1
  9. or SSH2 or SSH2 with SSH1 compatibility. I didn't see anything in the FAQ
  10. that's this straightforward, and I think it will be a welcome addition to
  11. the FAQ. If you add it in, don't bother crediting me.
  12.  
  13.  
  14. To Set Up RSH-Style Hostbased + Public Key Authentication
  15.  
  16. This is known to work with SSH 1.2.27 under Solaris 2.6 and is likely to
  17. work under any Unix-based SSH1. Where noted below, it should also work
  18. with SSH 2.0.30 if that SSH 2.0.30 is appropriately patched.
  19.  
  20. Hostbased authentication does not work properly with a Solaris 2.6 server,
  21. as of SSH 2.0.30 and SSH 2.1.0 Public Beta 1 -- a connection will be
  22. established and commands will run, but the connection hangs when the
  23. remote command or shell exits. A workaround using SSH2 with SSH1
  24. compatibility is discussed below.
  25.  
  26.  
  27. Here, I'll use the following terms:
  28. * The Server is the SSH server into which you're trying to connect.
  29. * The ServerUser is the username on the Server into which you'd like to
  30. login.
  31. * The Client is the machine running a SSH client.
  32. * The ClientUser is the username on the Client that you'd like to allow to
  33. login to the Server as the Server User.
  34.  
  35. As an example, our backups are done via username "backup" on host
  36. Tapeserv. On our Authserv server, user "root" is trying to connect to
  37. Tapeserv to make Authserv's backups on Tapeserv's tape drive. This means
  38. that the Server is Tapeserv, the ServerUser is backup, the Client is
  39. Authserv, and the ClientUser is "root".
  40.  
  41.  
  42. Step 1.
  43. Of course, install SSH on the Server and Client machines.
  44.  
  45.  
  46. Step 2 - SSH1.
  47. On the Client, cat the file /etc/ssh_host_key.pub and copy-n-paste it into
  48. Notepad or some other text editor. It will look something like this:
  49.      1024 35 1255908028087833976430... root@authserv
  50. (the actual number will be much longer)
  51.  
  52. Remove the root@Client from the end and add the Client hostname to the
  53. beginning:
  54.      authserv 1024 35 1255908028087833976430...
  55.  
  56. Then copy-n-paste this single, very long line into Server's
  57. /etc/ssh_known_hosts file
  58.  
  59. This gives the Server the Client's public key so the Server can verify the
  60. Client's identity based on a public key signature. By contrast, rsh only
  61. uses the IP address for authentication.
  62.  
  63.  
  64. Step 2 - SSH2.
  65. Copy the Client's /etc/ssh2/hostkey.pub file over to the Server and name
  66. it /etc/ssh2/knownhosts/authserv.ssh-dss.pub
  67.  
  68. Of course, since your host isn't named Authserv, use your own hostname.
  69. Generally, you'll want to use the "short" hostname and not the fully
  70. qualified hostname.
  71.  
  72. This gives the Server the Client's public key so the Server can verify the
  73. Client's identity based on a public key signature. By contrast, rsh only
  74. uses the IP address for authentication.
  75.  
  76.  
  77. Step 3.
  78. On the Server, create a file in the ServerUser's home directory named
  79. ".shosts". The contents of this file should be the Client hostname, some
  80. tabs or spaces, and the ClientUser username.
  81.  
  82. For example, to allow root@Authserv to log into backup@Tapeserv, I'd place
  83. this .shosts file into backup's home directory on Tapeserv:
  84. authserv      root
  85.  
  86. Be sure to chown and chmod the .shosts file. The .shosts file must be
  87. owned by the remote user and should be mode 0400.
  88.  
  89.  
  90.  
  91. Step 4 - SSH1.
  92.  
  93. Make sure that this line exists in /etc/sshd_config:
  94.      RhostsRSAAuthentication yes
  95. This enables the SSH1 daemon to do what we need it to do.
  96.  
  97. For safety, you may also want to verify this line:
  98.      RhostsAuthentication no
  99. This disables the use of rhosts-style authentication without corresponding
  100. public key authentisation.
  101.  
  102. If you had to modify the sshd_config file, you have to HUP the sshd to
  103. make the change take effect.
  104.  
  105.  
  106. Step 4 - SSH2.
  107.  
  108. Check the file /etc/ssh2/sshd2_config and make sure that
  109. AllowedAuthentications contains the word "hostbased" For example, it may
  110. read:
  111.      AllowedAuthentications     hostbased,password
  112.  
  113. If you had to modify the sshd2_config file, you'll have to HUP the sshd to
  114. make the change take effect.
  115.  
  116.  
  117. Step 5.
  118.  
  119. You should be all set.
  120.  
  121. On the Client, log in as the ClientUser and try this:
  122.      ssh ServerUser@Server uptime
  123. You should get back the results of "uptime" run on the remote server.
  124.  
  125. The first time you run ssh to that particular server, you'll have to
  126. answer "yes" when asked if you want to connect to the server. This is
  127. because the local ssh doesn't yet have the remote server's SSH public key.
  128. This will only hapen the first time.
  129.  
  130.  
  131.  
  132. Common Pitfalls
  133.  
  134. Did you copy the hostkey properly? Did it get mangled when you copied it
  135. over?
  136.  
  137. With SSH2, did you name the hostkey file appropriately? It should be
  138. /etc/ssh2/knownhosts/HOSTNAME.ssh-dss.pub and HOSTNAME may need to be the
  139. short hostname or the long hostname.
  140.  
  141. Check your spelling in the .shosts file
  142.  
  143. Is the .shosts file owned by the ServerUser?
  144.  
  145. Try running the server with the -v flag (for SSH2) or the -d flag (for
  146. SSH1) and see if anything useful is generated. This is a great way to see
  147. if a hostkey file is missing.
  148.  
  149.  
  150. About SSH1 and SSH2 Compatibility
  151.  
  152. At our site we use SSH2 with password-based authentication for interactive
  153. sessions. Because hostbased authentication doesn't work with SSH2 on
  154. Solaris, we installed SSH2 with SSH1 compatibility and we use SSH1 for
  155. noninteractive hostbased-authenticated backups. It is important to note
  156. that it is SSH1 and not SSH2 which handles the hostbased sessions, which
  157. means the following:
  158.  
  159. * The Server's SSH2 doesn't need the client's SSH2 hostkey. The Server's
  160. SSH1 needs the Client's SSH1 hostkey.
  161.  
  162. * The Server's SSH2 doesn't need hostbased authentication enabled.
  163.  
  164. * There's no need to HUP anything on the Server. The sshd1 is spawned on
  165. demand and will see the changes to /etc/sshd_config at that time.
  166.  
  167. * On the Client, be sure to use "ssh1" to be sure that the right client is
  168. being invoked, e.g.:
  169.      ssh1 backup@authserv uptime
  170.  
  171.  
  172.  
  173.  
  174.  
  175. --
  176. Gregor Mosheh
  177. gregor@humboldt1.com
  178. Systems Admin, Humboldt Internet
  179. 707.825.4638
  180.