Я сейчас озадачен странной проблемой… У меня есть хост с двойным стеком, к которому я хочу подключиться по SSH. Если я подключаюсь через IPv6, все работает как и ожидалось
datenwolf@foo ~/ > ssh -6 bar.example.com
Password:
datenwolf@bar ~/ >
Однако при попытке сделать то же самое через IPv4 происходит сбой.
datenwolf@foo ~/ > ssh -4 bar.example.com
Password:
Permission denied (publickey,keyboard-interactive).
datenwolf@foo ~/ >
Выдержка из /var/log/sshdдля неудачного входа в систему
Apr 24 16:34:03 [sshd] SSH: Server;Ltype: Version;Remote: www.xxx.yyy.zzz-38427;Protocol: 2.0;Client: OpenSSH_5.9p1 Debian-5ubuntu1
Apr 24 16:34:03 [sshd] SSH: Server;Ltype: Kex;Remote: www.xxx.yyy.zzz-38427;Enc: aes128-ctr;MAC: hmac-md5;Comp: none [preauth]
Apr 24 16:34:04 [sshd] SSH: Server;Ltype: Authname;Remote: www.xxx.yyy.zzz-38427;Name: wolfgangd [preauth]
Apr 24 16:34:07 [sshd] pam_access(sshd:account): access denied for user `datenwolf' from `foo.example.com'
Apr 24 16:34:07 [sshd] error: PAM: User account has expired for datenwolf from foo.example.com
Apr 24 16:34:07 [sshd] Connection closed by www.xxx.yyy.zzz [preauth]
Конечно, срок действия аккаунта не истек, и я могу прекрасно войти через IPv6. Используя Google, я нашел различные отчеты о сообщениях журнала, но ни один из них не соответствовал моей проблеме (в том смысле, что применение предложенных решений не сработало в моем случае).
У меня тут почти нет идей.
Обновлять
/var/log/sshdдля успешного входа в IPv6на той же самой целевой машине:
Apr 24 16:56:42 [sshd] SSH: Server;Ltype: Version;Remote: 2001:x:x:x:x:x:x:x-46025;Protocol: 2.0;Client: OpenSSH_5.9p1 Debian-5ubuntu1
Apr 24 16:56:42 [sshd] SSH: Server;Ltype: Kex;Remote: 2001:x:x:x:x:x:x:x-46025;Enc: aes128-ctr;MAC: hmac-md5;Comp: none [preauth]
Apr 24 16:56:43 [sshd] SSH: Server;Ltype: Authname;Remote: 2001:x:x:x:x:x:x:x-46025;Name: datenwolf [preauth]
Apr 24 16:56:47 [sshd] Accepted keyboard-interactive/pam for datenwolf from 2001:x:x:x:x:x:x:x port 46025 ssh2
Apr 24 16:56:47 [sshd] pam_unix(sshd:session): session opened for user datenwolf by (uid=0)
Я пробовал входить с разных машин, результат один и тот же: IPv6 работает, IPv4 — нет.
Обновление 2
Для справки это используемые таблицы IP. Обратите внимание, чтоони проверены в бою, то есть они используются уже несколько лет и не менялись в последнее время. Удаленный вход через IPv4делалработать с ними.
Таблицы IPv4:
Chain INPUT (policy ACCEPT 2144 packets, 336K bytes)
pkts bytes target prot opt in out source destination
132 20762 fail2ban-SSH tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:22
12M 14G ACCEPT all -- ppp0 * 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED
3111 95984 ACCEPT icmp -- ppp0 * 0.0.0.0/0 0.0.0.0/0
18692 1123K ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:22
2 112 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:1194
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:1194
4633 288K ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpts:6880:6899
2826 154K ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpts:6880:6899
4 160 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:123
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:123
44165 3069K REJECT all -- ppp0 * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable
Chain FORWARD (policy ACCEPT 48032 packets, 44M bytes)
pkts bytes target prot opt in out source destination
0 0 REJECT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:631 reject-with icmp-port-unreachable
0 0 REJECT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:515 reject-with icmp-port-unreachable
0 0 REJECT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:631 reject-with icmp-port-unreachable
0 0 REJECT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:515 reject-with icmp-port-unreachable
0 0 REJECT all -- ppp0 ppp0 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable
133K 8347K TCPMSS tcp -- * ppp0 0.0.0.0/0 0.0.0.0/0 tcp flags:0x06/0x02 TCPMSS clamp to PMTU
Chain OUTPUT (policy ACCEPT 14378 packets, 2172K bytes)
pkts bytes target prot opt in out source destination
Chain fail2ban-SSH (1 references)
pkts bytes target prot opt in out source destination
132 20762 RETURN all -- * * 0.0.0.0/0 0.0.0.0/0
IPv6 ip6tables
Chain INPUT (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 DROP all * * ::/0 ::/0 rt type:0 segsleft:0
484K 86M ACCEPT icmpv6 * * ::/0 ::/0
105K 7943K ACCEPT tcp * * ::/0 ::/0 tcp dpt:22
0 0 ACCEPT udp * * ::/0 ::/0 udp dpt:1194
0 0 ACCEPT tcp * * ::/0 ::/0 tcp dpt:1194
0 0 ACCEPT udp * * ::/0 ::/0 udp dpts:6880:6899
0 0 ACCEPT tcp * * ::/0 ::/0 tcp dpts:6880:6899
0 0 ACCEPT tcp * * ::/0 ::/0 tcp dpt:123
0 0 ACCEPT udp * * ::/0 ::/0 udp dpt:123
0 0 ACCEPT all ppp0,sixxs * ::/0 ::/0 ctstate RELATED,ESTABLISHED
4164K 466M ACCEPT all !ppp0,sixxs * ::/0 ::/0
0 0 REJECT all * * ::/0 ::/0 reject-with icmp6-port-unreachable
Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 DROP all * * ::/0 ::/0 rt type:0 segsleft:0
2864 311K ACCEPT icmpv6 * * ::/0 ::/0
0 0 REJECT tcp * * ::/0 ::/0 multiport ports 631 reject-with icmp6-port-unreachable
0 0 REJECT udp * * ::/0 ::/0 multiport ports 631 reject-with icmp6-port-unreachable
0 0 REJECT tcp * * ::/0 ::/0 multiport ports 515 reject-with icmp6-port-unreachable
0 0 REJECT udp * * ::/0 ::/0 multiport ports 515 reject-with icmp6-port-unreachable
0 0 REJECT all ppp0,sixxs ppp0,sixxs ::/0 ::/0 reject-with icmp6-port-unreachable
0 0 accept_with_pmtu_clamp tcp ppp0,sixxs * !2001:x:x::/48 2001:x:x::/48 tcp dpt:22
18M 14G accept_with_pmtu_clamp all * * ::/0 ::/0 ctstate RELATED,ESTABLISHED
65503 5289K accept_with_pmtu_clamp all !ppp0,sixxs * ::/0 ::/0
0 0 REJECT all * * ::/0 ::/0 reject-with icmp6-port-unreachable
Chain OUTPUT (policy ACCEPT 8099K packets, 11G bytes)
pkts bytes target prot opt in out source destination
0 0 DROP all * * ::/0 ::/0 rt type:0 segsleft:0
Chain accept_with_pmtu_clamp (3 references)
pkts bytes target prot opt in out source destination
0 0 TCPMSS tcp * ppp0,sixxs ::/0 ::/0 tcp flags:0x06/0x02 TCPMSS clamp to PMTU
18M 14G ACCEPT all * * ::/0 ::/0
Обновление 3
Вот /etc/sshd/sshd_configсистема, к которой я пытаюсь подключиться, без всех комментариев:
Port 22
ListenAddress 0.0.0.0
ListenAddress ::
PubkeyAuthentication yes
PasswordAuthentication no
UsePAM yes
AllowAgentForwarding yes
AllowTcpForwarding yes
X11Forwarding yes
X11DisplayOffset 10
X11UseLocalhost yes
PrintMotd no
PrintLastLog no
UseDNS yes
Subsystem sftp /usr/lib64/misc/sftp-server
решение1
После того, как все становилось все более и более странным (см. ветку комментариев в моем вопросе), я наконец понял. Сначала самое главное: процесс аутентификацииделалсбой в pam_access.so, однако не из-за какой-то неправильной настройки, /etc/security/access.confкак предполагалось.
Чтобы понять, почему, мы должны рассмотреть настройку этого ящика в частности: он действует как маршрутизатор к IPv4, который идет по каналу PPP, и IPv6, который идет по туннелю 6in4. Также этот ящик действует как рекурсивный преобразователь DNS, и здесь становится интересно. Я настроил преобразователь таким образом, что обратные запросы IPv4 разрешаются рекурсивно, начиная с корневых серверов IPv4, а обратные запросы IPv6 начинаются с корневых серверов IPv6. Эта настройка работала, когда я впервые ее установил.
Теперь на сцену выходит мой интернет-провайдер и люди, которые не понимают, как работают атаки DNS-амплификации. Короче говоря: я точно знаю, что мой интернет-провайдер вмешивается в входящие DNS-пакеты случайным образом, то есть некоторые вещи должны разрешаться через их собственные резолверы уже некоторое время, в то время как разрешение других DNS-адресов рекурсивно на ваших собственных работах — официальная причина заключается в том, чтобы смягчить атаки DNS-амплификации, но они делают это неправильно^1.
Так как я не хотел сильно менять настройки, я просто добавил DNS-резолверы моего провайдера в конец моего локального DNS-резолвера как нерекурсивные пересылки, так что если попытка рекурсивного разрешения истечет, он попытается использовать резолверы моего провайдера. Пока это работает. Но когда я настраивал это, я допустил небольшую ошибку: я ввел DNS-резолверы провайдера для работы только с хостов в пределах моей локальной области, то есть 192.168.0.0/16, но забыл о localhost, то есть моем маршрутизаторе, который является хостом, к которому я пытался подключиться по SSH, для которого резолвернетпримите во внимание резолверы интернет-провайдера.
pam_access.so пытается выполнить обратный поиск по адресу пиров; и это замыкает круг: поскольку для обратного поиска IPv6 будут доступны корневые серверы DNS IPv6, пакеты будут проходить через туннель 6in4 без вмешательства моего провайдера, получая ответ. Но обратный поиск IPv4 не будет выполняться через резолверы провайдера моими собственными силами, которые не получат ответа и в конечном итоге сообщат NXHOST (или будут работать в режиме тайм-аута). В любом случае pam_access.so не увидит то, что ему нравится, и просто скажет "ты не пройдешь".
После того, как я исправил конфигурацию резолвера, все снова работает как часы.Но теперь мне действительно придется наступить на пятки своему интернет-провайдеру...
Как я это решил? Ну, подняв уровень детализации журнала, интенсивно изучая, /var/log/everythingв каком порядке все разворачивается. Когда я увидел, что мой резолвер регистрирует попытки обратного поиска, я понял, что происходит.
1: с точки зрения DNS amplification mitigation это полная чушь, потому что я провел тестирование, и исходящие DNS-пакеты проходят нормально – однако это те пакеты, которые они должны фильтровать. Фактически, каждый конечный клиент ISP должен отбрасывать все UDP-пакеты, адрес отправителя которых не совпадает с адресами их клиентов
решение2
Конфигурация sshd на сервере — одна из самых интересных вещей, на которую стоит обратить внимание, если у вас возникли такие проблемы. Обычно она находится в /etc/ssh/sshd_config.
Вполне вероятно, что в вашем конфигурационном файле есть раздел:
Match Address 10.*.*.*,192.168.0.*
PasswordAuthentication no
Это имеет некоторые правила, специфичные для этих подсетей ( Addressв вашем файле они, скорее всего, будут отличаться). Эти правила применяются только к адресам IPv4, если они единственные, которые соответствуют (а не IPv6), и правила в пределах соответствия применяются только к совпавшему IP-адресу. Поэтому в зависимости от того, подключаетесь ли вы через IPv4 и IPv6, sshd имеет разные правила.
Не все вещи можно задать в Match, но их достаточно, чтобы иметь возможность изменить ситуацию:
AllowAgentForwarding, AllowTcpForwarding, AuthorizedKeysFile,
AuthorizedPrincipalsFile, Banner, ChrootDirectory, ForceCommand,
GatewayPorts, GSSAPIAuthentication, HostbasedAuthentication,
HostbasedUsesNameFromPacketOnly, KbdInteractiveAuthentication,
KerberosAuthentication, MaxAuthTries, MaxSessions,
PasswordAuthentication, PermitEmptyPasswords, PermitOpen,
PermitRootLogin, PermitTunnel, PubkeyAuthentication,
RhostsRSAAuthentication, RSAAuthentication, X11DisplayOffset,
X11Forwarding, X11UseLocalHost
решение3
Я столкнулся с той же проблемой, выровняйтеiptablesсip6tables, а затем исправили эту проблему.