| 1 |
I am trying to understand why an ssh server keeps dropping the connection when |
| 2 |
using openssh on Linux straight after a successful authentication, but it |
| 3 |
works fine with Filezilla in MSWindows. |
| 4 |
|
| 5 |
The connection initially appears to succeed like so: |
| 6 |
|
| 7 |
debug2: service_accept: ssh-userauth |
| 8 |
debug1: SSH2_MSG_SERVICE_ACCEPT received |
| 9 |
debug3: send packet: type 50 |
| 10 |
debug3: receive packet: type 51 |
| 11 |
debug1: Authentications that can continue: password |
| 12 |
debug3: start over, passed a different list password |
| 13 |
debug3: preferred publickey,keyboard-interactive,password |
| 14 |
debug3: authmethod_lookup password |
| 15 |
debug3: remaining preferred: ,keyboard-interactive,password |
| 16 |
debug3: authmethod_is_enabled password |
| 17 |
debug1: Next authentication method: password |
| 18 |
user_name@server_name.com's password: |
| 19 |
debug3: send packet: type 50 |
| 20 |
debug2: we sent a password packet, wait for reply |
| 21 |
debug3: receive packet: type 52 |
| 22 |
debug1: Single to Multithread CTR cipher swap - client request |
| 23 |
debug1: Authentication succeeded (password). |
| 24 |
Authenticated to server_name.com ([123.456.78.9]:22). |
| 25 |
|
| 26 |
|
| 27 |
Then it starts renegotiating keys and it eventually fails: |
| 28 |
|
| 29 |
debug1: Final hpn_buffer_size = 2097152 |
| 30 |
debug1: HPN Disabled: 0, HPN Buffer Size: 2097152 |
| 31 |
debug1: channel 0: new [client-session] |
| 32 |
debug1: Enabled Dynamic Window Scaling |
| 33 |
debug3: ssh_session2_open: channel_new: 0 |
| 34 |
debug2: channel 0: send open |
| 35 |
debug3: ssh_packet_send2: rekex triggered |
| 36 |
debug1: enqueue packet: 90 |
| 37 |
debug3: send packet: type 20 |
| 38 |
debug1: SSH2_MSG_KEXINIT sent |
| 39 |
debug1: Entering interactive session. |
| 40 |
debug1: pledge: network |
| 41 |
debug1: rekeying in progress |
| 42 |
debug1: rekeying in progress |
| 43 |
debug3: receive packet: type 20 |
| 44 |
debug1: SSH2_MSG_KEXINIT received |
| 45 |
debug1: AUTH STATE IS 1 |
| 46 |
debug2: local client KEXINIT proposal |
| 47 |
debug2: KEX algorithms: curve25519-sha256@××××××.org,diffie-hellman-group- |
| 48 |
exchange-sha256,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1 |
| 49 |
debug2: host key algorithms: ssh-rsa-cert-v01@×××××××.com,rsa-sha2-512,rsa- |
| 50 |
sha2-256,ssh-rsa,ecdsa-sha2-nistp256-cert-v01@×××××××.com,ecdsa-sha2-nistp384- |
| 51 |
cert-v01@×××××××.com,ecdsa-sha2-nistp521-cert-v01@×××××××.com,ssh-ed25519- |
| 52 |
cert-v01@×××××××.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2- |
| 53 |
nistp521,ssh-ed25519 |
| 54 |
debug2: ciphers ctos: chacha20-poly1305@×××××××.com,aes256- |
| 55 |
gcm@×××××××.com,aes128-gcm@×××××××.com,aes256-ctr,aes128-ctr,3des-cbc |
| 56 |
debug2: ciphers stoc: chacha20-poly1305@×××××××.com,aes256- |
| 57 |
gcm@×××××××.com,aes128-gcm@×××××××.com,aes256-ctr,aes128-ctr,3des-cbc |
| 58 |
debug2: MACs ctos: hmac-sha2-512-etm@×××××××.com,hmac-sha2-256- |
| 59 |
etm@×××××××.com,umac-128-etm@×××××××.com,hmac-sha2-512,hmac-sha2-256,hmac- |
| 60 |
ripemd160,hmac-sha1 |
| 61 |
debug2: MACs stoc: hmac-sha2-512-etm@×××××××.com,hmac-sha2-256- |
| 62 |
etm@×××××××.com,umac-128-etm@×××××××.com,hmac-sha2-512,hmac-sha2-256,hmac- |
| 63 |
ripemd160,hmac-sha1 |
| 64 |
debug2: compression ctos: none,zlib@×××××××.com,zlib |
| 65 |
debug2: compression stoc: none,zlib@×××××××.com,zlib |
| 66 |
debug2: languages ctos: |
| 67 |
debug2: languages stoc: |
| 68 |
debug2: first_kex_follows 0 |
| 69 |
debug2: reserved 0 |
| 70 |
debug2: peer server KEXINIT proposal |
| 71 |
debug2: KEX algorithms: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2- |
| 72 |
nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange- |
| 73 |
sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1,rsa1024-sha1 |
| 74 |
debug2: host key algorithms: ssh-rsa |
| 75 |
debug2: ciphers ctos: aes256-ctr,aes192-ctr,aes128-ctr,aes256-cbc,aes192- |
| 76 |
cbc,aes128-cbc,blowfish-ctr,blowfish-cbc,cast128- |
| 77 |
cbc,arcfour256,arcfour128,3des-ctr,3des-cbc |
| 78 |
debug2: ciphers stoc: aes256-ctr,aes192-ctr,aes128-ctr,aes256-cbc,aes192- |
| 79 |
cbc,aes128-cbc,blowfish-ctr,blowfish-cbc,cast128- |
| 80 |
cbc,arcfour256,arcfour128,3des-ctr,3des-cbc |
| 81 |
debug2: MACs ctos: hmac-sha2-256,hmac-sha2-512,hmac-sha1,hmac-sha1-96,hmac- |
| 82 |
md5,hmac-md5-96,hmac-ripemd160,umac-64@×××××××.com |
| 83 |
debug2: MACs stoc: hmac-sha2-256,hmac-sha2-512,hmac-sha1,hmac-sha1-96,hmac- |
| 84 |
md5,hmac-md5-96,hmac-ripemd160,umac-64@×××××××.com |
| 85 |
debug2: compression ctos: zlib@×××××××.com,zlib,none |
| 86 |
debug2: compression stoc: zlib@×××××××.com,zlib,none |
| 87 |
debug2: languages ctos: |
| 88 |
debug2: languages stoc: |
| 89 |
debug2: first_kex_follows 0 |
| 90 |
debug2: reserved 0 |
| 91 |
debug1: kex: algorithm: diffie-hellman-group-exchange-sha256 |
| 92 |
debug1: kex: host key algorithm: ssh-rsa |
| 93 |
debug1: REQUESTED ENC.NAME is 'aes256-ctr' |
| 94 |
debug1: kex: server->client cipher: aes256-ctr MAC: hmac-sha2-512 compression: |
| 95 |
none |
| 96 |
debug1: REQUESTED ENC.NAME is 'aes256-ctr' |
| 97 |
debug1: kex: client->server cipher: aes256-ctr MAC: hmac-sha2-512 compression: |
| 98 |
none |
| 99 |
debug3: send packet: type 34 |
| 100 |
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(2048<8192<8192) sent |
| 101 |
debug1: rekeying in progress |
| 102 |
debug1: rekeying in progress |
| 103 |
debug3: receive packet: type 31 |
| 104 |
debug1: got SSH2_MSG_KEX_DH_GEX_GROUP |
| 105 |
debug2: bits set: 4105/8192 |
| 106 |
debug3: send packet: type 32 |
| 107 |
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent |
| 108 |
debug1: rekeying in progress |
| 109 |
debug1: rekeying in progress |
| 110 |
debug3: receive packet: type 33 |
| 111 |
debug1: got SSH2_MSG_KEX_DH_GEX_REPLY |
| 112 |
debug1: Server host key: ssh-rsa |
| 113 |
SHA256:x0KsPBfGU/sP6+Yx1NhCoEDzF5w/IQ/6vxjuVEfPso |
| 114 |
debug2: verify_host_key: server host key RSA |
| 115 |
SHA256:x0KsPYqfxsUsP6+Yx1wKoNvRzF5w/IQ/6vxjuVEfPso matches cached key |
| 116 |
debug2: bits set: 4100/8192 |
| 117 |
debug3: send packet: type 21 |
| 118 |
debug2: set_newkeys: mode 1 |
| 119 |
debug1: set_newkeys: rekeying, input 8080 bytes 255 blocks, output 4472 bytes |
| 120 |
0 blocks |
| 121 |
debug1: spawned a thread |
| 122 |
debug1: spawned a thread |
| 123 |
debug1: rekey after 67108864 blocks |
| 124 |
debug1: dequeue packet: 90 |
| 125 |
debug3: send packet: type 90 |
| 126 |
debug1: SSH2_MSG_NEWKEYS sent |
| 127 |
debug1: expecting SSH2_MSG_NEWKEYS |
| 128 |
debug1: rekeying in progress |
| 129 |
debug3: receive packet: type 21 |
| 130 |
debug1: SSH2_MSG_NEWKEYS received |
| 131 |
debug2: set_newkeys: mode 0 |
| 132 |
debug1: set_newkeys: rekeying, input 8096 bytes 0 blocks, output 4520 bytes 3 |
| 133 |
blocks |
| 134 |
debug1: spawned a thread |
| 135 |
debug1: spawned a thread |
| 136 |
debug1: rekey after 67108864 blocks |
| 137 |
debug3: send packet: type 1 |
| 138 |
packet_write_wait: Connection to 123.456.78.9 port 22: Broken pipe |
| 139 |
|
| 140 |
|
| 141 |
I am guessing all this respawning probably triggers some DDoS protection limit |
| 142 |
on the server and it disconnects the client. Have you observed anything |
| 143 |
similar and would you know why Linux fails, but MSWindows works as it should? |
| 144 |
|
| 145 |
PS. Setting 'RekeyLimit 15G' in ~/.ssh/config as a large enough value to avoid |
| 146 |
rekeying does not seem to work. |
| 147 |
-- |
| 148 |
Regards, |
| 149 |
Mick |
Archives