Search the FAQ Archives

3 - A - B - C - D - E - F - G - H - I - J - K - L - M
N - O - P - Q - R - S - T - U - V - W - X - Y - Z - Internet FAQ Archives and frequently asked questions
Section - I can't get .rhosts/.shosts to work with ssh.

( Single Page )
[ Usenet FAQs | Web FAQs | Documents | RFC Index | Neighborhoods ]

Top Document: and frequently asked questions
Previous Document: Tcp wrappers (tcpd) thinks all hosts are in Solaris 8 or in some versions of AIX.
Next Document: Should I block all ICMP at my firewall/router?
See reader questions & answers on this topic! - Help others by sharing your knowledge
If ssh doesn't do what you want, the output of "ssh -v" may be helpful.

For .rhosts or .shosts (or hosts.equiv or shosts.equiv) to take effect with
ssh with the default configuration, a few somewhat unobvious things must be
the case.  These are all good restrictions and the rationale is included here.

    * The request must be coming in from a "privileged port"; thus, the ssh
      client must be setuid.  Without this restriction, any user could
      masquerade (for the purposes of passwordless login) as any other on the
      same source machine.  (Even with it, root can; but there's no way to
      restrict THAT without the user typing something or involving a third
      machine (i.e. some hardware which root doesn't have access to).)  Also,
      the ssh client must be able to read /etc/ssh_host_key (the private one)
      to be able to do the public key authentication thing to prove you're on
      the host whose IP address you're using.  N.B. that the 1.2.25 makefile
      sometimes turns off the setuid bit on ssh when doing a "make install"
      (it's a bug in the makefile, fixed in 1.2.26).

    * .rhosts or .shosts must be owned by the appropriate user and not be
      writable by group or others.  Sshd does not check for the situation of
      single-user groups common on some versions of unix these days (esp some
      versions of GNU/linux); you have to chmod g-w .rhosts/.shosts if your
      umask is 2.  (There is no way for sshd to detect the single-user group
      situation; current membership of size one doesn't tell you its history.)
      Similarly, your home directory should not be writable by group or others.

    * The source host must be in /etc/ssh_known_hosts or
      ~user/.ssh/known_hosts on the target machine.
      This is the difference between "RhostsRSAAuthentication" (allowed by
      default) and "RhostsAuthentication" (disallowed by default).  Without
      this, ssh is not gaining you any login security, although it is still
      gaining you anti-sniffing security.

When all else fails, try "ssh -v".
Take further questions to

User Contributions:

Comment about this article, ask questions, or add new information about this topic: