То, что несколько недель назад начиналось как раздражающая проблема, теперь сводит меня с ума!
Дома у меня есть Ubuntu 10.04.03, который действует как файловый сервер. Я делаю резервные копии на нем через rsync с других ящиков, вне сети. Когда я подключаюсь к этому файловому серверу со своего ноутбука, я пересылаю ssh-agent:
root@fileserver:~# env | grep SSH_AUTH
SSH_AUTH_SOCK=/tmp/ssh-IumRLB2628/agent.2628
Есть 1 ящик, также работающий 10.04.03, к которому я не могу подключиться. Все остальные работают нормально, мои ключи SSH не пересылаются, но у этого одного сервера их просто не будет. Это то, что я имею в виду:
root@fileserver:~# ssh the-problematic-server -v
OpenSSH_5.3p1 Debian-3ubuntu7, OpenSSL 0.9.8k 25 Mar 2009
debug1: Reading configuration data /root/.ssh/config
debug1: Applying options for myserver
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to the-problematic-server [n.n.n.n] port 22.
debug1: connect to address n.n.n.n port 22: Connection timed out
ssh: connect to host the-problematic-server port 22: Connection timed out
С того же файлового сервера в другой ящик, используя тот же перенаправленный ssh-агент:
root@fileserver:~# ssh the-good-server -v
debug1: Reading configuration data /root/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to the-good-server [n.n.n.n] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: identity file /root/.ssh/identity type -1
debug1: identity file /root/.ssh/id_rsa type -1
debug1: identity file /root/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3p1 Debian-3ubuntu7
debug1: match: OpenSSH_5.3p1 Debian-3ubuntu7 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.3p1 Debian-3ubuntu7
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'the-good-server.net' is known and matches the RSA host key.
debug1: Found key in /root/.ssh/known_hosts:10
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv THE FORWARDED KEY
debug1: Offering public key: /Users/gerhard/.ssh/calista_rsa <<<<<< THE FORWARDED KEY
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ THE FORWARDED KEY
debug1: Server accepts key: pkalg ssh-rsa blen 277
debug1: Authentication succeeded (publickey).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: Requesting authentication agent forwarding.
debug1: Sending environment.
debug1: Sending env LANG = en_US.UTF-8
Linux the-good-server 2.6.32-32-generic #62-Ubuntu SMP Wed Apr 20 21:52:38 UTC 2011 x86_64 GNU/Linux
Ubuntu 10.04.3 LTS
А теперь, вишенка наверху, с сервера, к которому я только что подключился ...
root@the-good-server:~# ssh the-problematic-server -v
OpenSSH_5.3p1 Debian-3ubuntu7, OpenSSL 0.9.8k 25 Mar 2009
debug1: Reading configuration data /root/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to the-problematic-server [n.n.n.n] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: identity file /root/.ssh/identity type -1
debug1: identity file /root/.ssh/id_rsa type 1
debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
debug1: identity file /root/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3p1 Debian-3ubuntu7
debug1: match: OpenSSH_5.3p1 Debian-3ubuntu7 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.3p1 Debian-3ubuntu7
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'the-problematic-server' is known and matches the RSA host key.
debug1: Found key in /root/.ssh/known_hosts:1
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: client_input_channel_open: ctype auth-agent@openssh.com rchan 2 win 65536 max 16384
debug1: channel 1: new [authentication agent connection]
debug1: confirm auth-agent@openssh.com
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv THE FORWARDED KEY AGAIN
debug1: Offering public key: /Users/gerhard/.ssh/calista_rsa <<<<<< THE FORWARDED KEY AGAIN
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ THE FORWARDED KEY AGAIN
debug1: Server accepts key: pkalg ssh-rsa blen 277
debug1: channel 1: FORCE input drain
debug1: Authentication succeeded (publickey).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: channel 1: free: authentication agent connection, nchannels 2
debug1: Requesting authentication agent forwarding.
debug1: Sending environment.
debug1: Sending env LANG = en_US
Linux the-problematic-server 2.6.34.6-64 #3 SMP Fri Sep 17 16:06:38 UTC 2010 x86_64 GNU/Linux
Ubuntu 10.04.3 LTS
Я также пробовал другого пользователя, кстати, то же самое происходит, когда я пытаюсь подключиться с файлового сервера. Ничего не регистрируется в auth.log этого окна «the-problematic-server», так что кажется, что это даже не доходит до части sshd.
У меня действительно заканчиваются идеи, я ищу более мудрые и резкие варианты. Ура!
root@problematic-server:~# ifconfig
eth0 Link encap:Ethernet HWaddr 00:25:90:13:b3:a0
inet addr:188.165.229.62 Bcast:188.165.229.255 Mask:255.255.255.0
inet6 addr: fe80::225:90ff:fe13:b3a0/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:4021584924 errors:169 dropped:4562 overruns:0 frame:169
TX packets:6302335682 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:2467184127845 (2.4 TB) TX bytes:8418184173437 (8.4 TB)
Memory:febe0000-fec00000
eth0:0 Link encap:Ethernet HWaddr 00:25:90:13:b3:a0
inet addr:94.23.121.1 Bcast:94.23.121.1 Mask:255.255.255.255
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Memory:febe0000-fec00000
eth0:1 Link encap:Ethernet HWaddr 00:25:90:13:b3:a0
inet addr:94.23.152.36 Bcast:94.23.152.36 Mask:255.255.255.255
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Memory:febe0000-fec00000
eth0:2 Link encap:Ethernet HWaddr 00:25:90:13:b3:a0
inet addr:178.32.58.3 Bcast:178.32.58.3 Mask:255.255.255.255
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Memory:febe0000-fec00000
Немногочисленные результаты арпинга:
root@problematic-server:~# arping -D -I eth0 -c 2 188.165.229.62
ARPING 188.165.229.62 from 0.0.0.0 eth0
Sent 2 probes (2 broadcast(s))
Received 0 response(s)
root@opteron16:~# arping -D -I eth0:0 -c 2 94.23.121.1
ARPING 94.23.121.1 from 0.0.0.0 eth0:0
Sent 2 probes (2 broadcast(s))
Received 0 response(s)
root@fileserver:~# ip route list
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.2
default via 192.168.1.1 dev eth0 metric 100
root@problematic-server:~# ip route list
188.165.229.0/24 dev eth0 proto kernel scope link src 188.165.229.62
default via 188.165.229.254 dev eth0 metric 100
root@fileserver:~# dig problematic-server
; <<>> DiG 9.7.0-P1 <<>> problematic-server
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36025
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;problematic-server. IN A
;; ANSWER SECTION:
problematic-server. 1016 IN A 188.165.229.62
;; Query time: 26 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Thu Sep 29 09:32:50 2011
;; MSG SIZE rcvd: 58
root@fileserver:~# arping -c 5 188.165.229.62
ARPING 188.165.229.62
--- 188.165.229.62 statistics ---
5 packets transmitted, 0 packets received, 100% unanswered
Вероятно, это проблема с трюком. Проверьте, можете ли вы пропинговать ящик. Проверьте брандмауэр (iptables), чтобы узнать, не блокирует ли он ваш хост. Проверьте файл /etc/hosts.*, чтобы узнать, не запрещен ли он там.
Посмотрите, может ли ваш хост или хост, к которому вы подключаетесь, иметь конфликт IP. Вы можете выполнить "arping" на хосте и посмотреть, вернет ли вам несколько аппаратных адресов.
Вы выполняете агрегацию каналов или у вас есть несколько сетевых карт на любом из хостов? Это может быть проблема с маршрутизацией.
[обновление] Похоже, у вас возникла проблема на пути от файлового сервера к проблемному серверу. По какой-то причине похоже, что данные не могут маршрутизироваться между этими сетями. Вы используете сетевые маршрутизаторы, которые маршрутизируют этот трафик? Похоже, проблема с вашим роутером.
Это все еще не решено ... Журнал с маршрутизатора LAN с включенным межсетевым экраном:
Local User (MAC=00-17-31-F2-63-7D): 192.168.1.2:57335 -> 188.165.229.62:22 (TCP)
[FW_Session][Pass][304/15000][@S:R=13:1, 192.168.1.2:57335->188.165.229.62:22]
[FILTER][Pass][lan->wan, 0:11:58.990][@S:R=13:1, 192.168.1.2:57335->188.165.229.62:22][TCP][HLen=20, TLen=60, Flag=S, Seq=1090671344, Ack=0, Win=5840]
И без межсетевого экрана:
Local User (MAC=00-17-31-F2-63-7D): 192.168.1.2:57336 -> 188.165.229.62:22 (TCP)
Все, что я получаю, это:
debug1: Connecting to 188.165.229.62 [188.165.229.62] port 22.
debug1: connect to address 188.165.229.62 port 22: Connection timed out
ssh: connect to host 188.165.229.62 port 22: Connection timed out
Я могу пинговать и трассировать адрес нормально. Я могу подключиться с ноутбука в той же домашней локальной сети. На обеих машинах нет брандмауэра. Я в тупике @ACase.
Это не столько проблема агента SSH, сколько общая проблема с сетевым подключением. Таким образом, применяются обычные шаги диагностики - ping, tcpdump, проверка брандмауэров и т. Д.