Of course the account did not expire and I can perfectly log in via IPv6. Using Google I found various reports on the log messages but none of them matched my problem (in the sense that applying the proposed solutions didn't work for my case).

I'm pretty much out of ideas here.

Update

/var/log/sshd for successfull IPv6 login on the very same target machine:

Anything in your local ssh config telling it to use different accounts to the different ip addresses? Are you 100% sure the ipv6 goes to the same machine? Can you show the successful login for the ipv6 in the log?
–
EightBitTonyApr 24 '13 at 14:52

2 Answers
2

After things getting stranger and stranger (see the thread of comments in my question) I finally figured it out. First things first: The authentication process did fail in pam_access.so however not due to some misconfiguration in /etc/security/access.conf as it was suggested.

To understand why, we must look at the setup of this box in particular: It acts as a router toward IPv4 which goes natively over the PPP link and IPv6 which is over a 6in4 tunnel. Also this box acts as a DNS recursive resolver, and here it is getting interesting. I did configure the resolver in a way that IPv4 reverse lookups are resolved recursively starting with the IPv4 root servers and IPv6 reverse lookups start with the IPv6 root servers. This setup did work when I first installed it.

Now my ISP enters the pictures and people who don't understand, how DNS amplification attacks work. To make a long story short: I know for sure that my ISP messes with incoming DNS packets at random, i.e. some things must be resolved through their own resolvers for some time now, while resolving other DNS addresses recursively on your own works – the official reason is to mitigate DNS amplification attacks, but they're doing it wrong then^1.

Since I didn't want to largely change my setup I just threw my ISP's DNS resolvers at the end of my local DNS resolver as nonrecursive forward, so if the recursive resolving attempt times out it tries my ISP's resolvers. This works so far. But when I did configure this I made a small mistake: I entered the ISP's DNS resolvers to work only from hosts within my local scope, i.e. 192.168.0.0/16 but forgot about localhost, aka my router, which is the host I tried to SSH into, for which the resolver would not take the ISP's resolvers into account.

pam_access.so attempts a reverse lookup on the peers address; and this closes the circle: Because for IPv6 reverse lookup the DNS IPv6 root servers would be accessed the packets would go though the 6in4 tunnel without my ISP messing with them, getting a response. But IPv4 reverse lookup would not be done over the ISP's resolvers by my own, which would receive no response and would ultimately report a NXHOST (or it would run in a timeout). Anyway pam_access.so won't see something it likes and just says "you shall not pass".

After I fixed that resolver configuration everything now works like a charm again. But I really have to step onto my ISP's toes now…

As to how I did resolve it? Well, by yanking up logging verbosity intensely studying /var/log/everything to see in which order things unfolded. When I saw my resolver logging the reverse lookup attempts I knew what was going on.

1: from a DNS amplification mitigation point of view this is complete nonsense, because I did test and outgoing DNS packets get through just fine – however those are the packets they should filter. In fact every end customer ISP should drop all UDP packets which sender address doesn't match those of their customers

The configuration of sshd on the server is one of the most interesting things to look at if you have these kind of problems. It is normally in /etc/ssh/sshd_config.

There is a good chance that in your config file there is a section:

Match Address 10.*.*.*,192.168.0.*
PasswordAuthentication no

That has some rules specific for these subnets (the Address in your file will most likely differ). These rules only apply for IPv4 addresses if those are the only one that match (and not IPv6) and the rules within the match only apply to the matched IP address. So depending on whether you connect via IPv4 and IPv6 sshd has different rules.

Not all things can be set in a Match, but they are enough to be able to make difference:

This would be a good hint if there was a Match directive. I added the sshd_config of the target system to my question. As you can see this is really very minimal and no funky stuff is going on there. Also note that PasswordAuthorization no does not prevent keyboard interactive. And the problem persists of public key authentication is used (i.e. works over IPv6 but not over IPv4).
–
datenwolfApr 24 '13 at 19:04