Unable to SSH or SFTP, able to access WHM
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,
-
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 user@domainorip0 -
ssh -vvv userA@xx.xx.xx.xx -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-cert-v01@openssh.com,rsa-sha2-256-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,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,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-group14-sha256,diffie-hellman-group14-sha1,ext-info-c debug2: host key algorithms: rsa-sha2-512-cert-v01@openssh.com,rsa-sha2-256-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,rsa-sha2-512,rsa-sha2-256,ssh-rsa,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,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519 debug2: ciphers ctos: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com debug2: ciphers stoc: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com 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 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: 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 no-more-sessions@openssh.com 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 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 eow@openssh.com 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 00 -
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 userA@IP.Address:Port then su - to root and do what I needed to do, until recently. 0 -
Do you have customizations in /etc/ssh/sshd_config and/or the .bash_profile for the user? 0 -
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. 0 -
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.com0 -
Have you guys contacted the provider for assistance with this? 0 -
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. 0 -
@curiouslystuck's solution worked for us as well. :D 0
Please sign in to leave a comment.
Comments
9 comments