Re: AllowUsers not working under certain conditions

On Thu, Nov 17, 2005 at 12:50:53PM -0000, Donald Fraser wrote:
[...]
> The first problem exists on both of the following versions oppenssh-3.5p1
> and oppenssh-3.9p1
> 1) I have on one of our servers the line in the sshd_config file:
> AllowUsers root@192.168.100.* root@192.168.102.*
>
> The server that runs the sshd only allows ssh clients to connect from the
> sub-net 192.168.100.0/24.
> Where as one would expect it to allow connections from both the listed
> sub-nets 192.168.100.0/24 and 192.168.102.0/24.
> Basically if I try connecting from the 192.168.102.0/24 sub-net I get the
> "User root not allowed because not listed in AllowUsers" error.
>
> The weird thing here is that if I change the option:
> "ListenAddress ::" to "ListenAddress my-server"
> then the problem goes away.

The problem is that when you specify "::" as the ListenAddress, the kernel
is reporting IPv4 connections as IP4-in-6 mapped ones (ie ::ffff:xxxx),
which don't match the IP addresses you specified. If you specify the
IPv6 addresses the kernel reports to sshd then it will work.

OpenSSH 4.1 and up work around this by "normalising" the addresses
first. From the ChangeLog:

- (dtucker) [canohost.c] normalise socket addresses returned by
get_remote_hostname(). This means that IPv4 addresses in log messages
on IPv6 enabled machines will no longer be prefixed by "::ffff:" and
AllowUsers, DenyUsers, AllowGroups, DenyGroups will match IPv4-style
addresses only for 4-in-6 mapped connections, regardless of whether
or not the machine is IPv6 enabled. ok djm@

And the trivial patch:

diff -u openssh_cvs/canohost.c:1.47 openssh_cvs/canohost.c:1.48
--- openssh_cvs/canohost.c:1.47 Tue Mar 1 21:16:19 2005
+++ openssh_cvs/canohost.c Tue May 3 19:05:32 2005
@@ -251,6 +251,8 @@
if (addr.ss_family == AF_INET6)
addrlen = sizeof(struct sockaddr_in6);

+ ipv64_normalise_mapped(&addr, &addrlen);
+
/* Get the address in ascii. */
if ((r = getnameinfo((struct sockaddr *)&addr, addrlen, ntop,
sizeof(ntop), NULL, 0, flags)) != 0) {

> The second problem is not present on the oppenssh-3.5p1-6 but is present on
> the later version oppenssh-3.9p1-8.
[snip description]

An explanation for this one does not immediately spring to mind.

--
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69
Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
http://www.mindrot.org/mailman/listi...enssh-unix-dev