Red Hat Bugzilla – Bug 461002
sshd name resolution
Last modified: 2008-09-04 21:29:24 EDT
Description of problem: The sshd daemon, of the openSSH package shipping with fedora 9, doesn't follow the name resolution stages specified in /etc/nsswitch.conf to resolve host names. Version-Release number of selected component (if applicable): openssh.x86_64 5.0p1-3.fc9 How reproducible: One way to reproduce the bug is by running a WINS server on the F9 machine and using wins in /etc/nsswitch.conf as one method of name resolution, while restricting ssh connectivity to the F9 box to some user(s) from a specific host on the local network. When the allowed user tries to connect from that host, he/she will be denied access although he/she should be allowed. Substituting the IP address for the hostname correctly allows the user. Thus, there may be something wrong with the name resolution in the sshd daemon. See the next section for details. Steps to Reproduce: 1. Install samba server. 2. Uncomment the line reading ; wins support = yes by removing the ; at the beginning of the line. Save the change. 3. Make sure the corresponding ports(UDP ports 137 and 138) are allowd in the firewall. 4. Run the nmb service: sudo /sbin/service nmb start 5. Configure one client or more on the local network to use the F9 machine as a WINS server. 6. Edit the file /etc/nsswitch.conf and change the line reading hosts: files dns to hosts: files wins dns Save the change. 7. To verify that the name resolution works properly, try to ping one of the clients configured in step 5 using ping -c 4 <client hostname> Clients should respond with echo replies. 8. Edit the file /etc/ssh/sshd_config(needs root privileges) and append the following line or change it if it already exists: AllowUsers user1@host1 "user1" must be a valid user account on the F9 machine. "host1" must be one of the clients configured in step 5. 9. If the sshd daemon is running, tell it to reload the configuration file using sudo /sbin/service sshd reload Or to be more safe, you may issue a full restart using sudo /sbin/service sshd restart Otherwise if the sshd daemon isn't running, start it using sudo /sbin/service sshd start 10. From the host1 machine, configured in step 8, try to ssh to the F9 box using ssh -l user1 <F9 box> where <F9 box> is the hostname or the IP address of the F9 machine; it doesn't matter. Actual results: "user1" is denied access to the F9 box from host1. Expected results: "user1" should be allowd access to the F9 box from host1. Additional info: I'm filing this bug in the x86_64 edition as this's the one I'm using and I've encountered the problem with. I don't know(and haven't tested) if this problem exists in the x86 edition of fedora 9 or not.
ssh/sshd use regular functions from glibc for name resolution (getaddrinfo, getnameinfo). I do not see any reasons why it should not work with wins in /etc/nsswitch.conf Please run the sshd in debug mode /usr/sbin/sshd -d -d -d and connect with ssh -v -v -v .... Attach the logs produced from the unsuccessful attempt here.
Created attachment 315686 [details] sshd debug level 3 log These were the debugging information produced by sshd server after running in debug mode level 3. For security reasons, I've replaced the name of the user trying to connect with <user1> and the hostname of the client trying to connect with <host1>. <user1> and <host1> are listed in the AllowUsers option in /etc/ssh/sshd_config as follows: AllowUsers <user1>@<host1> Other than those, nothing else has been changed in the output log. At line 129, you'll notice that the sshd server is trying to reverse map the IP address of the client machine trying to connect, to get the client hostname. I reviewed the manual of sshd_config and found that the only option responsible for such a behaviour is "HostbasedUsesNameFromPacketOnly", which in its default configuration, tries to reverse map the IP addresses in the TCP connection. However, as the manual states, it's only applicable to the ~/.shosts, ~/.rhosts, and /etc/hosts.equiv files during "HostbasedAuthentication", which isn't active by default. These two options, "HostbasedUsesNameFromPacketOnly" and "HostbasedAuthentication", are left at their defaults, so I shouldn't get any reverse map trials from IP address to hostnames from the sshd server.
Created attachment 315688 [details] ssh verbose mode level 3 log These were the verbose log produced by ssh client after running in verbose mode level 3. For security reasons, I've replaced the name of the user trying to connect with <user1> and the hostname of the client trying to connect with <host1>. <irrelevant user> represents the user currently running at the client machine; it's designated as "irrelevant" since the "-l <user1>" is used with the ssh client command. Other than those, nothing else has been changed in the output log.
Of course sshd needs to reverse map the ip adress of the client, how it could know the client machine hostname? If the wins nsswitch module doesn't provide correct reverse map then you cannot use hostnames in the AllowUsers statement in the configuration. This is not a bug in OpenSSH.
Reverse mapping an IP address has never been a good method for identifying hostnames. A hostname usually maps to a single IP address(with the exception of some well-known websites, like www.google.com, which may resolve to multiple IP addresses), but a single IP address may be reversely mapped to multiple hostnames. This's why this same problem exists when a hostname is defined in the file /etc/hosts where the hostname is not the primary hostname of the IP address, but rather one of the alias names in the alias list. I originally thought that the behaviour with the file /etc/hosts should have been filed as another bug, but I'd rather settle the generic behaviour with name resolution before thinking about other special cases. So I think what sshd should be doing - as what many other tools(like iptables for example) do - is resolving hostnames in the option AllowUsers to IP addresses then comparing these resulting allowed IP addresses with the IP address of the client trying to connect to sshd.