Depois de as coisas ficarem mais estranhas e estranhas (veja o tópico de comentários na minha pergunta) eu finalmente descobri. Primeiras coisas primeiro: O processo de autenticação fez falhar em pam_access.so, mas não devido a alguma configuração incorreta em /etc/security/access.conf como foi sugerido.
Para entender o motivo, devemos observar a configuração dessa caixa em particular: ela age como um roteador para o IPv4, que passa nativamente pelo link PPP e IPv6, que é um túnel 6in4. Também esta caixa funciona como um resolvedor recursivo de DNS, e aqui está ficando interessante. Eu configurei o resolvedor de forma que as pesquisas reversas do IPv4 sejam resolvidas recursivamente, começando pelos servidores raiz IPv4 e as pesquisas inversas IPv6 começam com os servidores raiz IPv6. Essa configuração funcionou quando eu a instalei pela primeira vez.
Agora, meu ISP insere as fotos e pessoas que não entendem como funcionam os ataques de amplificação de DNS. Para encurtar a história: eu sei com certeza que meu ISP mexe com os pacotes DNS recebidos aleatoriamente, isto é, algumas coisas precisam ser resolvidas por seus próprios resolvedores por algum tempo, enquanto resolvem outros endereços DNS recursivamente em seus próprios trabalhos - o oficial A razão é mitigar os ataques de amplificação do DNS, mas eles estão fazendo errado então ^ 1.
Desde que eu não queria mudar minha configuração em grande parte, eu joguei os resolvedores de DNS do meu ISP no final do meu resolvedor DNS local como redirecionamento não-recursivo, então se a tentativa de resolução recursiva expirar tente os resolvedores do meu ISP. Isso funciona até agora. Mas quando eu configurei isso, cometi um pequeno erro: entrei nos resolvedores DNS do ISP para trabalhar apenas com hosts dentro do meu escopo local, ou seja, 192.168.0.0/16, mas esqueci do localhost, também conhecido como meu roteador, que é o host que tentei SSH em, para o qual o resolvedor não considera os resolvedores do ISP.
pam_access.so tenta uma pesquisa inversa no endereço dos peers; e isso fecha o círculo: Como para a pesquisa reversa do IPv6, os servidores-raiz do DNS IPv6 seriam acessados, os pacotes entrariam no túnel 6in4 sem que o meu provedor mexesse com eles, obtendo uma resposta. Mas a pesquisa inversa IPv4 não seria feita pelos resolvedores do ISP por conta própria, o que não receberia nenhuma resposta e acabaria por relatar um NXHOST (ou seria executado em um tempo limite). De qualquer forma pam_access.so não vai ver algo que gosta e apenas diz "você não deve passar".
Depois de consertar a configuração do resolvedor, tudo agora funciona como um encanto novamente. Mas eu realmente tenho que entrar nos dedos do meu provedor agora ...
Sobre como resolvi isso? Bem, levantando verbosidade de registro estudando intensamente /var/log/everything para ver em que ordem as coisas se desdobraram. Quando vi meu resolvedor registrando as tentativas de pesquisa reversa, soube o que estava acontecendo.
1: de um ponto de vista de mitigação de amplificação de DNS isso é um absurdo completo, porque eu testei e os pacotes de saída de DNS passaram muito bem - no entanto, esses são os pacotes que eles devem filtrar. Na verdade, todo provedor de serviços ao cliente final deve descartar todos os pacotes UDP cujo endereço do remetente não corresponde aos de seus clientes