0

I have a weird situation where I can SSH into my VM from another machine on the network, but not from the host itself. Vital stats:

  • Host: OS X Yosemite
  • Guest: Ubuntu 14.04
  • VirtualBox version: 4.3.16 r65972
  • Network config: NAT, port 3022 forwarded to the guest as port 22 (ssh)

Here's what happens when I run ssh -vvv -p 3022 ezuk@localhost on the host:

OpenSSH_6.2p2, OSSLShim 0.9.8r 8 Dec 2011
debug1: Reading configuration data /etc/ssh_config
debug1: /etc/ssh_config line 20: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to localhost [::1] port 3022.
debug1: connect to address ::1 port 3022: Connection refused
debug1: Connecting to localhost [127.0.0.1] port 3022.
debug1: Connection established.
debug1: identity file /Users/ezukerman/.ssh/id_rsa type 1
debug1: identity file /Users/ezukerman/.ssh/id_rsa-cert type -1
debug1: identity file /Users/ezukerman/.ssh/id_dsa type -1
debug1: identity file /Users/ezukerman/.ssh/id_dsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.2
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6.1p1 Ubuntu-2ubuntu2
debug1: match: OpenSSH_6.6.1p1 Ubuntu-2ubuntu2 pat OpenSSH*
debug2: fd 5 setting O_NONBLOCK
debug3: put_host_port: [localhost]:3022
debug3: load_hostkeys: loading entries for host "[localhost]:3022" from file "/Users/ezukerman/.ssh/known_hosts"
debug3: load_hostkeys: found key type RSA in file /Users/ezukerman/.ssh/known_hosts:1
debug3: load_hostkeys: loaded 1 keys
debug3: order_hostkeyalgs: prefer hostkeyalgs: [email protected],[email protected],ssh-rsa
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: [email protected],[email protected],ssh-rsa,[email protected],[email protected],ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,[email protected],[email protected],aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected]
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,[email protected],[email protected],aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected]
debug2: kex_parse_kexinit: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-md5,hmac-sha1,[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-md5,hmac-sha1,[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,[email protected],zlib
debug2: kex_parse_kexinit: none,[email protected],zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: kex_parse_kexinit: [email protected],ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,[email protected],[email protected],[email protected],aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected]
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,[email protected],[email protected],[email protected],aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected]
debug2: kex_parse_kexinit: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-md5,hmac-sha1,[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-md5,hmac-sha1,[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,[email protected]
debug2: kex_parse_kexinit: none,[email protected]
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: mac_setup: found [email protected]
debug1: kex: server->client aes128-ctr [email protected] none
debug2: mac_setup: found [email protected]
debug1: kex: client->server aes128-ctr [email protected] none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug2: dh_gen_key: priv key bits set: 124/256
debug2: bits set: 520/1024
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Server host key: RSA 3a:dd:2f:fd:ed:3f:95:f0:17:1d:8e:3f:04:1c:5b:9f
debug3: put_host_port: [127.0.0.1]:3022
debug3: put_host_port: [localhost]:3022
debug3: load_hostkeys: loading entries for host "[localhost]:3022" from file "/Users/ezukerman/.ssh/known_hosts"
debug3: load_hostkeys: found key type RSA in file /Users/ezukerman/.ssh/known_hosts:1
debug3: load_hostkeys: loaded 1 keys
debug1: Host '[localhost]:3022' is known and matches the RSA host key.
debug1: Found key in /Users/ezukerman/.ssh/known_hosts:1
debug2: bits set: 492/1024
debug1: ssh_rsa_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /Users/ezukerman/.ssh/id_rsa (0x7f83a35001f0),
debug2: key: /Users/ezukerman/.ssh/id_dsa (0x0),
debug1: Authentications that can continue: publickey,password
debug3: start over, passed a different list publickey,password
debug3: preferred publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /Users/ezukerman/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /Users/ezukerman/.ssh/id_dsa
debug3: no such identity: /Users/ezukerman/.ssh/id_dsa: No such file or directory
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred: ,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password
ezuk@localhost's password:
debug3: packet_send2: adding 64 (len 52 padlen 12 extra_pad 64)
debug2: we sent a password packet, wait for reply
debug1: Authentication succeeded (password).
Authenticated to localhost ([127.0.0.1]:3022).
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug1: Requesting [email protected]
debug1: Entering interactive session.
debug2: callback start
debug2: fd 5 setting TCP_NODELAY
debug3: packet_set_tos: set IP_TOS 0x10
debug2: client_session2_setup: id 0
debug2: channel 0: request pty-req confirm 1
debug1: Sending environment.
debug3: Ignored env Apple_PubSub_Socket_Render
debug3: Ignored env COMMAND_MODE
debug3: Ignored env HOME
debug3: Ignored env ITERM_PROFILE
debug3: Ignored env ITERM_SESSION_ID
debug1: Sending env LANG = en_US.UTF-8
debug2: channel 0: request env confirm 0
debug3: Ignored env LOGNAME
debug3: Ignored env PATH
debug3: Ignored env PWD
debug3: Ignored env SECURITYSESSIONID
debug3: Ignored env SHELL
debug3: Ignored env SHLVL
debug3: Ignored env SSH_AUTH_SOCK
debug3: Ignored env TERM
debug3: Ignored env TERM_PROGRAM
debug3: Ignored env TMPDIR
debug3: Ignored env USER
debug3: Ignored env XPC_FLAGS
debug3: Ignored env XPC_SERVICE_NAME
debug3: Ignored env __CF_USER_TEXT_ENCODING
debug3: Ignored env __fish_bin_dir
debug3: Ignored env __fish_datadir
debug3: Ignored env __fish_help_dir
debug3: Ignored env __fish_runtime_dir
debug3: Ignored env __fish_sysconfdir
debug2: channel 0: request shell confirm 1
debug2: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug2: channel_input_status_confirm: type 99 id 0
debug2: PTY allocation request accepted on channel 0
debug2: channel 0: rcvd adjust 2097152
debug2: channel_input_status_confirm: type 99 id 0
debug2: shell request accepted on channel 0
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: client_input_channel_req: channel 0 rtype [email protected] reply 0
debug2: channel 0: rcvd eow
debug2: channel 0: close_read
debug2: channel 0: input open -> closed
debug2: channel 0: rcvd eof
debug2: channel 0: output open -> drain
debug2: channel 0: obuf empty
debug2: channel 0: close_write
debug2: channel 0: output drain -> closed
debug2: channel 0: rcvd close
debug3: channel 0: will not send data after close
debug2: channel 0: almost dead
debug2: channel 0: gc: notify user
debug2: channel 0: gc: user detached
debug2: channel 0: send close
debug2: channel 0: is dead
debug2: channel 0: garbage collecting
debug1: channel 0: free: client-session, nchannels 1
debug3: channel 0: status: The following connections are open:
  #0 client-session (t4 r0 i3/0 o3/0 fd -1/-1 cc -1)

Connection to localhost closed.
Transferred: sent 2924, received 2840 bytes, in 0.4 seconds
Bytes per second: sent 7835.7, received 7610.6
debug1: Exit status 1

tl;dr: Port is open, password auth works, and then... the session is closed. I don't think it's a problem with assigning the shell or something like that, because when I SSH in from another machine on the same LAN, it works beautifully.

Any ideas?

Improve this question
3
  • pls. add a debug info from sshd site. Perhaps this brings us further. I assume you do not have any IP address restrictions defined on sshd site, right?
    – ryder
    Commented Mar 3, 2015 at 11:08
  • @ryder- what would you like me to add? No IP addresses restricted.
    – ezuk
    Commented Mar 5, 2015 at 14:48
  • you already add a debug info from ssh client, can you add this from the sshd server?
    – ryder
    Commented Mar 5, 2015 at 14:53

3 Answers 3

Reset to default
1

I resolved the issue by switching to a standalone SSH client. The problem isn't with the VM, it's with the host -- the Mac's SSH client just acts funny.

Not sure what the exactly issue with the SSH client is, but switching to a different one just solved it.

Improve this answer
0

I saw a very similar error before. Since you are able to login I think the key lines are:

debug3: channel 0: status: The following connections are open:
#0 client-session (t4 r0 i3/0 o3/0 fd -1/-1 cc -1)

If you search around for this you'll find some related issues. Here's one on serverfault:

https://serverfault.com/questions/384676/linux-closing-connection-after-successful-login

"There are a couple of similar posts suggesting that this could be a problem with spawning a shell because of incorrect settings for the shell path in /etc/passwd"

# cat /etc/passwd | grep projectdp
projectdp:x:1000:1000:projectdp /home/projectdp:/bin/zsh <-- check this exists

...See the link for more details. I am direct quoting, emphasis and substitutions mine.

Improve this answer
1
  • Yeah.. I'm afraid i've been down that path before and checked it already. /etc/passwd contains a valid shell path for this user (/usr/bin/fish).
    – ezuk
    Commented Mar 5, 2015 at 14:47
0

This might be because of the localhost.

As you now NAT has an internal and an external interface:

Now let your host access the same way as other clients. That means instead of localhost connect to localIP:3022 and compare the results.

Improve this answer
5
  • I doubt this is valid, you can see in the debug that localhost resolves to 127.0.0.1 and the user is authenticated. The transport is working given the IP/name resolution.
    – p̻̻̥r̥̻̥o̻j̤͛ec͔t̞dp
    Commented Mar 3, 2015 at 18:05
  • I wanted to avoid connecting to 1270.0.1, I meant you explicitly used "ssh -vvv -p 3022 [email protected]" (where 192.168.x.y is the public IP of your computer NAT) Isn't there any SSH server also on your host machine? (so that the SSH client is confused someway about managing the peer keys)
    – F.I.V
    Commented Mar 4, 2015 at 12:53
  • It is possible that there's an SSH server also listening on the host, however it would be listening on port 22 most likely, not 3022 which was specified to forward to the guests' port 22. You might want to be careful thinking about 192.168.x.y as a public IP, I think what you mean is that it's the external interface's IP. This address is condiered a private network IP address. Lastly in the debug the authentication fails on the keys but it does successfully login using the password. Then at a later point the connection is severed.
    – p̻̻̥r̥̻̥o̻j̤͛ec͔t̞dp
    Commented Mar 4, 2015 at 17:31
  • Yes, exactly, I meant to say external edge of NAT. Could you initiate the SSH from another user account (wanted to make sure that some cached keys don't introduce issues). Also using external IP of your host instead of 127.0.0.1 to ensure the reverse path of NAT port forwarding experiences the same as other nodes.Thanks
    – F.I.V
    Commented Mar 5, 2015 at 6:26
  • SSHing the real LAN ip address (192.168.1.28:3022) gives exactly the same problems.
    – ezuk
    Commented Mar 5, 2015 at 14:45

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .