通過 IPv6 SSH 登錄成功,同時使用 IPv4 到同一主機產生“權限被拒絕”
我目前被一個奇怪的問題難住了……我有一個雙棧主機,我想通過 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 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
在事情變得越來越陌生之後(請參閱我問題中的評論主題),我終於弄明白了。首先要做的事情: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 不會干擾它們,得到響應。但是我自己不會通過 ISP 的解析器完成 IPv4 反向查找,它不會收到任何響應並最終會報告 NXHOST(或者它會超時執行)。無論如何 pam_access.so 不會看到牠喜歡的東西,只會說“你不能通過”。
在我修復了解析器配置之後,現在一切都像魅力一樣工作了。但我現在真的必須踩到我的 ISP 的腳趾了……
至於我是怎麼解決的?好吧,通過提高日誌記錄的詳細程度,深入研究
/var/log/everything
以了解事情的發展順序。當我看到我的解析器記錄反向查找嘗試時,我知道發生了什麼。1:從緩解 DNS 放大的角度來看,這完全是胡說八道,因為我確實測試過,並且傳出的 DNS 數據包可以很好地通過——但是那些是他們應該過濾的數據包。事實上,每個最終客戶 ISP 都應該丟棄所有發件人地址與其客戶地址不匹配的 UDP 數據包