CentOS Hold Me Back From Work – Sshd …bull

Home » CentOS » CentOS Hold Me Back From Work – Sshd …bull
CentOS 20 Comments

I don’t know what’s going on

the sushi from the laptop always kick me out!!!

Fresh installation.

packet_write_wait: Connection

How can that be!

Andy

20 thoughts on - CentOS Hold Me Back From Work – Sshd …bull

  • what is wrong with the default sshd server.

    after retry to connect sshd – key changed from known hosts????

    grrr

  • You will need to provide a little more information, what’s the output when you use SSH -vvv user@host?

  • ine-imac-andy:~ andy$ SSH 141.52.135.21
    @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
    @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
    @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
    IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
    Someone could be eavesdropping on you right now (man-in-the-middle attack)!
    It is also possible that a host key has just been changed. The fingerprint for the RSA key sent by the remote host is SHA256:KIKE0V+Hm1UW4XtpTAVsl/7QWqJSVoQHfLnjj3vn/nM. Please contact your system administrator. Add correct host key in /Users/andy/.ssh/known_hosts to get rid of this message. Offending ECDSA key in /Users/andy/.ssh/known_hosts:22
    RSA host key for 141.52.135.21 has changed and you have requested strict checking. Host key verification failed. ine-imac-andy:~ andy$ vi .ssh/
    id_rsa id_rsa.pub known_hosts
    ine-imac-andy:~ andy$ vi .ssh/known_hosts ine-imac-andy:~ andy$ SSH -vvv andy@141.52.135.21
    OpenSSH_6.9p1, LibreSSL 2.1.8
    debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 21: Applying options for *
    debug1: /etc/ssh/ssh_config line 56: Applying options for *
    debug2: ssh_connect: needpriv 0
    debug1: Connecting to 141.52.135.21 [141.52.135.21] port 22. debug1: Connection established. debug1: identity file /Users/andy/.ssh/id_rsa type 1
    debug1: key_load_public: No such file or directory debug1: identity file /Users/andy/.ssh/id_rsa-cert type -1
    debug1: key_load_public: No such file or directory debug1: identity file /Users/andy/.ssh/id_dsa type -1
    debug1: key_load_public: No such file or directory debug1: identity file /Users/andy/.ssh/id_dsa-cert type -1
    debug1: key_load_public: No such file or directory debug1: identity file /Users/andy/.ssh/id_ecdsa type -1
    debug1: key_load_public: No such file or directory debug1: identity file /Users/andy/.ssh/id_ecdsa-cert type -1
    debug1: key_load_public: No such file or directory debug1: identity file /Users/andy/.ssh/id_ed25519 type -1
    debug1: key_load_public: No such file or directory debug1: identity file /Users/andy/.ssh/id_ed25519-cert type -1
    debug1: Enabling compatibility mode for protocol 2.0
    write: Broken pipe ine-imac-andy:~ andy$ SSH -vvv andy@141.52.135.21
    OpenSSH_6.9p1, LibreSSL 2.1.8
    debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 21: Applying options for *
    debug1: /etc/ssh/ssh_config line 56: Applying options for *
    debug2: ssh_connect: needpriv 0
    debug1: Connecting to 141.52.135.21 [141.52.135.21] port 22. debug1: Connection established. debug1: identity file /Users/andy/.ssh/id_rsa type 1
    debug1: key_load_public: No such file or directory debug1: identity file /Users/andy/.ssh/id_rsa-cert type -1
    debug1: key_load_public: No such file or directory debug1: identity file /Users/andy/.ssh/id_dsa type -1
    debug1: key_load_public: No such file or directory debug1: identity file /Users/andy/.ssh/id_dsa-cert type -1
    debug1: key_load_public: No such file or directory debug1: identity file /Users/andy/.ssh/id_ecdsa type -1
    debug1: key_load_public: No such file or directory debug1: identity file /Users/andy/.ssh/id_ecdsa-cert type -1
    debug1: key_load_public: No such file or directory debug1: identity file /Users/andy/.ssh/id_ed25519 type -1
    debug1: key_load_public: No such file or directory debug1: identity file /Users/andy/.ssh/id_ed25519-cert type -1
    debug1: Enabling compatibility mode for protocol 2.0
    debug1: Local version string SSH-2.0-OpenSSH_6.9
    debug1: Remote protocol version 2.0, remote software version OpenSSH_5.9p1 Debian-5ubuntu1.8
    debug1: match: OpenSSH_5.9p1 Debian-5ubuntu1.8 pat OpenSSH_5* compat 0x0c000000
    debug2: fd 3 setting O_NONBLOCK
    debug1: Authenticating to 141.52.135.21:22 as ‘andy’
    debug3: hostkeys_foreach: reading file “/Users/andy/.ssh/known_hosts”
    debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug2: kex_parse_kexinit: curve25519-sha256@libssh.org,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-ed25519-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-ed25519,ssh-rsa,ssh-dss 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: 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,ssh-dss debug2: kex_parse_kexinit: 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: kex_parse_kexinit: 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: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
    debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,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
    debug1: kex: server->client aes128-ctr umac-64@openssh.com none debug1: kex: client->server aes128-ctr umac-64@openssh.com none debug1: sending SSH2_MSG_KEX_ECDH_INIT
    debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
    debug1: Server host key: ssh-rsa SHA256:KIKE0V+Hm1UW4XtpTAVsl/7QWqJSVoQHfLnjj3vn/nM
    debug3: hostkeys_foreach: reading file “/Users/andy/.ssh/known_hosts”
    The authenticity of host ‘141.52.135.21 (141.52.135.21)’ can’t be established. RSA key fingerprint is SHA256:KIKE0V+Hm1UW4XtpTAVsl/7QWqJSVoQHfLnjj3vn/nM. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added ‘141.52.135.21’ (RSA) to the list of known hosts. 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 ssh_packet_read: Connection reset by peer

  • I’ve installed CentOS a LOT of times, versions 5, 6, and 7, and never had any issues with the built in sshd service, and a variety of clients, including other linux ssh, putty and securecrt on windows, gui SCP/SFTP
    utilties(they use sshd too), freebsd ssh, solaris ssh, aix ssh.

    the “key changed from known_hosts” error happens if your client had previously connected with the same “user@hostname” on a previous installation of the server OS with a different ssh_host_key

    you need to provide a lot more information if you expect a more specific answer from anyone, like what version of CentOS did you install, what client software you’re using to connect to it, any pertinent background information like was this hostname previously used for a different OS
    install, etc etc.

  • This never happen to me, first time too. This was never happen when i drive the machine with the usb drive installation of CentOS, same state. As I said: Fresh from yesterday.

    Greetings

    Andy

  • any issues with the built in sshd service, and a variety of clients, including other linux ssh, putty and securecrt on windows, gui SCP/SFTP
    utilties(they use sshd too), freebsd ssh, solaris ssh, aix ssh. previously connected with the same “user@hostname” on a previous installation of the server OS with a different ssh_host_key answer from anyone, like what version of CentOS did you install, what client software you’re using to connect to it, any pertinent background information like was this hostname previously used for a different OS
    install, etc etc.

    You installed the server with the same IP, you need to remove the entry from the known hosts, which is located in .ssh on the computer you are trying to connect to.

  • Same machine iMac for the last two weeks.

    Can work on virtual box CentOS 7
    Usb drive installation CentOS 7 works

    Fresh installation not on this laptop.

  • The problem is not with your installation of CentOS, it is with the computer you are connecting from. Read the error log you pasted earlier, it tells you exactly what the problem is and how to remedy it:

    Open up the file /Users/andy/.ssh/known_hosts and delete line 22.

  • (sorry if I repeat what someone already said – it is already long thread, and I’m reading my mail from latest messages to oldest…)

    Usually host key (of remote machine) could change for the following reasons:

    1. benign reasons: remote machine system was reinstalled and/or SSH server keys were re-generated, or some machine was retired and different machine re-used its IP, or for some other reason, like changes in DNS, you are connecting to _different_ system that has same IP as the one you were connecting to in the past

    In this case it is indeed safe to delete old known keys resembling this host (there may be more that one), then SSH to it and accept new key

    2. Bad reasons: remote machine is hijacked and host keys have changed. Or, as SSH error message says, it may be “man in the middle” attack. If some intermediate malicious machine is able to intercept your traffic, it can make encrypted SSH tunnel between source machine and itself, and between itself and destination machine, having all traffic in clear text on itself. The only thing that stops this “man in the middle” is you, as you are verifying the host key, and “man in the middle” can not use as host key the key of remote machine (he would need both secret and public key of the pair for that). This is how SSH is designed to ensure you are talking to the machine you think you are talking to.

    If this is the case, you shouldn’t continue, instead right thing to do is to first make sure that indeed the key of remote machine was changed by its admin. Calling remote machine’s sysadmin would be right thing to do.

    I hope, this helps.

    Valeri

    ++++++++++++++++++++++++++++++++++++++++
    Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247
    ++++++++++++++++++++++++++++++++++++++++

  • I know how todo. I try it out tomorrow. But it’s the first time with this kind of problem with a fresh installed CentOS 7.

    Thanks Valeri.

  • Valeri Galtsev wrote:


    Just as a side note, here: when we rebuild a machine – say, when we were doing CentOS 5 to 6, or when we build a new machine for someone, 6->7, we
    *remove /etc/ssh/ssh_host*, and rsync in the *old* /etc/ssh/ssh_host* from backup.

    Not doing this does have a tendency to freak out the users….

    mark

  • Yes that is true. We do this too sometimes, but for machines that are too long on the network when we upgrade the system we do follow “good security practice” and re-generate the keys. Even though there is no reason to think that secret key may be compromised.

    Valeri

    ++++++++++++++++++++++++++++++++++++++++
    Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247
    ++++++++++++++++++++++++++++++++++++++++

  • Thank you, John! You made my day!

    Valeri

    ++++++++++++++++++++++++++++++++++++++++
    Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247
    ++++++++++++++++++++++++++++++++++++++++


  • I see one possibility that explains both the key change and the connection resets:

    You installed a new server and used an IP address that was already in use on another server. That’s why you already had an SSH key for that address. The connection resets occur when the client you’re using to connect updates its ARP table and swaps from the MAC address on the new host to the MAC address on the old host (or visa versa).

  • Oh yes, and bizarre may happen if you have two machines with the same static IP _simultaneously_ on the network. To check if that is the case
    (for particular IP, say 192.168.2.7) from the machine with different IP on the same subnet 192.168.2.x do

    arping 192.168.2.7

    you will get ARP responses from all machines, and if there is more than one, you will see responces coming from different MAC addresses.

    Valeri

    ++++++++++++++++++++++++++++++++++++++++
    Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247
    ++++++++++++++++++++++++++++++++++++++++

  • Many of the other answers are ignoring this detail by simply recommending that the OP remove the offending line from known_hosts and try again. That’s an excellent way to get MITM’d!

    When OpenSSH warns you that the remote host’s key is different from the one it saw before, you *must not ignore it* unless you know exactly why it changed.

    Don’t guess! Verify.

    How?

    Log into the intended host over some trusted channel, then say:

    for f in /etc/ssh/ssh_host_*_key ; do ssh-keygen -lf $f ; done

    If none of those values exactly matches

    SHA256:KIKE0V+Hm1UW4XtpTAVsl/7QWqJSVoQHfLnjj3vn/nM.

    then OpenSSH is right to prevent your login. It means you aren’t connecting to the server you think you are. It might be a benign misconfiguration or it might be a MITM attempt.

    This is potentially a game-over scenario. Don’t ignore it.

    See also this article on the TOFU problem:

    https://en.wikipedia.org/wiki/Trust_on_first_use