我目前被一個奇怪的問題難住了……我有一個雙棧主機，我想透過 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 iptables：
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 ip6 表
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 根伺服器開始遞歸解析。當我第一次安裝它時，這個設定確實有效。
現在我的 ISP 輸入圖片，人們不明白 DNS 放大攻擊是如何運作的。長話短說：我確信我的 ISP 會隨機處理傳入的 DNS 封包，也就是說，有些事情現在必須透過自己的解析器來解決一段時間，而其他 DNS 位址則由您自己遞歸解析 - 官方原因是為了減輕DNS 放大攻擊，但他們這樣做是錯誤的^1。
由於我不想大幅改變我的設置，所以我只是將 ISP 的 DNS 解析器作為非遞歸轉發放在本地 DNS 解析器的末尾，因此，如果遞歸解析嘗試超時，它會嘗試我的 ISP 的解析器。到目前為止這有效。但是當我配置這個時，我犯了一個小錯誤：我輸入了ISP 的DNS 解析器，使其僅在本地範圍內的主機（即192.168.0.0/16）中工作，但忘記了localhost，又名我的路由器，這是我嘗試的主機SSH 進入，解析器將不是考慮 ISP 的解析器。
pam_access.so 嘗試對對等位址進行反向查找；這就結束了循環：因為對於 IPv6 反向查找，將存取 DNS IPv6 根伺服器，封包將通過 6in4 隧道，而不會受到 ISP 的干擾，從而獲得回應。但是 IPv4 反向查找不會由我自己透過 ISP 的解析器完成，這將不會收到任何回應，並且最終會報告 NXHOST（或它會逾時運行）。無論如何，pam_access.so 不會看到牠喜歡的東西，只會說「你不會通過」。
在我修復了該解析器配置之後，現在一切都再次變得充滿魅力。但現在我真的必須對我的 ISP 採取行動...
至於我是怎麼解決的呢？好吧，透過猛烈地研究日誌的冗長/var/log/everything來了解事情展開的順序。當我看到我的解析器記錄反向查找嘗試時，我知道發生了什麼。
1：從 DNS 放大緩解的角度來看，這完全是無稽之談，因為我確實測試過，傳出的 DNS 封包可以很好地通過 - 然而這些是它們應該過濾的封包。事實上，每個最終客戶 ISP 都應該丟棄所有寄件者地址與客戶地址不符的 UDP 資料包
答案2
如果您遇到此類問題，伺服器上 sshd 的配置是最有趣的事情之一。它通常在/etc/ssh/sshd_config.
您的設定檔中很可能有一個部分：
Match Address 10.*.*.*,192.168.0.*
PasswordAuthentication no
其中有一些特定於這些子網路的規則（Address您文件中的規則很可能會有所不同）。如果 IPv4 位址是唯一符合的位址（而非 IPv6），則這些規則僅適用於 IPv4 位址，且符合中的規則僅適用於相符的 IP 位址。因此，根據您是否透過 IPv4 和 IPv6 連接，sshd 有不同的規則。
並不是所有的東西都可以在 a 中設置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和ip6表，然後解決了這個問題。