| View previous topic :: View next topic |
| Author |
Message |
grooveman
Veteran
Joined: 24 Feb 2003
Posts: 1217
|
 Posted: Tue Jan 26, 2016 2:36 pm Post subject: ssh/sftp bad packet length |
 |
|
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:
| Code: | 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
_________________
To look without without looking within is like looking without without looking at all. |
|
| Back to top |
|
 |
grooveman
Veteran
Joined: 24 Feb 2003
Posts: 1217
|
| Posted: Fri Jan 29, 2016 1:25 pm Post subject: |
|
|
Really? No insight on this? Is that because it is a stupid question, or because it is a very obscure one?
_________________
To look without without looking within is like looking without without looking at all. |
|
| Back to top |
|
|
ian.au
Guru
Joined: 07 Apr 2011
Posts: 591
Location: Australia
|
| Posted: Fri Jan 29, 2016 11:33 pm Post subject: |
|
|
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>
Posted 2015-08-13
Revision 1
Starting with the 7.0 release of OpenSSH, support for ssh-dss keys has
been disabled by default at runtime due to their inherit weakness. If
you rely on these key types, you will have to take corrective action or
risk being locked out.
Your best option is to generate new keys using strong algos such as rsa
or ecdsa or ed25519. RSA keys will give you the greatest portability
with other clients/servers while ed25519 will get you the best security
with OpenSSH (but requires recent versions of client & server).
If you are stuck with DSA keys, you can re-enable support locally by
updating your sshd_config and ~/.ssh/config files with lines like so:
PubkeyAcceptedKeyTypes=+ssh-dss
Be aware though that eventually OpenSSH will drop support for DSA keys
entirely, so this is only a stop gap solution.
More details can be found on OpenSSH's website:
http://www.openssh.com/legacy.html |
|
|
| Back to top |
|
|
grooveman
Veteran
Joined: 24 Feb 2003
Posts: 1217
|
| Posted: Mon Feb 01, 2016 5:07 pm Post subject: |
|
|
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
_________________
To look without without looking within is like looking without without looking at all. |
|
| Back to top |
|
|
grooveman
Veteran
Joined: 24 Feb 2003
Posts: 1217
|
| Posted: Mon Feb 01, 2016 7:09 pm Post subject: |
|
|
Hmm... no dice. Same error. Perhaps this is something different.
I added:
| Code: | | PubkeyAcceptedKeyTypes=+ssh-dss |
to /home/joey/.ssh/config
And I tried putting it in /etc/ssh/ssh_config as well. Not working eitther way...
_________________
To look without without looking within is like looking without without looking at all. |
|
| Back to top |
|
|
ian.au
Guru
Joined: 07 Apr 2011
Posts: 591
Location: Australia
|
| Posted: Mon Feb 01, 2016 10:04 pm Post subject: |
|
|
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.
On the first start of the SSH service, system keys will be generated. Keys can be (re)generated using the ssh-keygen command.
To generate the key used for SSH protocol version 1 (which usually is not enabled anymore; it has been deprecated in favor of protocol version 2) use: |
| Code: |
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):
|
| Code: |
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. |
|
| Back to top |
|
|
grooveman
Veteran
Joined: 24 Feb 2003
Posts: 1217
|
| Posted: Mon Feb 01, 2016 10:07 pm Post subject: |
|
|
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.
_________________
To look without without looking within is like looking without without looking at all. |
|
| Back to top |
|
|
ian.au
Guru
Joined: 07 Apr 2011
Posts: 591
Location: Australia
|
| Posted: Mon Feb 01, 2016 10:46 pm Post subject: |
|
|
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 | Code: | | 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. |
|
| Back to top |
|
|
grooveman
Veteran
Joined: 24 Feb 2003
Posts: 1217
|
| Posted: Fri Feb 05, 2016 4:01 pm Post subject: |
|
|
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...
_________________
To look without without looking within is like looking without without looking at all. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Networking & Security
