Ssh Failure From CentOS7 To CentOS6

Home » CentOS » Ssh Failure From CentOS7 To CentOS6
CentOS 5 Comments

Hi,

I have a strange problem with a freshly installed CentOS7 desktop
(most8pc25). I can’t SSH to 2 CentOS6 servers, even with firewall disabled on the client and on the server. But I can connect from the server to the client, all in the same VLAN. I can also SSH from this desktop to CentOS7 servers in the same VLAN or in another VLAN.

No idea about this problem.

On the server kareline (client is most8pc25), tcpdump says:

tcpdump: listening on p5p1, link-type EN10MB (Ethernet), capture size
65535 bytes
18:17:25.844816 IP (tos 0x0, ttl 64, id 19021, offset 0, flags [DF], proto TCP (6), length 60)
    most8pc25.legi.grenoble-inp.fr.36414 >
kareline.legi.grenoble-inp.fr.ssh: Flags [S], cksum 0xfff1 (correct), seq 3060883003, win 26880, options [mss 8960,sackOK,TS val 2888822 ecr
0,nop,wscale 7], length 0
18:17:25.844927 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 52)
    kareline.legi.grenoble-inp.fr.ssh >
most8pc25.legi.grenoble-inp.fr.36414: Flags [S.], cksum 0xa1f5
(correct), seq 1624136656, ack 3060883004, win 17920, options [mss
8960,nop,nop,sackOK,nop,wscale 7], length 0
18:17:25.845014 IP (tos 0x0, ttl 64, id 19022, offset 0, flags [DF], proto TCP (6), length 40)
    most8pc25.legi.grenoble-inp.fr.36414 >
kareline.legi.grenoble-inp.fr.ssh: Flags [.], cksum 0x4542 (correct), ack 1, win 210, length 0
18:17:25.845406 IP (tos 0x0, ttl 64, id 19023, offset 0, flags [DF], proto TCP (6), length 61)
    most8pc25.legi.grenoble-inp.fr.36414 >
kareline.legi.grenoble-inp.fr.ssh: Flags [P.], cksum 0x817c (correct), seq 1:22, ack 1, win 210, length 21
18:17:25.845435 IP (tos 0x0, ttl 64, id 27577, offset 0, flags [DF], proto TCP (6), length 40)
    kareline.legi.grenoble-inp.fr.ssh >
most8pc25.legi.grenoble-inp.fr.36414: Flags [.], cksum 0x4573 (correct), ack 22, win 140, length 0
18:17:25.854750 IP (tos 0x0, ttl 64, id 27578, offset 0, flags [DF], proto TCP (6), length 61)
    kareline.legi.grenoble-inp.fr.ssh >
most8pc25.legi.grenoble-inp.fr.36414: Flags [P.], cksum 0x0a4e
(incorrect -> 0x84ad), seq 1:22, ack 22, win 140, length 21
18:17:25.854887 IP (tos 0x0, ttl 64, id 19024, offset 0, flags [DF], proto TCP (6), length 40)
    most8pc25.legi.grenoble-inp.fr.36414 >
kareline.legi.grenoble-inp.fr.ssh: Flags [.], cksum 0x4518 (correct), ack 22, win 210, length 0
18:17:25.856766 IP (tos 0x0, ttl 64, id 27579, offset 0, flags [DF], proto TCP (6), length 880)
    kareline.legi.grenoble-inp.fr.ssh >
most8pc25.legi.grenoble-inp.fr.36414: Flags [P.], cksum 0x0d81
(incorrect -> 0x8fa1), seq 22:862, ack 22, win 140, length 840
18:17:25.896278 IP (tos 0x0, ttl 64, id 19026, offset 0, flags [DF], proto TCP (6), length 40)
    most8pc25.legi.grenoble-inp.fr.36414 >
kareline.legi.grenoble-inp.fr.ssh: Flags [.], cksum 0x3bea (correct), ack 862, win 224, length 0
18:17:26.055314 IP (tos 0x0, ttl 64, id 19027, offset 0, flags [DF], proto TCP (6), length 64)
    most8pc25.legi.grenoble-inp.fr.36414 >
kareline.legi.grenoble-inp.fr.ssh: Flags [P.], cksum 0x0594 (correct), seq 1518:1542, ack 862, win 224, length 24
18:17:26.055348 IP (tos 0x0, ttl 64, id 27580, offset 0, flags [DF], proto TCP (6), length 52)
    kareline.legi.grenoble-inp.fr.ssh >
most8pc25.legi.grenoble-inp.fr.36414: Flags [.], cksum 0xd6b0 (correct), ack 22, win 140, options [nop,nop,sack 1 {1518:1542}], length 0
18:18:22.446296 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has kareline.legi.grenoble-inp.fr tell most8pc25.legi.grenoble-inp.fr, length 46
18:18:22.446318 ARP, Ethernet (len 6), IPv4 (len 4), Reply kareline.legi.grenoble-inp.fr is-at 00:10:18:e7:91:c0 (oui Unknown), length 28
18:19:14.030270 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has kareline.legi.grenoble-inp.fr tell most8pc25.legi.grenoble-inp.fr, length 46
18:19:14.030287 ARP, Ethernet (len 6), IPv4 (len 4), Reply kareline.legi.grenoble-inp.fr is-at 00:10:18:e7:91:c0 (oui Unknown), length 28
…..

On the CentOS7 client, with “-v -v” SSH says:

[tec21@most8pc25 ~]$ssh -v -v kareline OpenSSH_7.4p1, OpenSSL 1.0.2k-fips  26 Jan 2017
debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 58: Applying options for *
debug2: resolving “kareline” port 22
debug2: ssh_connect_direct: needpriv 0
debug1: Connecting to kareline [194.254.66.8] port 22. debug1: Connection established. debug1: key_load_public: No such file or directory debug1: identity file /home/tec21/.ssh/id_rsa type -1
debug1: key_load_public: No such file or directory debug1: identity file /home/tec21/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory debug1: identity file /home/tec21/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory debug1: identity file /home/tec21/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory debug1: identity file /home/tec21/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory debug1: identity file /home/tec21/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory debug1: identity file /home/tec21/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory debug1: identity file /home/tec21/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.4
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3
debug1: match: OpenSSH_5.3 pat OpenSSH_5* compat 0x0c000000
debug2: fd 3 setting O_NONBLOCK
debug1: Authenticating to kareline:22 as ‘tec21’
debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug2: local client KEXINIT proposal debug2: KEX algorithms:
curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1,ext-info-c debug2: host key algorithms:
ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ssh-ed25519-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ssh-dss-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa,ssh-dss debug2: ciphers ctos:
chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-cbc,aes192-cbc,aes256-cbc debug2: ciphers stoc:
chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-cbc,aes192-cbc,aes256-cbc debug2: MACs ctos:
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
debug2: MACs stoc:
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
debug2: compression ctos: none,zlib@openssh.com,zlib debug2: compression stoc: none,zlib@openssh.com,zlib debug2: languages ctos:
debug2: languages stoc:
debug2: first_kex_follows 0
debug2: reserved 0
debug2: peer server KEXINIT proposal debug2: KEX algorithms:
diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: host key algorithms: ssh-rsa,ssh-dss debug2: ciphers ctos:
aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se debug2: ciphers stoc:
aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se debug2: MACs ctos:
hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: MACs stoc:
hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: compression ctos: none,zlib@openssh.com debug2: compression stoc: none,zlib@openssh.com debug2: languages ctos:
debug2: languages stoc:
debug2: first_kex_follows 0
debug2: reserved 0
debug1: kex: algorithm: diffie-hellman-group-exchange-sha256
debug1: kex: host key algorithm: ssh-rsa debug1: kex: server->client cipher: aes128-ctr MAC: umac-64@openssh.com compression: none debug1: kex: client->server cipher: aes128-ctr MAC: umac-64@openssh.com compression: none debug1: kex: diffie-hellman-group-exchange-sha256 need=16 dh_need=16
debug1: kex: diffie-hellman-group-exchange-sha256 need=16 dh_need=16
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<3072<8192) sent Connection closed by 194.254.66.8 port 22 I'm stuck.... Patrick

5 thoughts on - Ssh Failure From CentOS7 To CentOS6

  • So the client is able to talk to the server and the server is responding.

    ^^ this says the first part started working.

    It got items and says it is going to use the user tec21 to login

    The server then stops the connection. I would then go through the following on the host:
    1. Is fail2ban or something else dropping the connection for some reason?
    2. Is there a log in /var/log/secure to say something is going on?
    3. Does running the server on port 2222 in debug mode and connecting from the client give a reason for it dieing?
    4. On the client and server are /etc/ssh/*_config changed from defaults and what changes are there. Sometimes saying you want XYZ
    algo in one and not having it in another causes dropped connections but I thought it gave an error.

    —
    Stephen J Smoogen.

  • Unlikely. If selinux was preventing anything, it’d prevent sshd from binding to the non-standard port (2222) and the daemon wouldn’t even start, or mislabeled pubkeys/ssh directories, where you’d just get a permission denied. From the SSH -vvv output, it looks like it dies in the middle of an authentication attempt.

  • Thanks all for your answers ans suggestions. It cannot be a fail2ban problem as firewall was disabled on the server for the tests.

    The time was playing against me so I went back to CentOS6 (these desktops must be available monday) and all run fine. I will investigate this later. It’s easy for me to switch from CentOS6 to CentOS7 as the OS
    is automatically installed (PXE boot + Kickstart)

    Patrick

  • Hi Patrick, we can help you investigate the problem and found the root cause building an identical setup using your kick-start. Can you share it with us for this purpose?

    It seems that something related to your setup and goes wrong in some way one on CentOS7

    Cheers, Fleur