[SOLVED] openssh-6.7p1-x86_64-2_slack14.1 problems

Jeronimo Barros · 12-17-2014, 07:46 AM

Guys,

I've just applied the last openssh patch (openssh-6.7p1-x86_64-2_slack14.1 - previous package: openssh-6.6p1-x86_64-3_slack14.1) and now I can't ssh to other servers.

I'm getting a weird error:

Code:

OpenSSH_6.7p1, OpenSSL 1.0.1j 15 Oct 2014
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Connecting to test2 [192.168.0.126] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: identity file /root/.ssh/id_rsa type 1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.7
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6.1
debug1: match: OpenSSH_6.6.1 pat OpenSSH_6.6.1* compat 0x04000000
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr umac-64-etm@openssh.com zlib@openssh.com
debug1: kex: client->server aes128-ctr umac-64-etm@openssh.com zlib@openssh.com
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY

Is anyone having the same problem ? I didn't find much help at google...

Thanks in advance for any help.

Best regards, Jero

Labinnah · 12-17-2014, 08:18 AM

I don't see any critical errors here. These are only some local nonexistent cert errors. RSA one exists, and this should be enough. If you paste whole debug output, then you didn't get "Server host key" from server. You should get next line like this:

Code:

debug1: Server host key: ECDSA a4:47:54:ae:20:ff:...

So I suspect some networking problem.

Jeronimo Barros · 12-17-2014, 10:57 AM

Quote:

Originally Posted by Labinnah

So I suspect some networking problem.

As I said, it's a weird problem, not a networking problem. Everything was OK before the update was applied. sshd for example is working fine and I can access the server via the network (what I'm doing right now), only ssh is not working anymore.

I tried to ssh others servers (that was OK before the patch) with and without the .ssh directory populated. Another test I did before was to diff the ssh_config file with another one from other server with the openssh-6.6p1-x86_64-3_slack14.1 installed and there is no difference.

So, any hint ?

Jero

mancha · 12-17-2014, 03:22 PM

That's strange. I'm wondering if this might be network-related - maybe packet lengths.

Can you provide the output of two things:

Code:

# ip link

And also run the following while ssh'ing out and provide the output (change to the appropriate iface if not eth0):

Code:

# tcpdump -i eth0 port 22

--mancha

P.S. If you don't want to share source and/or destination addresses, you can scrub them from the tcpdump output with sed or something
before posting (use a.b.c.d for source and w.x.y.z for dest or so).

Labinnah · 12-17-2014, 03:34 PM

Quote:

Originally Posted by Jeronimo Barros

sshd for example is working fine and I can access the server via the network (what I'm doing right now), only ssh is not working anymore.

I mean more obscure errors, like wrong firewall rules, not general network problem. You can try ssh localhost - you probably haven't any not standard configuration there.

You can also "strace" ssh session to see where ssh process sleep or enter endless loop.

Jeronimo Barros · 12-17-2014, 04:24 PM

Quote:

Originally Posted by mancha

That's strange. I'm wondering if this might be network-related - maybe packet lengths.

Mancha, you and Labinnah are right about the packet length and network problem.

The server was installed from an image of an production server and that server was on a 9000 bytes MTU network, but this new server is being installed and configured on an 1500 bytes MTU network. I changed the MTU and now the applications that use the ssh are working.

Curiously, until the update everything was working fine. Because of it I didn't check all the network configurations.

Thank you all again, without these hints probably I would spent the night trying to figure out the problem.

Best regards, Jero