Unable to SSH or SFTP, able to access WHM

[curiouslystuck]

Greetings

WHM v86.0.18

Server was setup a few years ago, updating automatically.

I have been able to access SSH and SFTP over the years without a problem.
SSH authentication via password (not keys). Last time was about a week ago.

Today I tried and I wasn't able to, as soon as I type the password it logged me back out.

Looking at the secure access log (via WHM / Terminal), I see the following entries.
Apr 26 22:40:52 servername sshd[20755]: Accepted password for userA from my.ip.address port 2024 ssh2
Apr 26 22:40:52 servername sshd[20755]: pam_unix(sshd:session): session opened for user userA by (uid=0)
Apr 26 22:40:52 servername sshd[20776]: Received disconnect from my.ip.address: 11: disconnected by user
Apr 26 22:40:52 servername sshd[20755]: pam_unix(sshd:session): session closed for user userA

I am trying to access the remote server (GoDaddy) via Mac Shell access, ATT DSL, also tried with a laptop connected to Verizon mobile hotspot, (thinking it might be a local router firewall issue and/or ISP blocking port?). - have not updated router settings in a long time either.

The server has been hammered lately by persistent bot(s). added a few weeks ago recommended .htaccess entry and now they are getting 404 errors on links they are accessing.

Only change done recently (yesterday) was to generate a new SSL Request, for a SSL cert but opted to continue to use the cpanel generated one (for the server), and cancel the one I was paying for and not using.

Accessing accounts hosted on server via SFTP (alternate port-non 22) exhibits the same issue although the error message is different.
Status: Connecting to xx.xx.xx.xx:xxxx...
Status: Connected to xx.xx.xx.xx
Error: FATAL ERROR: Received unexpected end-of-file from SFTP server
Error: Could not connect to server
Status: Waiting to retry...

Any ideas what might be wrong?

Thanks,

 

[cPanelLauren]

So you are able to access WHM, just not SSH correct? SFTP uses the same protocol. If you go to access SSH via terminal or PuTTY (outside of WHM) what is the output when you use the -v (verbose) flag? Something like:

ssh -vvv [email protected]

 

[curiouslystuck]

ssh -vvv [email protected] -p xxx3
OpenSSH_7.9p1, LibreSSL 2.7.3
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 48: Applying options for *
debug2: resolve_canonicalize: hostname xx.xx.xx.xx is address
debug2: ssh_connect_direct
debug1: Connecting to xx.xx.xx.xx [xx.xx.xx.xx] port xxx3.
debug1: Connection established.
debug1: identity file /Users/otheruser/.ssh/id_rsa type -1
debug1: identity file /Users/otheruser/.ssh/id_rsa-cert type -1
debug1: identity file /Users/otheruser/.ssh/id_dsa type -1
debug1: identity file /Users/otheruser/.ssh/id_dsa-cert type -1
debug1: identity file /Users/otheruser/.ssh/id_ecdsa type -1
debug1: identity file /Users/otheruser/.ssh/id_ecdsa-cert type -1
debug1: identity file /Users/otheruser/.ssh/id_ed25519 type -1
debug1: identity file /Users/otheruser/.ssh/id_ed25519-cert type -1
debug1: identity file /Users/otheruser/.ssh/id_xmss type -1
debug1: identity file /Users/otheruser/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_7.9
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3
debug1: match: OpenSSH_5.3 pat OpenSSH_5* compat 0x0c000002
debug2: fd 3 setting O_NONBLOCK
debug1: Authenticating to xx.xx.xx.xx:xxx3 as 'userA'
debug3: put_host_port: [xx.xx.xx.xx]:xxx3
debug3: hostkeys_foreach: reading file "/Users/otheruser/.ssh/known_hosts"
debug3: record_hostkey: found key type RSA in file /Users/otheruser/.ssh/known_hosts:2
debug3: load_hostkeys: loaded 1 keys from [xx.xx.xx.xx]:xxx3
debug3: order_hostkeyalgs: prefer hostkeyalgs: rsa-sha2-512-c[email protected],[email protected],[email protected],rsa-sha2-512,rsa-sha2-256,ssh-rsa
debug3: send packet: type 20
debug1: SSH2_MSG_KEXINIT sent
debug3: receive packet: type 20
debug1: SSH2_MSG_KEXINIT received
debug2: local client KEXINIT proposal
debug2: KEX algorithms: curve25519-sha256,[email protected],ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1,ext-info-c
debug2: host key algorithms: [email protected],[email protected],[email protected],rsa-sha2-512,rsa-sha2-256,ssh-rsa,[email protected],[email protected],[email protected],[email protected],ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519
debug2: ciphers ctos: [email protected],aes128-ctr,aes192-ctr,aes256-ctr,[email protected],[email protected]
debug2: ciphers stoc: [email protected],aes128-ctr,aes192-ctr,aes256-ctr,[email protected],[email protected]
debug2: MACs ctos: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: compression ctos: none,[email protected],zlib
debug2: compression stoc: none,[email protected],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,[email protected]
debug2: ciphers stoc: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected]
debug2: MACs ctos: hmac-md5,hmac-sha1,[email protected],hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug2: MACs stoc: hmac-md5,hmac-sha1,[email protected],hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug2: compression ctos: none,[email protected]
debug2: compression stoc: none,[email protected]
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: [email protected] compression: none
debug1: kex: client->server cipher: aes128-ctr MAC: [email protected] compression: none
debug3: send packet: type 34
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(2048<3072<8192) sent
debug3: receive packet: type 31
debug1: got SSH2_MSG_KEX_DH_GEX_GROUP
debug2: bits set: 1557/3072
debug3: send packet: type 32
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug3: receive packet: type 33
debug1: got SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Server host key: ssh-rsa SHA256:z9djZdxvUnzM6SLpcFo6INz6ixj3YFIF+dM/h3+JHh4
debug3: put_host_port: [xx.xx.xx.xx]:xxx3
debug3: put_host_port: [xx.xx.xx.xx]:xxx3
debug3: hostkeys_foreach: reading file "/Users/otheruser/.ssh/known_hosts"
debug3: record_hostkey: found key type RSA in file /Users/otheruser/.ssh/known_hosts:2
debug3: load_hostkeys: loaded 1 keys from [xx.xx.xx.xx]:xxx3
debug3: hostkeys_foreach: reading file "/Users/otheruser/.ssh/known_hosts"
debug3: record_hostkey: found key type RSA in file /Users/otheruser/.ssh/known_hosts:2
debug3: load_hostkeys: loaded 1 keys from [xx.xx.xx.xx]:xxx3
debug1: Host '[xx.xx.xx.xx]:xxx3' is known and matches the RSA host key.
debug1: Found key in /Users/otheruser/.ssh/known_hosts:2
debug2: bits set: 1590/3072
debug3: send packet: type 21
debug2: set_newkeys: mode 1
debug1: rekey after 4294967296 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug3: receive packet: type 21
debug1: SSH2_MSG_NEWKEYS received
debug2: set_newkeys: mode 0
debug1: rekey after 4294967296 blocks
debug1: Will attempt key: /Users/otheruser/.ssh/id_rsa
debug1: Will attempt key: /Users/otheruser/.ssh/id_dsa
debug1: Will attempt key: /Users/otheruser/.ssh/id_ecdsa
debug1: Will attempt key: /Users/otheruser/.ssh/id_ed25519
debug1: Will attempt key: /Users/otheruser/.ssh/id_xmss
debug2: pubkey_prepare: done
debug3: send packet: type 5
debug3: receive packet: type 6
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug3: send packet: type 50
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password,keyboard-interactive
debug3: start over, passed a different list publickey,gssapi-keyex,gssapi-with-mic,password,keyboard-interactive
debug3: preferred publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /Users/otheruser/.ssh/id_rsa
debug3: no such identity: /Users/otheruser/.ssh/id_rsa: No such file or directory
debug1: Trying private key: /Users/otheruser/.ssh/id_dsa
debug3: no such identity: /Users/otheruser/.ssh/id_dsa: No such file or directory
debug1: Trying private key: /Users/otheruser/.ssh/id_ecdsa
debug3: no such identity: /Users/otheruser/.ssh/id_ecdsa: No such file or directory
debug1: Trying private key: /Users/otheruser/.ssh/id_ed25519
debug3: no such identity: /Users/otheruser/.ssh/id_ed25519: No such file or directory
debug1: Trying private key: /Users/otheruser/.ssh/id_xmss
debug3: no such identity: /Users/otheruser/.ssh/id_xmss: No such file or directory
debug2: we did not send a packet, disable method
debug3: authmethod_lookup keyboard-interactive
debug3: remaining preferred: password
debug3: authmethod_is_enabled keyboard-interactive
debug1: Next authentication method: keyboard-interactive
debug2: userauth_kbdint
debug3: send packet: type 50
debug2: we sent a keyboard-interactive packet, wait for reply
debug3: receive packet: type 60
debug2: input_userauth_info_req
debug2: input_userauth_info_req: num_prompts 1
Password: <password was entered>
debug3: send packet: type 61
debug3: receive packet: type 60
debug2: input_userauth_info_req
debug2: input_userauth_info_req: num_prompts 0
debug3: send packet: type 61
debug3: receive packet: type 52
debug1: Authentication succeeded (keyboard-interactive).
Authenticated to xx.xx.xx.xx ([xx.xx.xx.xx]:xxx3).
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug3: send packet: type 90
debug1: Requesting [email protected]
debug3: send packet: type 80
debug1: Entering interactive session.
debug1: pledge: network
debug3: receive packet: type 91
debug2: channel_input_open_confirmation: channel 0: callback start
debug2: fd 3 setting TCP_NODELAY
debug3: ssh_packet_set_tos: set IP_TOS 0x48
debug2: client_session2_setup: id 0
debug2: channel 0: request pty-req confirm 1
debug3: send packet: type 98
debug1: Sending environment.
debug3: Ignored env TERM_PROGRAM
debug3: Ignored env SHELL
debug3: Ignored env TERM
debug3: Ignored env TMPDIR
debug3: Ignored env Apple_PubSub_Socket_Render
debug3: Ignored env TERM_PROGRAM_VERSION
debug3: Ignored env TERM_SESSION_ID
debug3: Ignored env USER
debug3: Ignored env SSH_AUTH_SOCK
debug3: Ignored env PATH
debug3: Ignored env PWD
debug1: Sending env LANG = en_US.UTF-8
debug2: channel 0: request env confirm 0
debug3: send packet: type 98
debug3: Ignored env XPC_FLAGS
debug3: Ignored env XPC_SERVICE_NAME
debug3: Ignored env SHLVL
debug3: Ignored env HOME
debug3: Ignored env LOGNAME
debug3: Ignored env _
debug3: Ignored env __CF_USER_TEXT_ENCODING
debug2: channel 0: request shell confirm 1
debug3: send packet: type 98
debug2: channel_input_open_confirmation: channel 0: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug3: receive packet: type 99
debug2: channel_input_status_confirm: type 99 id 0
debug2: PTY allocation request accepted on channel 0
debug2: channel 0: rcvd adjust 2097152
debug3: receive packet: type 99
debug2: channel_input_status_confirm: type 99 id 0
debug2: shell request accepted on channel 0
Last login: Tue Apr 28 20:59:30 2020 from <my local IP address>
debug3: receive packet: type 98
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug3: receive packet: type 98
debug1: client_input_channel_req: channel 0 rtype [email protected] reply 0
debug2: channel 0: rcvd eow
debug2: channel 0: chan_shutdown_read (i0 o0 sock -1 wfd 4 efd 6 [write])
debug2: channel 0: input open -> closed
debug3: receive packet: type 96
debug2: channel 0: rcvd eof
debug2: channel 0: output open -> drain
debug2: channel 0: obuf empty
debug2: channel 0: chan_shutdown_write (i3 o1 sock -1 wfd 5 efd 6 [write])
debug2: channel 0: output drain -> closed
debug3: receive packet: type 97
debug2: channel 0: rcvd close
debug3: channel 0: will not send data after close
debug2: channel 0: almost dead
debug2: channel 0: gc: notify user
debug2: channel 0: gc: user detached
debug2: channel 0: send close
debug3: send packet: type 97
debug2: channel 0: is dead
debug2: channel 0: garbage collecting
debug1: channel 0: free: client-session, nchannels 1
debug3: channel 0: status: The following connections are open:
  #0 client-session (t4 r0 i3/0 o3/0 e[write]/0 fd -1/-1/6 sock -1 cc -1)

debug3: send packet: type 1
debug3: fd 1 is not O_NONBLOCK
Connection to xx.xx.xx.xx closed.
Transferred: sent 2696, received 2752 bytes, in 0.1 seconds
Bytes per second: sent 21220.7, received 21661.4
debug1: Exit status 0

 

[curiouslystuck]

userA is the admin account, which was also added to wheel group to be able to su - to root (a long time ago), direct ssh root login is disabled.
Typically I would ssh to [email protected]:Port then su - to root and do what I needed to do, until recently.

 

[cPanelLauren]

Do you have customizations in /etc/ssh/sshd_config and/or the .bash_profile for the user?

 

[curiouslystuck]

No edits other than changing the port and disable direct root login in sshd_config.

However, I found a post in GoDaddy site that seems to indicate some if not all WHM users were also experiencing the same issue.

GoDaddy: SSH accepting connection, then dropping connection?

Looks like an update on GoDaddy's side created the problem. In my case my server had two different versions of openssh/clients/server installed (5.3p1-124 & 5.3p1-269).
Removed all applicable, used yum to install, rebooted server (also replaced new config with my old config), access is back.

 

[Teryakisan]

I am having this exact same issue. Server has been trucking along for years. Same WHM version. Same host.

@curiouslystuck did you happen to notice if your WHM was down for 'scheduled maintenance' yesterday? Our was and all off this seems to have started then.

WHM SSH Terminal output looks pretty normal until...

debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug3: Wrote 272 bytes for a total of 1181
debug3: check_host_in_hostfile: host xxxxxxxxx.com filename /root/.ssh/known_hosts
debug3: check_host_in_hostfile: host xxxxxxxxx.com filename /root/.ssh/known_hosts
debug3: check_host_in_hostfile: host xxxxxxxxx.com filename /etc/ssh/ssh_known_hosts
debug3: check_host_in_hostfile: host xxxxxxxxx.com filename /etc/ssh/ssh_known_hosts
debug3: check_host_in_hostfile: host xxx.xxx.xxx.xxx filename /root/.ssh/known_hosts
debug3: check_host_in_hostfile: host xxx.xxx.xxx.xxx filename /root/.ssh/known_hosts
debug3: check_host_in_hostfile: host xxx.xxx.xxx.xxx filename /etc/ssh/ssh_known_hosts
debug3: check_host_in_hostfile: host xxx.xxx.xxx.xxx filename /etc/ssh/ssh_known_hosts
debug3: check_host_in_hostfile: host xxxxxxxxx.com filename /root/.ssh/known_hosts
debug3: check_host_in_hostfile: host xxxxxxxxx.com filename /etc/ssh/ssh_known_hosts
debug2: no key of type 0 for host xxxxxxxxx.com
debug3: check_host_in_hostfile: host xxxxxxxxx.com filename /root/.ssh/known_hosts2
debug3: check_host_in_hostfile: host xxxxxxxxx.com filename /etc/ssh/ssh_known_hosts2
debug3: check_host_in_hostfile: host xxxxxxxxx.com filename /root/.ssh/known_hosts
debug3: check_host_in_hostfile: host xxxxxxxxx.com filename /etc/ssh/ssh_known_hosts
debug2: no key of type 2 for host xxxxxxxxx.com
debug3: check_host_in_hostfile: host xxxxxxxxx.com filename /root/.ssh/known_hosts2
debug3: check_host_in_hostfile: host xxxxxxxxx.com filename /etc/ssh/ssh_known_hosts2
debug3: check_host_in_hostfile: host xxxxxxxxx.com filename /root/.ssh/known_hosts
debug3: check_host_in_hostfile: host xxxxxxxxx.com filename /etc/ssh/ssh_known_hosts
debug2: no key of type 3 for host xxxxxxxxx.com

 

[cPanelLauren]

Have you guys contacted the provider for assistance with this?

 

[Teryakisan]

Absolutely. After my post, we were able to escalate the issue with GoDaddy and they think that Cent has pushed an update intended for CentOS 7 out to clients running CentOS 6. Seems that GoDaddy has only deployed CentOS 7 in the EU. Oops.

Have sent @curiouslystuck's solution to IT to see if that will solve the issue for us as well.

 

[Teryakisan]

@curiouslystuck's solution worked for us as well. :D