Мой сервер подключается через маршрутизатор (NAT) к Интернету, я уже настроил переадресацию портов.
SSH работает нормально при подключении по LAN IP, но не работает при подключении через WAN IP.
Что я пробовал
/etc/ssh)/etc/hosts.allow и /etc/hosts.denysshd: ALL к hosts.allowiptables -L (ничего в этом)ProxyCommand nc %h %p из ответа здесьdebug1: sshd version OpenSSH_6.6.1, OpenSSL 1.0.1f 6 Jan 2014
debug1: key_parse_private2: missing begin marker
debug1: read PEM private key done: type RSA
debug1: private host key: #0 type 1 RSA
debug1: key_parse_private2: missing begin marker
debug1: read PEM private key done: type DSA
debug1: private host key: #1 type 2 DSA
debug1: key_parse_private2: missing begin marker
debug1: read PEM private key done: type ECDSA
debug1: private host key: #2 type 3 ECDSA
debug1: private host key: #3 type 4 ED25519
debug1: rexec_argv[0]='/usr/sbin/sshd'
debug1: rexec_argv[1]='-d'
Set /proc/self/oom_score_adj from 0 to -1000
debug1: Bind to port 222 on 0.0.0.0.
Server listening on 0.0.0.0 port 222.
debug1: Bind to port 222 on ::.
Server listening on :: port 222.
debug1: Server will not fork when running in debugging mode.
debug1: rexec start in 5 out 5 newsock 5 pipe -1 sock 8
debug1: inetd sockets after dupping: 3, 3
Connection from xxx.xxx.xxx.xxx port 58644 on 192.168.0.101 port 222
ssh -vvv -C -A -X -p 2222 username@xxx.xxx.xxx.xxx
OpenSSH_7.2p2 Ubuntu-4ubuntu2.1, OpenSSL 1.0.2g 1 Mar 2016
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: resolving "xxx.xxx.xxx.xxx" port 2222
debug2: ssh_connect_direct: needpriv 0
debug1: Connecting to xxx.xxx.xxx.xxx [xxx.xxx.xxx.xxx] port 2222.
debug1: Connection established.
debug1: key_load_public: No such file or directory
debug1: identity file /home/yan/.ssh/id_rsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/yan/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/yan/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/yan/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/yan/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/yan/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/yan/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/yan/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.2p2 Ubuntu-4ubuntu2.1
ssh_exchange_identification: read: Connection reset by peer
Любой совет будет признателен. Спасибо!
ssh_exchange_identification: read: Connection reset by peer
После долгой борьбы я исправил отказ в соединении ssh, просто выполнив следующую команду.
sudo dhclient
Спасибо за предоставленные журналы. Итак, мы видим, что sshd на сервере видит входящее соединение, но это не все.
Мое первое предположение касается вашего NAT-маршрутизатора; возможно, он плохо справляется со своей работой. Ваше описание неясно в одном отношении: если вы подключаетесь с сервера к интернет-стороне вашего NAT-маршрутизатора, и это не работает, вы можете попытаться подключиться из Интернета.
Вы можете попробовать другие службы, такие как веб-сервер или что-нибудь еще, о чем вы знаете, а затем настроить NAT-маршрутизатор, чтобы он также стал доступным. Работает или нет?
Очень точную информацию можно собрать с помощью таких инструментов, как tcpdump или wirehark. В идеале вы используете его с обеих сторон соединения; тогда вы увидите, как пакеты проходят через NAT.
Допустим, ваш клиент ssh находится на IP 1.1.1.1, а подключение к Интернету вашего сервера - на 3.3.3.3. Таким образом, ввод ssh 3.3.3.3 ENTER должен отправить пакет tcp syn из 1.1.1.1 и случайный порт, скажем, с 55555 на 3.3.3.3. Вы должны увидеть этот пакет на его сетевом интерфейсе с помощью sniffe4r. Этот пакет проходит через Интернет к вашему маршрутизатору NAT на 3.3.3.3, где он преобразуется через NAT к IP-адресу локальной сети, например 192.168.1.11. Сниффер на вашем сервере должен увидеть пакет tcp syn с 1.1.1.1 на 192.168.1.11 порт 22.
Когда sshd принимает соединение, вы должны увидеть ответный пакет в локальном сниффере: пакет tcp ack / syn от 192.168.1.11, порт 22 до 1.1.1.1, порт 55555. Он проходит через ваш NAT-маршрутизатор и должен быть изменен на «с 3.3. .3.3 порт 22 до 1.1.1.1 порт 55555 ". Обычно вы не можете увидеть исходящий пакет, потому что на этом этапе вы не можете обнюхать его. Но если до этого момента все прошло правильно, он перейдет на клиентскую сторону, и там сниффер сможет его поймать. На этом этапе ваш клиент увидит, что соединение установлено, и ответит пакетом с порта 55555 1.1.1.1 на порт 22 3.3.3.3 с пакетом tcp ack для подтверждения установления соединения. Этот пакет будет проходить и получать NAT, и ... ваш сервер также увидит завершенное двустороннее рукопожатие.
Но поскольку мы видим «Сброс соединения одноранговым узлом», скорее всего, ваша проблема проявится до этого момента.
Просто намек на tcpdumping: вы можете увидеть ровный конечный поток пакетов, если вы отправите ssh на свой клиентский компьютер (может быть корневой сервер в Интернете) и запустите tcpdum там - он будет tcpdump пакетов, транспортирующих ваш вывод tcpdump, который снова получит tcpdump и так далее . Чтобы легко управлять этим, вы можете изменить порт своего ssh-сервера (или, по крайней мере, конфигурацию NAT на вашем маршрутизаторе) на другой порт, скажем, 2222.
Тогда ваша команда ssh будет: ssh 3.3.3.3 -p 2222, и вы можете отфильтровать свой tcpdump как
tcpdump port 2222
или, если вы хотите видеть все, кроме вашего рабочего ssh-соединения с клиентом:
tcpdump not port 22
Радоваться, веселиться tcpdumpЯ смотрю интернет-трафик и многому учусь!
TomTomTom