Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Why ssh client breaks connection in expecting SSH2_MSG_NEWKEYS state?
347 views
Skip to first unread message
Yuri
Dec 11, 2013, 4:28:03 AM12/11/13
to
I have a client host that I don't have access to now, which attempts to
establish ssh connection back to my BSD server using the private key.
Client runs this command:
/usr/bin/ssh -i ~/.ssh/my_key_rsa -o "ExitOnForwardFailure yes" -p
$HPORT $HUSER@$HOST -R $LPORT:localhost:$LPORT -N
On the server debug log looks like this:
Connection from NNN.NNN.NNN.NNN port 43567
debug1: HPN Disabled: 0, HPN Buffer Size: 65536
debug1: Client protocol version 2.0; client software version
OpenSSH_5.9p1 Debian-5ubuntu1
debug1: match: OpenSSH_5.9p1 Debian-5ubuntu1 pat OpenSSH_5*
debug1: Remote is not HPN-aware
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.2_hpn13v11 FreeBSD-20130515
debug1: permanently_set_uid: 22/22 [preauth]
debug1: list_hostkey_types: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256 [preauth]
debug1: SSH2_MSG_KEXINIT sent [preauth]
debug1: SSH2_MSG_KEXINIT received [preauth]
debug1: kex: client->server aes128-ctr hmac-md5 none [preauth]
debug1: kex: server->client aes128-ctr hmac-md5 none [preauth]
debug1: expecting SSH2_MSG_KEX_ECDH_INIT [preauth]
debug1: SSH2_MSG_NEWKEYS sent [preauth]
debug1: expecting SSH2_MSG_NEWKEYS [preauth]
Connection closed by NNN.NNN.NNN.NNN [preauth]
Client breaks connection right after 'expecting SSH2_MSG_NEWKEYS'.
I can always successfully connect to this server myself, and successful
log continuation looks like this:
debug1: SSH2_MSG_NEWKEYS received
debug1: KEX done
debug1: userauth-request for user minsk service ssh-connection method none
debug1: attempt 0 failures 0
...
When I have set this client up, it was able to connect to similar BSD
server system over the local net. So it does have the correct key. But
over the internet connection now fails like this.
What can possibly cause client to break connection after 'expecting
SSH2_MSG_NEWKEYS', and not proceed to SSH2_MSG_NEWKEYS?
I tried the same with similar linux client system running in VM, and it
succeeds to connect. I also tried to downgrade server from version 6.2
to 5.8, and both versions exhibit the same problem.
Yuri
_______________________________________________
openssh-unix-dev mailing list
openssh-...@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
establish ssh connection back to my BSD server using the private key.
Client runs this command:
/usr/bin/ssh -i ~/.ssh/my_key_rsa -o "ExitOnForwardFailure yes" -p
$HPORT $HUSER@$HOST -R $LPORT:localhost:$LPORT -N
On the server debug log looks like this:
Connection from NNN.NNN.NNN.NNN port 43567
debug1: HPN Disabled: 0, HPN Buffer Size: 65536
debug1: Client protocol version 2.0; client software version
OpenSSH_5.9p1 Debian-5ubuntu1
debug1: match: OpenSSH_5.9p1 Debian-5ubuntu1 pat OpenSSH_5*
debug1: Remote is not HPN-aware
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.2_hpn13v11 FreeBSD-20130515
debug1: permanently_set_uid: 22/22 [preauth]
debug1: list_hostkey_types: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256 [preauth]
debug1: SSH2_MSG_KEXINIT sent [preauth]
debug1: SSH2_MSG_KEXINIT received [preauth]
debug1: kex: client->server aes128-ctr hmac-md5 none [preauth]
debug1: kex: server->client aes128-ctr hmac-md5 none [preauth]
debug1: expecting SSH2_MSG_KEX_ECDH_INIT [preauth]
debug1: SSH2_MSG_NEWKEYS sent [preauth]
debug1: expecting SSH2_MSG_NEWKEYS [preauth]
Connection closed by NNN.NNN.NNN.NNN [preauth]
Client breaks connection right after 'expecting SSH2_MSG_NEWKEYS'.
I can always successfully connect to this server myself, and successful
log continuation looks like this:
debug1: SSH2_MSG_NEWKEYS received
debug1: KEX done
debug1: userauth-request for user minsk service ssh-connection method none
debug1: attempt 0 failures 0
...
When I have set this client up, it was able to connect to similar BSD
server system over the local net. So it does have the correct key. But
over the internet connection now fails like this.
What can possibly cause client to break connection after 'expecting
SSH2_MSG_NEWKEYS', and not proceed to SSH2_MSG_NEWKEYS?
I tried the same with similar linux client system running in VM, and it
succeeds to connect. I also tried to downgrade server from version 6.2
to 5.8, and both versions exhibit the same problem.
Yuri
_______________________________________________
openssh-unix-dev mailing list
openssh-...@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Darren Tucker
Dec 11, 2013, 5:09:35 AM12/11/13
to
On Wed, Dec 11, 2013 at 8:28 PM, Yuri <yu...@rawbw.com> wrote:
> I have a client host that I don't have access to now, which attempts to
> establish ssh connection back to my BSD server using the private key.
> Client runs this command:
> /usr/bin/ssh -i ~/.ssh/my_key_rsa -o "ExitOnForwardFailure yes" -p $HPORT
> $HUSER@$HOST -R $LPORT:localhost:$LPORT -N
>
> On the server debug log looks like this:
> Connection from NNN.NNN.NNN.NNN port 43567
> debug1: HPN Disabled: 0, HPN Buffer Size: 65536
That's a modified ssh server. Can you reproduce the problem with a
> I have a client host that I don't have access to now, which attempts to
> establish ssh connection back to my BSD server using the private key.
> Client runs this command:
> /usr/bin/ssh -i ~/.ssh/my_key_rsa -o "ExitOnForwardFailure yes" -p $HPORT
> $HUSER@$HOST -R $LPORT:localhost:$LPORT -N
>
> On the server debug log looks like this:
> Connection from NNN.NNN.NNN.NNN port 43567
> debug1: HPN Disabled: 0, HPN Buffer Size: 65536
stock openssh from openssh.com?
You might get some more clues if you run the server in debug mode
(/path/to/sshd -ddde).
--
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69
Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.
Yuri
Dec 11, 2013, 6:17:10 AM12/11/13
to
On 12/11/2013 02:09, Darren Tucker wrote:
> That's a modified ssh server. Can you reproduce the problem with a
> stock openssh from openssh.com?
The modification is minor, to port for FreeBSD. It did work with this
> That's a modified ssh server. Can you reproduce the problem with a
> stock openssh from openssh.com?
modification on the same system.
>
> You might get some more clues if you run the server in debug mode
> (/path/to/sshd -ddde).
around the failure.
I also looked at the server system call trace, and the first major
difference is that in successful case one read(2) call returns 16 bytes,
and in failed case it returns 0 bytes, which means disconnect.
What are the possible client failure points between the server events
'expecting SSH2_MSG_NEWKEYS' and 'SSH2_MSG_NEWKEYS received'?
Yuri
Darren Tucker
Dec 11, 2013, 8:57:46 AM12/11/13
to
On Wed, Dec 11, 2013 at 10:17 PM, Yuri <yu...@rawbw.com> wrote:
> On 12/11/2013 02:09, Darren Tucker wrote:
>>
>> That's a modified ssh server. Can you reproduce the problem with a
>> stock openssh from openssh.com?
>
> The modification is minor, to port for FreeBSD. It did work with this
> modification on the same system.
Please post the debug output from the stock openssh client and server.
> On 12/11/2013 02:09, Darren Tucker wrote:
>>
>> That's a modified ssh server. Can you reproduce the problem with a
>> stock openssh from openssh.com?
>
> The modification is minor, to port for FreeBSD. It did work with this
> modification on the same system.
>> You might get some more clues if you run the server in debug mode
>> (/path/to/sshd -ddde).
>
> Unfortunately, this didn't give any new clues. No new debug messages around
> the failure.
>
> I also looked at the server system call trace, and the first major
> difference is that in successful case one read(2) call returns 16 bytes, and
> in failed case it returns 0 bytes, which means disconnect.
>
> What are the possible client failure points between the server events
> 'expecting SSH2_MSG_NEWKEYS' and 'SSH2_MSG_NEWKEYS received'?
--
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69
Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.
Yuri
Dec 11, 2013, 2:35:21 PM12/11/13
to
On 12/11/2013 05:57, Darren Tucker wrote:
>> >What are the possible client failure points between the server events
>> >'expecting SSH2_MSG_NEWKEYS' and 'SSH2_MSG_NEWKEYS received'?
> tough to say without seeing the server-side debug output.
I think I figured out the cause. Fresh ssh client always asks this:
>> >What are the possible client failure points between the server events
>> >'expecting SSH2_MSG_NEWKEYS' and 'SSH2_MSG_NEWKEYS received'?
> tough to say without seeing the server-side debug output.
The authenticity of host '[server.host.name]:NNN ([server-host-ip]:NNN)'
can't be established.
ECDSA key fingerprint is NN:NN:NN....
Are you sure you want to continue connecting (yes/no)?
I think this "yes" has never been entered for this server host on client.
So, as I understand, in my case the server can do absolutely nothing,
and it requires the manual interruption on the client to hit "yes".
Or those options should be added on the client: -o
"StrictHostKeyChecking=no" -o "UserKnownHostsFile=/dev/null"
Yuri
Damien Miller
Dec 11, 2013, 5:06:43 PM12/11/13
to
On Wed, 11 Dec 2013, Yuri wrote:
> On 12/11/2013 02:09, Darren Tucker wrote:
> > That's a modified ssh server. Can you reproduce the problem with a
> > stock openssh from openssh.com?
>
> The modification is minor, to port for FreeBSD. It did work with this
> modification on the same system.
No, it isn't:
> On 12/11/2013 02:09, Darren Tucker wrote:
> > That's a modified ssh server. Can you reproduce the problem with a
> > stock openssh from openssh.com?
>
> The modification is minor, to port for FreeBSD. It did work with this
> modification on the same system.
> debug1: Local version string SSH-2.0-OpenSSH_6.2_hpn13v11 FreeBSD-20130515
-d
0 new messages