Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
[SOLVED] General SSH fail(ure)!!
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Networking & Security
View previous topic :: View next topic  
Author Message
BobWya
Apprentice
Apprentice


Joined: 12 Aug 2012
Posts: 228
Location: Cambridge,UK

PostPosted: Sun Dec 29, 2013 10:35 pm    Post subject: [SOLVED] General SSH fail(ure)!! Reply with quote

Hi folks,

Just wondering if I could get a little help with my ssh setup on my laptop... I'm using the KDE DE with the following packages...
Code:
[ebuild   R    ] sys-libs/zlib-1.2.8-r1  USE="minizip -static-libs" ABI_X86="32 (64) (-x32)" 558 kB
[ebuild   R   ~] dev-libs/openssl-1.0.1e-r3  USE="gmp (sse2) tls-heartbeat zlib -bindist -kerberos -rfc3779 -static-libs {-test} -vanilla" 0 kB
[ebuild   R   ~] sys-libs/pam-1.1.8  USE="berkdb cracklib nls -audit -debug -nis (-selinux) {-test} -vim-syntax" 0 kB
[ebuild   R   ~] net-misc/openssh-6.4_p1-r1  USE="X hpn ldap pam tcpd -X509 -bindist -kerberos -ldns -libedit (-selinux) -skey -static" 0 kB


My ssh config was working fine - till a recent world update... I'm still using the same gcc version (4.7.3) and make options. I'm still tracking down a few other problems (like XBMC git and ntfs-3g not building - nothing that would affect my ssh capability).

I can post up my ssh and sshd config files - but I haven't changed these (since the update) and I've compared them with an Arch install (multi-booted on the same laptop) to double check (that I'm not losing my sanity)!!

Currently I can't ssh, either into or out of, the Gentoo install on my laptop.
Code:
> ssh -vvv localhost
OpenSSH_6.4, OpenSSL 1.0.1e 11 Feb 2013
debug1: Reading configuration data /etc/ssh/ssh_config
debug2: ssh_connect: needpriv 0
debug1: Connecting to localhost [::1] port 22.
debug1: Connection established.
debug3: Incorrect RSA1 identifier
debug3: Could not load "/home/robert/.ssh/id_rsa" as a RSA1 public key
debug1: identity file /home/robert/.ssh/id_rsa type 1
debug1: identity file /home/robert/.ssh/id_rsa-cert type -1
debug1: identity file /home/robert/.ssh/id_dsa type -1
debug1: identity file /home/robert/.ssh/id_dsa-cert type -1
debug1: identity file /home/robert/.ssh/id_ecdsa type -1
debug1: identity file /home/robert/.ssh/id_ecdsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.4p1-hpn14v2
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.4p1-hpn14v2
debug1: match: OpenSSH_6.4p1-hpn14v2 pat OpenSSH*
debug2: fd 3 setting O_NONBLOCK
debug3: load_hostkeys: loading entries for host "localhost" from file "/home/robert/.ssh/known_hosts"
debug3: load_hostkeys: loaded 0 keys
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: AUTH STATE IS 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
debug2: kex_parse_kexinit: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ssh-dss-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-dss-cert-v00@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: hmac-md5-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-sha1,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-sha1,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,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: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: 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
debug2: kex_parse_kexinit: ssh-rsa
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: hmac-md5-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-sha1,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-sha1,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: mac_setup: found hmac-md5-etm@openssh.com
debug1: REQUESTED ENC.NAME is 'aes128-ctr'
debug1: kex: server->client aes128-ctr hmac-md5-etm@openssh.com none
debug2: mac_setup: found hmac-md5-etm@openssh.com
debug1: REQUESTED ENC.NAME is 'aes128-ctr'
debug1: kex: client->server aes128-ctr hmac-md5-etm@openssh.com none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
Connection closed by ::1


Anyone got any thoughts?? Don't usually like to ask for help - but this one has me stumped!! Not sure if it's a bug or package incompatibility... I did turn off the kerberos USE flag (as my laptop is just on a standard CIFS/workgroup home network).

Thanks for any guidance!!
Robert


Last edited by BobWya on Mon Dec 30, 2013 7:49 pm; edited 1 time in total
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 43546
Location: 56N 3W

PostPosted: Sun Dec 29, 2013 11:34 pm    Post subject: Reply with quote

BobWya,

Code:
ssh -vvv localhost
OpenSSH_6.4, OpenSSL 1.0.1e 11 Feb 2013
debug1: Reading configuration data /etc/ssh/ssh_config
debug2: ssh_connect: needpriv 0
debug1: Connecting to localhost [::1] port 22.

Why does it prefer IPv6 ?

Code:
ssh -4 -vvv localhost
should make it use IPv4, or I've remembered the -4 incorrectly.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
Sodki
Guru
Guru


Joined: 11 Aug 2003
Posts: 419
Location: London, U.K. & Lisbon, Portugal

PostPosted: Mon Dec 30, 2013 2:07 pm    Post subject: Reply with quote

I had a similar problem when I last updated OpenSSH to version 6.4, being unable to connect:

Code:
$ ssh localhost
Password:
Bad packet length 3050708630.
Disconnecting: Packet corrupt


I've traced the problem to the AES algorithms with CTR. Example:

Code:
$ grep Ciphers /etc/ssh/ssh_config
#   Ciphers aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc


This are is the default algorithms used by OpenSSH. I've tested all those ciphers individually by setting the "Ciphers" option manually and these were my conclusions:

  • aes*-ctr ciphers always fail
  • all other ciphers work

In the end, I found out I had no support for CTR on the kernel (CONFIG_CRYPTO_CTR), thus the failure.

Edit: this analysis was wrong, see below.


Last edited by Sodki on Sun Jan 05, 2014 8:22 am; edited 1 time in total
Back to top
View user's profile Send private message
BobWya
Apprentice
Apprentice


Joined: 12 Aug 2012
Posts: 228
Location: Cambridge,UK

PostPosted: Mon Dec 30, 2013 7:49 pm    Post subject: Reply with quote

Both problems solved...
I needed to revert to: dev-libs/openssl stable amd64
boom!! ssh working as soon as I logged back in... It's not the latest build =net-misc/openssh-6.4_p1-r1 causing the issues (I had that on my Arch installs without complaints - so went to the Cryptographic stuff first)...

OT (but since I mentioned it above) I also found...
I needed to revert to: dev-libs/libgcrypt stable amd64, in order to fix the ntfs-3g building issues (brilliant the dev's have completely changed the API's for libgcrypt - which breaks ntfs-3g - hey no biggie... :roll: )

Thanks for the advice anyway and hope this info can help the other chil'rens...
Bob 8)
Back to top
View user's profile Send private message
Sodki
Guru
Guru


Joined: 11 Aug 2003
Posts: 419
Location: London, U.K. & Lisbon, Portugal

PostPosted: Sun Jan 05, 2014 8:20 am    Post subject: Reply with quote

Sodki wrote:
I had a similar problem when I last updated OpenSSH to version 6.4, being unable to connect:

Code:
$ ssh localhost
Password:
Bad packet length 3050708630.
Disconnecting: Packet corrupt


I've traced the problem to the AES algorithms with CTR. Example:

Code:
$ grep Ciphers /etc/ssh/ssh_config
#   Ciphers aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc


This are is the default algorithms used by OpenSSH. I've tested all those ciphers individually by setting the "Ciphers" option manually and these were my conclusions:

  • aes*-ctr ciphers always fail
  • all other ciphers work

In the end, I found out I had no support for CTR on the kernel (CONFIG_CRYPTO_CTR), thus the failure.


Actually I was completely wrong. My issue was solved by disabling the "hpn" use flag for openssh.
Back to top
View user's profile Send private message
BobWya
Apprentice
Apprentice


Joined: 12 Aug 2012
Posts: 228
Location: Cambridge,UK

PostPosted: Sun Jan 05, 2014 10:25 am    Post subject: Reply with quote

Sodki wrote:

Actually I was completely wrong. My issue was solved by disabling the "hpn" use flag for openssh.


Does that work with the ~amd64 build of openssl (since openssh uses the openssl API, apparently, and does not perform the cryptography directly)?
Don't we want high performance ssh though??!! :wink:

I usually just compile every single cryptographic function I can find into every new kernel I build 8)

Thanks
Bob
Back to top
View user's profile Send private message
Navar
Guru
Guru


Joined: 20 Aug 2012
Posts: 353

PostPosted: Sun Jan 05, 2014 1:12 pm    Post subject: Reply with quote

My understanding of the crypto API in kernel level would be for things like IPSec, leveraging specialized hardware drivers and devices with kernel support for specialized performance (which you probably do not have), kernel file systems and block device level encryption. If you don't utilize any of that you probably don't need to build it in.

While openssl/ssh is cross platform and doesn't need the kernel API, I would presume userspace library algorithms should perform as well as those provided in kernel, excluding special circumstances like mentioned above. With symmetric ciphers, e.g., an XOR operation should be the same whether in kernel space or userland library routines for performance.

I'm all for speed, but in this case I don't think it'd matter. ;)
_________________
Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Networking & Security All times are GMT
Page 1 of 1

 
Jump to:  
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