Skip to main content
Help Center
The GoDaddy Community will undergo maintenance starting on Wednesday, July 28th at 3pm PST / 6pm EST. Learn more
cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Go to solution
PaddyLandau
Helper II

SSH with private key suddenly asking for cPanel password

I have been using a private-public key pair to access SSH. This is invaluable for me to run certain automated tasks, because using a private key allows me to access SSH without using a password.

 

For the past couple of days, however, accessing SSH asks me for the cPanel password. I had made no changes whatsoever. I tried generating a new key-pair (and deleting the old pair), but it still wants me to enter the cPanel password every time I access SSH.

 

This means that it's pointless actually using a key-pair at all.

 

Do you know how I can fix this, please?

1 ACCEPTED SOLUTION

Well, well, well, What a surprise.

 

It's working again.

 

It didn't work yesterday, and since then I made no changes whatsoever. But, today it works.

 

You might argue that it's something that I've done while trying to fix the problem. But, there's a second account that now works, and I had done nothing whatsoever with it.

 

So…

 

As you and I agreed, it was a problem with GoDaddy, not with us.

 

I'm a bit cross with GoDaddy's support team for categorically refusing to raise this to their higher-level support. I've wasted hours on this.

 

Please check if it's working with you now.

View solution in original post

11 REPLIES 11
Yoder
Getting Started

After multiple support calls and multiple hours, I don't have much useful to add except that it's not just you. Something enormous was broken recently. It may possibly have been a reaction to this security breach: https://business.financialpost.com/technology/tech-news/godaddy-suffers-hack-of-ssh-credentials

 

My account is currently broken in the same way - only password login works. cPanel does nothing useful.

 

I can only guess that GoDaddy disabled key login entirely, but support seems to deny this.

Thank you for your answer, @Yoder .

 

I realised yesterday that this is problematic in another way: Delegate Access.

 

I support a few community and charity websites. A couple in particular have delegated access to me, which makes sense as they can restrict what I can do, and they don't have to give me their login password. When I need SSH, I use the private key to access SSH — but, now I can't do so, because of this problem! It worsens security in this regard, because they need to give me their password. Not good.

 

Given your answer, I think that I'll have to phone GoDaddy and emphasise the problem. Thanks again.

Yes, this is a huge problem. Ultimately I'll need to either get this fixed, or switch hosting plans/providers. Perhaps this problem only impacts some of GoDaddy's hosting plans?

 

FYI, cPanel still lets you manage SSH keys, which edits your ~/.ssh/authorized_keys file for you, as if it should work. I tried importing new keys and creating a new key, and starting over with an empty .ssh directory.  It seems that cPanel doesn't do anything useful or special on its own - it is merely a GUI to prevent people from needing to use a text editor or command line to update those files.

 

The only thing that makes sense at this point is that PubkeyAuthentication has been set to "no" in the sshd configs, but support indicated they were told key login should still work. So perhaps it was disabled accidentally?

@Yoder , I've also tried to regenerate the keys, both on my machine and using GoDaddy's cPanel. I agree that the cPanel appears to be just a front-end.

 

I've been googling this extensively, also checking folder permissions, and I can find nothing wrong.

 

I was on the phone to GoDaddy a couple of times today, and I had the same experience as you did. They are adamant that the error lies on my side.

 

I hopped onto Windows and installed PuTTY. PuTTY gave an error: "Server refused our key". Nothing else. I returned to Linux (my usual desktop mode) and ran SSH with full debugging. I can't find any error in the debug logs, so I've asked on Ubuntu Forums . Those guys are usually good, but because the query specifically applies to GoDaddy, we might not get an answer there.

 

I know very little about SSH, so PubkeyAuthentication is new to me. Reading the documentation, if it's been set to "no", this is definitely the problem. Where did you find this setting on GoDaddy, please?

 

I'll write here again with any updates.

You can't see what it's set to because you don't have file permissions to view that file.

 

However, I just ran some more detailed analysis of ssh debug logs, and actually it doesn't look like "PubkeyAuthentication no" is the issue.  At least on OpenSSH_8.0 the behavior with "PubkeyAuthentication no" is for the server to not list "publickey" as an authentication for the client to try.  GoDaddy's sshd is telling the client that "publickey" is allowed.  So either that's an issue with GoDaddy's older version of sshd, or they've done something else to make it not work.

 

The only thing I can think of that they could do to break this in this way would be to not point `sshd` at the right authorized_keys file.  The "AuthorizedKeysFile" setting in sshd could be pointed to anything else, which would cause this.  Perhaps support could find out if that's been changed?

On the server that I use, GoDaddy allows me to see the file /etc/ssh/ssh_config (I include it below). The file includes neither AuthorizedKeysFile nor PubkeyAuthentication, which means that the defaults apply. The defaults (according to both what I find online and GoDaddy's own man sshd_config) are:

AuthorizedKeysFile .ssh/authorized_keys
PubkeyAuthentication yes

The latter applies to protocol version 2 only. How can I check which protocol is being used? I believe that it's 2.0, because my debug line (from running ssh -vvv …) reads:

debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3

There is a potential problem with AuthorizedKeysFile in that the default doesn't include the home folder. That means that it might be looking at a different .ssh folder, although a different site says that the default is actually ~/.ssh/authorized_keys.

I hope that we can diagnose this, because it's frustrating as heck.

Here's the file /etc/ssh/ssh_config from GoDaddy's server:

#	$OpenBSD: ssh_config,v 1.25 2009/02/17 01:28:32 djm Exp $

# This is the ssh client system-wide configuration file.  See
# ssh_config(5) for more information.  This file provides defaults for
# users, and the values can be changed in per-user configuration files
# or on the command line.

# Configuration data is parsed as follows:
#  1. command line options
#  2. user-specific file
#  3. system-wide file
# Any configuration value is only changed the first time it is set.
# Thus, host-specific definitions should be at the beginning of the
# configuration file, and defaults at the end.

# Site-wide defaults for some commonly used options.  For a comprehensive
# list of available options, their meanings and defaults, please see the
# ssh_config(5) man page.

# Host *
#   ForwardAgent no
#   ForwardX11 no
#   RhostsRSAAuthentication no
#   RSAAuthentication yes
#   PasswordAuthentication yes
#   HostbasedAuthentication no
#   GSSAPIAuthentication no
#   GSSAPIDelegateCredentials no
#   GSSAPIKeyExchange no
#   GSSAPITrustDNS no
#   BatchMode no
#   CheckHostIP yes
#   AddressFamily any
#   ConnectTimeout 0
#   StrictHostKeyChecking ask
#   IdentityFile ~/.ssh/identity
#   IdentityFile ~/.ssh/id_rsa
#   IdentityFile ~/.ssh/id_dsa
#   Port 22
#   Protocol 2,1
#   Cipher 3des
#   Ciphers aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc
#   MACs hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160
#   EscapeChar ~
#   Tunnel no
#   TunnelDevice any:any
#   PermitLocalCommand no
#   VisualHostKey no
Host *
	GSSAPIAuthentication yes
# If this option is set to yes then remote X11 clients will have full access
# to the original X11 display. As virtually no X11 client supports the untrusted
# mode correctly we set this to yes.
	ForwardX11Trusted yes
# Send locale-related environment variables
	SendEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES 
	SendEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT 
	SendEnv LC_IDENTIFICATION LC_ALL LANGUAGE
	SendEnv XMODIFIERS

 

Unfortunately, no, that's the ssh client config, not the sshd config.  The sshd config is normally located at /etc/ssh/sshd_config.

 

One way to get the current behavior would be:

 

AuthorizedKeysFile /dev/null



@Yoder wrote:

… that's the ssh client config, not the sshd config.  The sshd config is normally located at /etc/ssh/sshd_config.



Oops, my bad!

 

Looking on GoDaddy's server, there is no such file as either /etc/sshd_config or /etc/ssh/sshd_config (the latter is the default path). This makes it difficult to check, because according to man sshd, "sshd refuses to start if there is no configuration file." So, it must be using a different configuration file.

 

Interestingly, though, I've made partial progress — but I have no idea how! Yesterday, I created a new key pair with a new password so that I could tell when the key was being used. It wasn't being used (SSH didn't ask for the private key's password when connecting).

 

Until about an hour ago. Suddenly, it started asking for the private key's password when connecting.

 

Unfortunately, it's not a solution, because it's asking for both the private key's password and the cPanel password. You can see how it asks for both:

Enter passphrase for key '/home/paddy/.ssh/id_rsa_godaddy_paddy': 
{readacted-username}@{redacted-hostname}'s password:

 

Here is what I have done, which might or might not have made the difference. On GoDaddy's server, I created the file ~/.ssh/config and entered the following line:

PubkeyAuthentication yes

(From what I read, the file ~/.ssh/config takes precedence over /etc/ssh/sshd_config. I could be wrong.)

 

 This didn't take effect immediately, but only after ten minutes or so (I wasn't timing it), which is why it might have been sheer coincidence. Or, maybe, the SSH daemon refreshes itself on a regular basis, but I couldn't find any evidence of that online.

 

I removed the config file to see if that made a difference, but it's been an hour already, and it still asks for the private key's password. I know that it really is asking for the key's password because it complains if I enter the wrong password. So, my config file was probably some type of coincidence.

 

So, all that we have to do now is to get SSH to stop asking for cPanel's password. At least, that's if I've understood the whole thing correctly — I might be completely on the wrong track, because I'm no expert in these matters.

~/.ssh/config should not impact inbound connections. That's the config that would control what outbound `ssh` commands from the server would do.

 

The password prompt for a key is happening because GoDaddy's sshd is telling the client that the pubkey auth method is allowed.  That's strange of course since it rejects all pubkey auth when the client attempts it.

Well, well, well, What a surprise.

 

It's working again.

 

It didn't work yesterday, and since then I made no changes whatsoever. But, today it works.

 

You might argue that it's something that I've done while trying to fix the problem. But, there's a second account that now works, and I had done nothing whatsoever with it.

 

So…

 

As you and I agreed, it was a problem with GoDaddy, not with us.

 

I'm a bit cross with GoDaddy's support team for categorically refusing to raise this to their higher-level support. I've wasted hours on this.

 

Please check if it's working with you now.

View solution in original post

Oh wow is that ever good news - mine is working as well - thanks!