# [SOLVED] General SSH fail(ure)!!

## BobWya

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...

```
[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.

```
> 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!!

RobertLast edited by BobWya on Mon Dec 30, 2013 7:49 pm; edited 1 time in total

----------

## NeddySeagoon

BobWya,

```
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 ?

```
ssh -4 -vvv localhost
```

should make it use IPv4, or I've remembered the -4 incorrectly.

----------

## Sodki

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

```
$ ssh localhost

Password: 

Bad packet length 3050708630.

Disconnecting: Packet corrupt

```

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

```
$ 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

----------

## BobWya

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...   :Rolling Eyes:   )

Thanks for the advice anyway and hope this info can help the other chil'rens...  

Bob  :Cool: 

----------

## Sodki

 *Sodki wrote:*   

> I had a similar problem when I last updated OpenSSH to version 6.4, being unable to connect:
> 
> ```
> $ ssh localhost
> 
> ...

 

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

----------

## BobWya

 *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   :Cool: 

Thanks

Bob

----------

## Navar

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.  :Wink: 

----------

