Wednesday, October 27, 2021

[SOLVED] SSH stuck to client_input_global_request: rtype [email protected] want_reply 0

Issue

I am trying to connect to a vagrant machine on my mac (I'm using Mac OS High Sierra). I'm using a private key to connect to it but I get stuck on this line:

client_input_global_request: rtype [email protected] want_reply 0

I use the following command line:

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 [email protected]

and this is the result:

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: [email protected]
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: [email protected] MAC: <implicit> compression: none
debug1: kex: client->server cipher: [email protected] 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 [email protected]
debug1: Entering interactive session.
debug1: pledge: network
debug1: client_input_global_request: rtype [email protected] want_reply 0

Could someone give me a hint to get rid of this problem? I get stuck to this point, forever. I think the problem should be between Vagrant and Mac Os. The same vagrant virtual machine works under a Windows environment.


Solution

I had the same problem with ProxyJump directive while connecting through bastion host to an instance. The process was timing out after the same line. Turned out there was a problem with Firewall dropping connection from bastion host.

As far as I can see your connection to 192.168.33.10 succeeds and hangs after opening listening port 5423 on localhost. So you either have a firewall blocking connections to localhost on port 5423 or a firewall on 192.168.33.10 blocking port 5423.

To solve this you have to test these ports manually with telnet\nmap utilities The syntax is as follows:

telnet localhost 5423

or

nmap -p 5423 192.168.33.10

If port is open you will see the following message

Escape character is '^]'.

If port is closed by firewall telnet will hang with the following message

Trying 172.18.0.47...

If port is closed by fireawll nmap will show you that its filtered

PORT STATE SERVICE

80/tcp filtered http

If port is open via firewall but there's no application listening on this port you will get a message

telnet: Unable to connect to remote host: Connection refused

After that you need to open those ports. On linux machines simply issue following command

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

On MacOS you need to modify this file /etc/pf.conf (found via this article)



Answered By - Max Shepelev