4

On a cPanel server, where SSH worked yesterday, I suddenly can’t login with SSH. I get “Access Denied.”

I checked that logins with passwords are enabled in /etc/ssh/sshd_config and they are. I tried logging in as root via KVM then SSH’ing to localhost, it works.

I’ve tried multiple accounts, even creating a new account but it won’t work and I’m sure the passwords are correct because I’ve reset them multiple times and even copy-pasted them into Putty, not to mention they work via KVM.

I don’t know of anything that happened that would cause this to change overnight.

I’ve also checked sshd_config for AllowUser directives which allow you to restrict access to a certain IP, but it doesn’t have any.

And another point, I just checked it on my phone’s 4G and it works there, just not on my DSL.

In the past the connection on my DSL has been slow and spurious to my server. Even after moving to a different host in a different country. At those times every other site I try works fine. Not sure if relevant.

Here's the output of ssh -v using Git for Windows' SSH.

OpenSSH_6.6.1, OpenSSL 1.0.1i 6 Aug 2014
debug1: Connecting to <host> [<IP>] port 22.
debug1: Connection established.
debug1: identity file /.ssh/id_rsa type -1
debug1: identity file /.ssh/id_rsa-cert type -1
debug1: identity file /.ssh/id_dsa type -1
debug1: identity file /.ssh/id_dsa-cert type -1
debug1: identity file /.ssh/id_ecdsa type -1
debug1: identity file /.ssh/id_ecdsa-cert type -1
debug1: identity file /.ssh/id_ed25519 type -1
debug1: identity file /.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.6.1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3
debug1: match: OpenSSH_5.3 pat OpenSSH_5* compat 0x0c000000
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<3072<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Server host key: RSA <key>
The authenticity of host '<host> (<IP>)' can't be established.
RSA key fingerprint is <key>.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '<host>,<IP>' (RSA) to the list of known hosts.
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Next authentication method: publickey
debug1: Trying private key: /.ssh/id_rsa
debug1: Trying private key: /.ssh/id_dsa
debug1: Trying private key: /.ssh/id_ecdsa
debug1: Trying private key: /.ssh/id_ed25519
debug1: Next authentication method: password
<user>@<host>'s password:
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
Permission denied, please try again.
<user>@<host>'s password:
  • You should add these details to your question: A neutered—meaning your specifics removed—output of what happens when you SSH with the -v (verbose/debugging) option like this: ssh -v [username]@[host] from your DSL connection. – JakeGould Feb 22 '15 at 5:14
3

In the past the connection on my DSL has been slow and spurious to my server. Even after moving to a different host in a different country. At those times every other site I try works fine. Not sure if relevant.

Based on the debugging output of ssh -v you are showing—and your comment above which I think is relevant—I would recommend adjusting the sshd_config on your server like this; note that I like to use nano but feel free to use whatever text editor you prefer using.

First, open up the ssh_config file like this:

sudo nano /etc/ssh/sshd_config

There should be a configuration area called ”GSSAPI options” that looks like this:

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes

Change that to uncomment the line that reads “GSSAPIAuthentication no”:

# GSSAPI options
GSSAPIAuthentication no
#GSSAPICleanupCredentials yes

Finally, save that file and restart the SSH server daemon like this. To restart SSH on a RedHat/CentOS-based system do this:

sudo service sshd restart

To restart SSH on a Debian/Ubuntu-based system do this:

sudo service ssh restart

Now try logging in again. I would still recommend ssh -v for debugging purposes, but I believe this will clear things up.

  • Am I supposed to do this on the server? I tried but the ssh -v output didn't change, i.e., it didn't have hostbased or keyboard-interactive in the list of "Authentications that can continue". – goobliata Feb 23 '15 at 0:05
  • Ok, updated. There is a Host * block in ssh_config and I was adding PreferredAuthentications under it, not indented. I squeezed it in indented within the host section and now I can login. The ssh -v output still didn't change though, but I guess those are just flags and not authentication methods or something... Thanks. – goobliata Feb 23 '15 at 0:15
  • @trentg Yes, as I state: “I would recommend adjusting the ssh_config on your server like this…” And yes, I’m saying you should change your SSH daemon config on the server to add hostbased or keyboard-interactive to the list of PreferredAuthentications. Happily this works! When you say “I squeezed it in indented within the host section and now I can login.” Perfect! The directives can be applied on a per-host basis. So when you added it indented under Host * it now will apply those settings to all hosts (* = wildcard) that attempt to connect via SSH to your server. Glad this worked! – JakeGould Feb 23 '15 at 0:16
  • 1
    @JakeGould ssh_config is the system-wide configuration file for the client, not the server. The ssh server reads sshd_config. – Kenster Feb 23 '15 at 2:37
  • 1
    @JakeGould that answer isn't very clear about it, but it's talking about editing the client config one the local host in one spot, and editing the server config on the remote host in another spot. Editing ssh_config on a remote server won't affect incoming sessions to that server, and restarting sshd after editing the client config is a waste of time. – Kenster Feb 23 '15 at 10:52
1

I reinstalled the openssh-server package and it seems to have worked, for now. The sshd_config file did not change from how I had it last so it's very strange.

  • 1
    Ug. This was a temporary "fix" (more likely a fluke) too. The problem keeps coming back and going away every few days. – goobliata Mar 13 '15 at 22:10
  • Did you find a permanent solution to this? – manu_dilip_shah Apr 10 '18 at 6:08
  • I never did. I later installed Debian without cPanel and haven't had the problem again, but I'm not sure that was the issue. – goobliata Apr 11 '18 at 12:41

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.