Порт открыт, но я не могу ssh к нему

Мой компьютер компании находится за брандмауэром, я хочу подключиться к удаленному серверу. Порт открыт, но я не могу подключиться к нему, кто-нибудь знает основную причину?

Из моей компании ПК подключается к удаленному серверу:

# telnet my-server 2221 Trying xxxx.. Connected to my-server. Escape character is '^]'. ^C^C^C # nc -vzw5 my-server 2221 Connection to my-server 2221 port [tcp/rockwell-csp1] succeeded! # ssh -vvv my-server -p 2221 OpenSSH_5.3p1, OpenSSL 1.0.1e-fips 11 Feb 2013 debug1: Reading configuration data /root/.ssh/config debug1: Applying options for * debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug2: ssh_connect: needpriv 0 debug1: Connecting to my-server [xxxx] port 2221. debug1: Connection established. debug1: permanently_set_uid: 0/0 debug1: identity file /root/.ssh/identity type -1 debug1: identity file /root/.ssh/identity-cert type -1 debug3: Not a RSA1 key file /root/.ssh/id_rsa. debug2: key_type_from_name: unknown key type '-----BEGIN' debug3: key_read: missing keytype debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug2: key_type_from_name: unknown key type '-----END' debug3: key_read: missing keytype debug1: identity file /root/.ssh/id_rsa type 1 debug1: identity file /root/.ssh/id_rsa-cert type -1 debug1: identity file /root/.ssh/id_dsa type -1 debug1: identity file /root/.ssh/id_dsa-cert type -1 debug1: identity file /root/.ssh/id_ecdsa type -1 debug1: identity file /root/.ssh/id_ecdsa-cert type -1 ^C 

Процесс застрянет навсегда.

Однако в то же время я проверяю статус удаленного сервера, я ясно вижу, что соединение установлено:

 # netstat -at tcp 0 402 myserver:ssh xxxx:11307 ESTABLISHED 

Через некоторое время статус подключения изменится на FIN_WAIT1, а затем будет закрыт:

  # netstat -at tcp 0 402 myserver:ssh xxxx:11307 FIN_WAIT1 

Tcpdump на стороне сервера, в то время как клиент инициирует запрос на соединение:

 # tcpdump -i ppp0 port 2221 -vv tcpdump: listening on ppp0, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes 12:09:01.408239 IP (tos 0x10, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60) server_ip.2221 > client_ip.20999: Flags [S.], cksum 0x21e6 (correct), seq 2805531925, ack 581774329, win 14400, options [mss 1452,sackOK,TS val 9959078 ecr 74287789,nop,wscale 4], length 0 12:09:01.424747 IP (tos 0x0, ttl 50, id 41302, offset 0, flags [DF], proto TCP (6), length 52) client_ip.20999 > server_ip.2221: Flags [.], cksum 0x8711 (correct), seq 1, ack 1, win 457, options [nop,nop,TS val 74287802 ecr 9959078], length 0 12:09:01.448272 IP (tos 0x10, ttl 64, id 62398, offset 0, flags [DF], proto TCP (6), length 454) server_ip.2221 > client_ip.20999: Flags [P.], cksum 0x5dba (correct), seq 1:403, ack 1, win 900, options [nop,nop,TS val 9959082 ecr 74287802], length 402 12:09:01.674641 IP (tos 0x10, ttl 64, id 62399, offset 0, flags [DF], proto TCP (6), length 454) server_ip.2221 > client_ip.20999: Flags [P.], cksum 0x5da3 (correct), seq 1:403, ack 1, win 900, options [nop,nop,TS val 9959105 ecr 74287802], length 402 12:09:01.904523 IP (tos 0x10, ttl 64, id 62400, offset 0, flags [DF], proto TCP (6), length 454) server_ip.2221 > client_ip.20999: Flags [P.], cksum 0x5d8c (correct), seq 1:403, ack 1, win 900, options [nop,nop,TS val 9959128 ecr 74287802], length 402 12:09:02.364225 IP (tos 0x10, ttl 64, id 62401, offset 0, flags [DF], proto TCP (6), length 454) server_ip.2221 > client_ip.20999: Flags [P.], cksum 0x5d5e (correct), seq 1:403, ack 1, win 900, options [nop,nop,TS val 9959174 ecr 74287802], length 402 12:09:03.283694 IP (tos 0x10, ttl 64, id 62402, offset 0, flags [DF], proto TCP (6), length 454) server_ip.2221 > client_ip.20999: Flags [P.], cksum 0x5d02 (correct), seq 1:403, ack 1, win 900, options [nop,nop,TS val 9959266 ecr 74287802], length 402 12:09:05.122593 IP (tos 0x10, ttl 64, id 62403, offset 0, flags [DF], proto TCP (6), length 454) server_ip.2221 > client_ip.20999: Flags [P.], cksum 0x5c4a (correct), seq 1:403, ack 1, win 900, options [nop,nop,TS val 9959450 ecr 74287802], length 402 12:09:08.810407 IP (tos 0x10, ttl 64, id 62404, offset 0, flags [DF], proto TCP (6), length 454) server_ip.2221 > client_ip.20999: Flags [P.], cksum 0x5ad9 (correct), seq 1:403, ack 1, win 900, options [nop,nop,TS val 9959819 ecr 74287802], length 402 12:09:15.006311 IP (tos 0x10, ttl 64, id 17769, offset 0, flags [DF], proto TCP (6), length 52) server_ip.2221 > client_ip.4708: Flags [F.], cksum 0x0499 (correct), seq 1497941342, ack 2936162453, win 900, options [nop,nop,TS val 9960438 ecr 74001029], length 0 12:09:16.176090 IP (tos 0x10, ttl 64, id 62405, offset 0, flags [DF], proto TCP (6), length 454) server_ip.2221 > client_ip.20999: Flags [P.], cksum 0x57f8 (correct), seq 1:403, ack 1, win 900, options [nop,nop,TS val 9960556 ecr 74287802], length 402 12:09:30.927316 IP (tos 0x10, ttl 64, id 62406, offset 0, flags [DF], proto TCP (6), length 454) server_ip.2221 > client_ip.20999: Flags [P.], cksum 0x5234 (correct), seq 1:403, ack 1, win 900, options [nop,nop,TS val 9962032 ecr 74287802], length 402 12:10:00.429743 IP (tos 0x10, ttl 64, id 62407, offset 0, flags [DF], proto TCP (6), length 454) server_ip.2221 > client_ip.20999: Flags [P.], cksum 0x46ac (correct), seq 1:403, ack 1, win 900, options [nop,nop,TS val 9964984 ecr 74287802], length 402 12:10:59.354673 IP (tos 0x10, ttl 64, id 62408, offset 0, flags [DF], proto TCP (6), length 454) server_ip.2221 > client_ip.20999: Flags [P.], cksum 0x2fa4 (correct), seq 1:403, ack 1, win 900, options [nop,nop,TS val 9970880 ecr 74287802], length 402 12:12:57.364324 IP (tos 0x10, ttl 64, id 62409, offset 0, flags [DF], proto TCP (6), length 454) server_ip.2221 > client_ip.20999: Flags [P.], cksum 0x0184 (correct), seq 1:403, ack 1, win 900, options [nop,nop,TS val 9982688 ecr 74287802], length 402 12:14:01.653934 IP (tos 0x10, ttl 64, id 62410, offset 0, flags [DF], proto TCP (6), length 52) server_ip.2221 > client_ip.20999: Flags [F.], cksum 0x0e69 (correct), seq 403, ack 1, win 900, options [nop,nop,TS val 9989120 ecr 74287802], length 0 

  • ssh_exchange_identification: соединение закрыто удаленным хостом
  • сеанс .ksh зависает после того, как он неактивен
  • Почему rsync ищет DSA вместо ключа RSA при запуске cron job?
  • Как подавлять сообщения debug2 во время сеанса SSH?
  • Скопировать / вставить в SSH'd VIM из локального (Windows) буфера обмена
  • параллельная копия файла с использованием тройника неожиданно медленно
  • Моше сохранить полосу пропускания?
  • Проверка отпечатка ключа хоста в старом формате
  • 3 Solutions collect form web for “Порт открыт, но я не могу ssh к нему”

     debug1: Connection established. [...] debug1: identity file /root/.ssh/id_ecdsa-cert type -1 ^C 

    Когда клиент подключается к SSH-серверу, первый обмен данными заключается в том, что сервер и клиент отправляют свои строки версий друг другу. Клиент OpenSSH обычно регистрирует это сразу после списка файлов идентификации, например, из моей системы:

     [...] debug1: identity file /home/devuser/.ssh/id_ed25519-cert type -1 debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_6.6.1p1 Ubuntu-2ubuntu2 debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6.1p1 Ubuntu-2ubuntu2 

    Ваш клиент никогда не регистрировал получение строки версии SSH с сервера. Вероятно, одна из трех вещей:

    1. Брандмауэр или что-то подобное блокирует или удаляет пакеты данных TCP с сервера на клиент.
    2. Клиент подключается к SSH-серверу, но он работает неправильно.
    3. Клиент подключается к чему-то другому, кроме ssh-сервера.

    Вам необходимо устранить эту проблему на сервере. Сервер OpenSSH регистрируется через syslog. Вы должны начать с проверки журналов syslog, чтобы узнать, что, если что-нибудь sshd занесло в журнал о попытке подключения.

    Проверьте разрешения на файл ~/.ssh/authorized_keys . Они должны быть 0600.

    Проверьте права на домашний каталог (~), а не только ~/.ssh .

    Кроме того, вы можете создать новый набор ключей и попробовать:

    • ssh-keygen -t rsa
    • Enter file in which to save the key (/home/demo/.ssh/id_rsa): нажмите Enter
    • Enter passphrase (empty for no passphrase): нажмите enter

    Это будет выглядеть примерно так:

    ssh-keygen -t rsa Generating public/private rsa key pair. Enter file in which to save the key (/home/demo/.ssh/id_rsa): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/demo/.ssh/id_rsa. Your public key has been saved in /home/demo/.ssh/id_rsa.pub. The key fingerprint is: 4a:dd:0a:c6:35:4e:3f:ed:27:38:8c:74:44:4d:93:67 demo@a The key's randomart image is: +--[ RSA 2048]----+ | .oo. | | . oE | | + . o | | . = = . | | = S = . | | o + = + | | . o + o . | | . o | | | +-----------------+

    Ключи id_rsa будут что-то:

    -----BEGIN RSA PRIVATE KEY----- xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx -----END RSA PRIVATE KEY-----

    Проверьте целостность и повторите попытку.

    Возможно, что-то не так с вашим ключом? Вы можете попробовать войти в систему с именем пользователя и паролем, чтобы убедиться, что это не ключ. Это не работает, если sshd настроен только для приема ключей. Вот пример

     ssh -o PreferredAuthentications=password -o PubkeyAuthentication=no -p 2221 username@my-server 
    Linux и Unix - лучшая ОС в мире.