# ssh/sftp bad packet length

## grooveman

Hi. 

I have a very strange problem.  We cannot sftp into our web host using the standard (open) sftp client.  The weird thing is, that psftp on windows (part of the putty suite), works fine.  But, of course, I do most of my heavy-lifting on Linux, and it is a real pain going back and forth.

This is what I'm getting:

```
sftp -vvv -P 22 11.22.33.44

OpenSSH_7.1p2-hpn14v10, OpenSSL 1.0.2e 3 Dec 2015

debug1: Reading configuration data /etc/ssh/ssh_config

debug2: ssh_connect: needpriv 0

debug1: Connecting to 11.22.33.44 [11.22.33.44] port 22.

debug1: Connection established.

debug1: key_load_public: No such file or directory

debug1: identity file /home/joey/.ssh/id_rsa type -1

debug1: key_load_public: No such file or directory

debug1: identity file /home/joey/.ssh/id_rsa-cert type -1

debug1: key_load_public: No such file or directory

debug1: identity file /home/joey/.ssh/id_dsa type -1

debug1: key_load_public: No such file or directory

debug1: identity file /home/joey/.ssh/id_dsa-cert type -1

debug1: key_load_public: No such file or directory

debug1: identity file /home/joey/.ssh/id_ed25519 type -1

debug1: key_load_public: No such file or directory

debug1: identity file /home/joey/.ssh/id_ed25519-cert type -1

debug1: Enabling compatibility mode for protocol 2.0

debug1: Local version string SSH-2.0-OpenSSH_7.1p2-hpn14v10

debug1: Remote protocol version 2.0, remote software version mod_sftp/0.9.9

debug1: no match: mod_sftp/0.9.9

debug2: fd 3 setting O_NONBLOCK

debug1: Authenticating to 11.22.33.44:22 as 'joey'

debug3: put_host_port: [11.22.33.44]:22

debug3: hostkeys_foreach: reading file "/home/joey/.ssh/known_hosts"

debug3: record_hostkey: found key type RSA in file /home/joey/.ssh/known_hosts:15

debug3: load_hostkeys: loaded 1 keys from [11.22.33.44]:22

debug3: order_hostkeyalgs: prefer hostkeyalgs: ssh-rsa-cert-v01@openssh.com,ssh-rsa

debug1: SSH2_MSG_KEXINIT sent

debug1: SSH2_MSG_KEXINIT received

debug1: AUTH STATE IS 0

debug2: kex_parse_kexinit: curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1

debug2: kex_parse_kexinit: ssh-rsa-cert-v01@openssh.com,ssh-rsa,ssh-ed25519-cert-v01@openssh.com,ssh-ed25519

debug2: kex_parse_kexinit: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se

debug2: kex_parse_kexinit: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se

debug2: kex_parse_kexinit: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1,hmac-md5-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96

debug2: kex_parse_kexinit: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1,hmac-md5-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96

debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib

debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib

debug2: kex_parse_kexinit: 

debug2: kex_parse_kexinit: 

debug2: first_kex_follows 0 

debug2: reserved 0 

debug2: kex_parse_kexinit: 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: kex_parse_kexinit: ssh-rsa,ssh-dss

debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr

debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr

debug2: kex_parse_kexinit: hmac-sha1,hmac-sha2-256,hmac-sha2-512

debug2: kex_parse_kexinit: hmac-sha1,hmac-sha2-256,hmac-sha2-512

debug2: kex_parse_kexinit: zlib@openssh.com,zlib,none

debug2: kex_parse_kexinit: zlib@openssh.com,zlib,none

debug2: kex_parse_kexinit: 

debug2: kex_parse_kexinit: 

debug2: first_kex_follows 0 

debug2: reserved 0 

debug1: REQUESTED ENC.NAME is 'aes128-ctr'

debug1: kex: server->client aes128-ctr hmac-sha2-256 none

debug1: REQUESTED ENC.NAME is 'aes128-ctr'

debug1: kex: client->server aes128-ctr hmac-sha2-256 none

debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<8192<8192) sent

debug1: got SSH2_MSG_KEX_DH_GEX_GROUP

debug2: bits set: 4119/8192

debug1: SSH2_MSG_KEX_DH_GEX_INIT sent

debug1: got SSH2_MSG_KEX_DH_GEX_REPLY

debug1: Server host key: ssh-rsa SHA256:eJMBlJHD4J93jFib1edUiceY7750q+CeXcFWYMdPCaY

debug3: put_host_port: [11.22.33.44]:22

debug3: put_host_port: [11.22.33.44]:22

debug3: hostkeys_foreach: reading file "/home/joey/.ssh/known_hosts"

debug3: record_hostkey: found key type RSA in file /home/joey/.ssh/known_hosts:15

debug3: load_hostkeys: loaded 1 keys from [11.22.33.44]:22

debug3: hostkeys_foreach: reading file "/home/joey/.ssh/known_hosts"

debug3: record_hostkey: found key type RSA in file /home/joey/.ssh/known_hosts:15

debug3: load_hostkeys: loaded 1 keys from [11.22.33.44]:22

debug1: Host '[11.22.33.44]:22' is known and matches the RSA host key.

debug1: Found key in /home/joey/.ssh/known_hosts:15

debug2: bits set: 4114/8192

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: SSH2_MSG_SERVICE_REQUEST sent

Bad packet length 1674287662.

ssh_packet_read: message authentication code incorrect

Couldn't read packet: Connection reset by peer
```

Any ideas?

Thanks!

G

----------

## grooveman

Really?  No insight on this?  Is that because it is a stupid question, or because it is a very obscure one?

----------

## ian.au

Looks like you need to regenerate your ssh-keys per http://www.openssh.com/legacy.html or the below news item offers a workaround:

 *Quote:*   

> 2015-08-13-openssh-weak-keys
> 
>   Title                     OpenSSH 7.0 disables ssh-dss keys by default
> 
>   Author                    Mike Frysinger <vapier@gentoo.org>
> ...

 

----------

## grooveman

Thank you for that.

Since we don't own the server, we are kind of stuck with whatever it is they use.  Hopefully we will be able to change services relatively soon here.

I appreciate the insight.

-G

----------

## grooveman

Hmm... no dice.  Same error.  Perhaps this is something different.

I added:

```
PubkeyAcceptedKeyTypes=+ssh-dss
```

to /home/joey/.ssh/config

And I tried putting it in /etc/ssh/ssh_config as well.  Not working eitther way...

----------

## ian.au

Did you re-generate some key-pairs? It's not clear from your post that you did, my understanding is that you would have had to regen the keys after making the changes to your config files, so it won't be working if you missed that step. From: https://wiki.gentoo.org/wiki/SSH

 *Quote:*   

> 
> 
> Create keys
> 
> In order to provide a secure shell, cryptographic keys are used to manage the encryption, decryption, and hashing functionalities offered by SSH.
> ...

 

```

root #/usr/bin/ssh-keygen -t rsa1 -b 1024 -f /etc/ssh/ssh_host_key -N ""
```

 *Quote:*   

> To generate the keys for SSH protocol version 2 (DSA and RSA algorithms):
> 
> 

  

```

root #/usr/bin/ssh-keygen -t dsa -f /etc/ssh/ssh_host_dsa_key -N ""

root #/usr/bin/ssh-keygen -t rsa -f /etc/ssh/ssh_host_rsa_key -N ""
```

I don't know if the workaround remains valid (I didn't try it), since the news on this dates to last August and clearly flags that support will be ultimately dropped for the weaker keys it's not probably a solution to go that way.

Anyway you're banging on the ceiling of my expertise in this area, but hopefully pointed you in the right direction, along with the wiki and man-page and there is some really concise information on the dev-list https://dev.gentoo.org/~swift/docs/security_benchmarks/openssh.html which I'd say is recommended reading if deploying ssh on web-facing services.

----------

## grooveman

No I didn't, but that is all server-side.  I have no control over the server.  I'm just trying to get my ssh client to interface with the server.

----------

## ian.au

Sorry I'm used to having complete access on the server side for this. 

I think your solution is still to generate a keypair on your machine and upload the public key to your server. I know you can use the format 

```
ssh-copy-id <user>@xxx.xxx.xxx.xxx
```

 to upload the key - although I have not used this method that I remember. I've only ever pasted the keys with ssh - but that's probably not an option if ssh isn't working.

----------

## grooveman

Hmm... I don't think this is going to work either.  I don't even get dumped into the user's homedir... just under the web root.  I have nowhere to put the keys...

----------

