Re: [gentoo-user] SSH rekeying straight after authentication

[Mick]

On Monday 27 Feb 2017 16:49:42 Andrew Savchenko wrote:
> On Thu, 23 Feb 2017 20:10:05 + Mick wrote:
> > I am trying to understand why an ssh server keeps dropping the connection
> > when using openssh on Linux straight after a successful authentication,
> > but it works fine with Filezilla in MSWindows.
> 
> [...]
> 
> > I am guessing all this respawning probably triggers some DDoS protection
> > limit on the server and it disconnects the client.  Have you observed
> > anything similar and would you know why Linux fails, but MSWindows works
> > as it should?
> I use HPN for years and connect to hundreds of servers, most of
> them are without HPN support. I have no problems so far. But HPN is
> unofficial and it may trigger problems. Maybe this is a bug in HPN,
> maybe a server's custom protection.
> 
> Try to report this on bugzilla for openssh maintainers.
> 
> Best regards,
> Andrew Savchenko

Thanks Andrew, but I am not sure if it is an openssh bug or the particular 
server SSH implementation, which I do not control and the BOFH isn't 
particular helpful.

It may be an SSH implementation interoperability problem.  A Linux Mint PC 
suddenly fails to connect using the latest OpenSSH version (OpenSSH_7.2p2 
Ubuntu-4ubuntu2.1, OpenSSL 1.0.2g  1 Mar 2016) because the server does not 
appear to return a list of authentication methods as it should.

The Gentoo PCs fail to connect because it seems the client switches from 
single to multithreaded CTR transaction and the SSH server then becomes over-
protective.

I've posted in OpenSSH M/L about the Linux Mint behaviour, but had no 
responses.
-- 
Regards,
Mick

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-user] SSH rekeying straight after authentication

[Andrew Savchenko]

On Thu, 23 Feb 2017 20:10:05 + Mick wrote:
> I am trying to understand why an ssh server keeps dropping the connection 
> when 
> using openssh on Linux straight after a successful authentication, but it 
> works fine with Filezilla in MSWindows.
[...]
> I am guessing all this respawning probably triggers some DDoS protection 
> limit 
> on the server and it disconnects the client.  Have you observed anything 
> similar and would you know why Linux fails, but MSWindows works as it should?

I use HPN for years and connect to hundreds of servers, most of
them are without HPN support. I have no problems so far. But HPN is
unofficial and it may trigger problems. Maybe this is a bug in HPN,
maybe a server's custom protection.

Try to report this on bugzilla for openssh maintainers.

Best regards,
Andrew Savchenko


pgpEM5hBjqNZP.pgp
Description: PGP signature

Re: [gentoo-user] SSH rekeying straight after authentication

[Mick]

On Thursday 23 Feb 2017 22:18:25 Stroller wrote:
> > On 23 Feb 2017, at 20:10, Mick  wrote:
> >
> > I am trying to understand why an ssh server keeps dropping the connection
> > when using openssh on Linux straight after a successful authentication,
> > but it works fine with Filezilla in MSWindows.
> >
> > The connection initially appears to succeed like so:
> >
> > debug2: service_accept: ssh-userauth
> > debug1: SSH2_MSG_SERVICE_ACCEPT received
>
> Are both clients using SSH2? And the same cyphers?
>
> Stroller.

Yes and yes, thanks Stroller.  The problem seems to be related to the client 
using HPN and
the server not.
--
Regards,
Mick


signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-user] SSH rekeying straight after authentication

[Stroller]

> On 23 Feb 2017, at 20:10, Mick  wrote:
> 
> I am trying to understand why an ssh server keeps dropping the connection 
> when 
> using openssh on Linux straight after a successful authentication, but it 
> works fine with Filezilla in MSWindows.
> 
> The connection initially appears to succeed like so:
> 
> debug2: service_accept: ssh-userauth
> debug1: SSH2_MSG_SERVICE_ACCEPT received

Are both clients using SSH2? And the same cyphers?

Stroller.

[gentoo-user] SSH rekeying straight after authentication

[Mick]

I am trying to understand why an ssh server keeps dropping the connection when 
using openssh on Linux straight after a successful authentication, but it 
works fine with Filezilla in MSWindows.

The connection initially appears to succeed like so:

debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug3: send packet: type 50
debug3: receive packet: type 51
debug1: Authentications that can continue: password
debug3: start over, passed a different list password
debug3: preferred publickey,keyboard-interactive,password
debug3: authmethod_lookup password
debug3: remaining preferred: ,keyboard-interactive,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password
user_name@server_name.com's password: 
debug3: send packet: type 50
debug2: we sent a password packet, wait for reply
debug3: receive packet: type 52
debug1: Single to Multithread CTR cipher swap - client request
debug1: Authentication succeeded (password).
Authenticated to server_name.com ([123.456.78.9]:22).


Then it starts renegotiating keys and it eventually fails:

debug1: Final hpn_buffer_size = 2097152
debug1: HPN Disabled: 0, HPN Buffer Size: 2097152
debug1: channel 0: new [client-session]
debug1: Enabled Dynamic Window Scaling
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug3: ssh_packet_send2: rekex triggered
debug1: enqueue packet: 90
debug3: send packet: type 20
debug1: SSH2_MSG_KEXINIT sent
debug1: Entering interactive session.
debug1: pledge: network
debug1: rekeying in progress
debug1: rekeying in progress
debug3: receive packet: type 20
debug1: SSH2_MSG_KEXINIT received
debug1: AUTH STATE IS 1
debug2: local client KEXINIT proposal
debug2: KEX algorithms: curve25519-sha...@libssh.org,diffie-hellman-group-
exchange-sha256,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1
debug2: host key algorithms: ssh-rsa-cert-...@openssh.com,rsa-sha2-512,rsa-
sha2-256,ssh-rsa,ecdsa-sha2-nistp256-cert-...@openssh.com,ecdsa-sha2-nistp384-
cert-...@openssh.com,ecdsa-sha2-nistp521-cert-...@openssh.com,ssh-ed25519-
cert-...@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-
nistp521,ssh-ed25519
debug2: ciphers ctos: chacha20-poly1...@openssh.com,aes256-
g...@openssh.com,aes128-...@openssh.com,aes256-ctr,aes128-ctr,3des-cbc
debug2: ciphers stoc: chacha20-poly1...@openssh.com,aes256-
g...@openssh.com,aes128-...@openssh.com,aes256-ctr,aes128-ctr,3des-cbc
debug2: MACs ctos: hmac-sha2-512-...@openssh.com,hmac-sha2-256-
e...@openssh.com,umac-128-...@openssh.com,hmac-sha2-512,hmac-sha2-256,hmac-
ripemd160,hmac-sha1
debug2: MACs stoc: hmac-sha2-512-...@openssh.com,hmac-sha2-256-
e...@openssh.com,umac-128-...@openssh.com,hmac-sha2-512,hmac-sha2-256,hmac-
ripemd160,hmac-sha1
debug2: compression ctos: none,z...@openssh.com,zlib
debug2: compression stoc: none,z...@openssh.com,zlib
debug2: languages ctos: 
debug2: languages stoc: 
debug2: first_kex_follows 0 
debug2: reserved 0 
debug2: peer server KEXINIT proposal
debug2: KEX algorithms: 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,rsa1024-sha1
debug2: host key algorithms: ssh-rsa
debug2: ciphers ctos: aes256-ctr,aes192-ctr,aes128-ctr,aes256-cbc,aes192-
cbc,aes128-cbc,blowfish-ctr,blowfish-cbc,cast128-
cbc,arcfour256,arcfour128,3des-ctr,3des-cbc
debug2: ciphers stoc: aes256-ctr,aes192-ctr,aes128-ctr,aes256-cbc,aes192-
cbc,aes128-cbc,blowfish-ctr,blowfish-cbc,cast128-
cbc,arcfour256,arcfour128,3des-ctr,3des-cbc
debug2: MACs ctos: hmac-sha2-256,hmac-sha2-512,hmac-sha1,hmac-sha1-96,hmac-
md5,hmac-md5-96,hmac-ripemd160,umac...@openssh.com
debug2: MACs stoc: hmac-sha2-256,hmac-sha2-512,hmac-sha1,hmac-sha1-96,hmac-
md5,hmac-md5-96,hmac-ripemd160,umac...@openssh.com
debug2: compression ctos: z...@openssh.com,zlib,none
debug2: compression stoc: z...@openssh.com,zlib,none
debug2: languages ctos: 
debug2: languages stoc: 
debug2: first_kex_follows 0 
debug2: reserved 0 
debug1: kex: algorithm: diffie-hellman-group-exchange-sha256
debug1: kex: host key algorithm: ssh-rsa
debug1: REQUESTED ENC.NAME is 'aes256-ctr'
debug1: kex: server->client cipher: aes256-ctr MAC: hmac-sha2-512 compression: 
none
debug1: REQUESTED ENC.NAME is 'aes256-ctr'
debug1: kex: client->server cipher: aes256-ctr MAC: hmac-sha2-512 compression: 
none
debug3: send packet: type 34
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(2048<8192<8192) sent
debug1: rekeying in progress
debug1: rekeying in progress
debug3: receive packet: type 31
debug1: got SSH2_MSG_KEX_DH_GEX_GROUP
debug2: bits set: 4105/8192
debug3: send packet: type 32
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: rekeying in progress
debug1: rekeying in progress
debug3: receive packet: type 33
debug1: got SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Server host key: ssh-rsa 
SHA256:x0KsPBfGU/sP6+Yx1NhCoEDzF5w/IQ/6vxjuVEfPso
debug2: verify_host_key: server host key