SSH привязан к client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0 - PullRequest
Новая
       87

SSH привязан к client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0

0 голосов
/ 21 ноября 2018

Я пытаюсь подключиться к бродячей машине на моем Mac (я использую Mac OS High Sierra).Я использую закрытый ключ для подключения к нему, но я застреваю в этой строке: 

client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0

Я использую следующую командную строку: 

ssh -v -N  -L localhost:5432:192.168.33.10:5432 -o ConnectTimeout=1 -o ServerAliveInterval=30 -o ServerAliveCountMax=3 -i /Users/MacUser/Desktop/Vagrant_Project/.vagrant/machines/default/virtualbox/private_key -p 22 vagrant@192.168.33.10

, и это результат:

OpenSSH_7.6p1, LibreSSL 2.6.2
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 48: Applying options for *
debug1: Connecting to 192.168.33.10 [192.168.33.10] port 22.
debug1: fd 3 clearing O_NONBLOCK
debug1: Connection established.
debug1: key_load_public: No such file or directory
debug1: identity file /Users/MacUser/Desktop/Vagrant_Project/.vagrant/machines/default/virtualbox/private_key type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/MacUser/Desktop/Vagrant_Project/.vagrant/machines/default/virtualbox/private_key-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_7.6
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.2p2 Ubuntu-4ubuntu2.6
debug1: match: OpenSSH_7.2p2 Ubuntu-4ubuntu2.6 pat OpenSSH* compat 0x04000000
debug1: Authenticating to 192.168.33.10:22 as 'vagrant'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256@libssh.org
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:Ju/ngomtpiyMPtrgFsK+ttKbFUR9BwW3CyDFjo5KITc
debug1: Host '192.168.33.10' is known and matches the ECDSA host key.
debug1: Found key in /Users/MacUser/.ssh/known_hosts:3
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<rsa-sha2-256,rsa-sha2-512>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /Users/MacUser/Desktop/Vagrant_Project/.vagrant/machines/default/virtualbox/private_key
debug1: Authentication succeeded (publickey).
Authenticated to 192.168.33.10 ([192.168.33.10]:22).
debug1: Local connections to localhost:5432 forwarded to remote address 192.168.33.10:5432
debug1: Local forwarding listening on ::1 port 5432.
debug1: channel 0: new [port listener]
debug1: Local forwarding listening on 127.0.0.1 port 5432.
debug1: channel 1: new [port listener]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: pledge: network
debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0

Может ли кто-нибудь дать мне подсказку, чтобы избавиться от этой проблемы?Я застрял в этой точке навсегда.Я думаю, что проблема должна быть между Vagrant и Mac Os.Эта же бродячая виртуальная машина работает в среде Windows.

1 Ответ

0 голосов
/ 09 января 2019

У меня была такая же проблема с директивой ProxyJump при подключении через бастионный хост к экземпляру.Процесс истекал после той же строки.Оказалось, что была проблема с разрывом соединения брандмауэром с хоста бастиона.

Насколько я вижу, ваше подключение к 192.168.33.10 успешно и зависает после открытия порта прослушивания 5423 на локальном хосте.Таким образом, у вас есть либо брандмауэр, блокирующий соединения с локальным узлом на порту 5423 , либо брандмауэр на 192.168.33.10 блокирующий порт 5423 .

Для решениядля этого вам необходимо вручную проверить эти порты с помощью утилит telnet \ nmap . Синтаксис следующий: 

telnet localhost 5423

или 

nmap -p 5423 192.168.33.10

Если порт открыт, высм. следующее сообщение

Escape-символ '^]'.

Если порт закрыт брандмауэром, telnet будет зависать со следующим сообщением

Попытка 172.18.0.47 ...

Если порт закрыт fireawll, nmap покажет вам, что его отфильтрованный

PORT STATE SERVICE

80/ tcp отфильтрованный http

Если порт открыт через брандмауэр, но на этом порту нет прослушивающих приложений, вы получите сообщение

telnet: Невозможно подключиться к удаленному хосту:Отказ в соединении

После этого вам нужно открыть эти порты.На машинах Linux просто введите следующую команду 

iptables -I INPUT -p tcp --dport 5423 --syn -j ACCEPT && service iptables save

В MacOS вам нужно изменить этот файл / etc / pf.conf (находится в этой статье article )

...