Support

Akeeba Backup for WordPress

#39260 Trouble connecting to SFTP (SSH) from SiteGround to offsite server

Posted in ‘Akeeba Backup for WordPress’
This is a public ticket

Everybody will be able to see its contents. Do not include usernames, passwords or any other sensitive information.

Environment Information

WordPress version
6.2.2
PHP version
8.2.8
Akeeba Backup version
7.9.2

Latest post by nicholas on Monday, 31 July 2023 03:01 CDT

GJSchaller

I've been working on moving my backup scheme from plain old FTP to SFTP (over SSH).  So far, I have been able to:

  • Generate the keys on my home Mac
  • Install them on the server I will be FTPing to
    • After this was done, I disabled authentication using passwords
  • I am able to authenticate to the server from multiple points, using the keys in place of a password:
    • Home Mac via SSH
    • Home Mac via Cyberduck FTP
    • Remote / Office PC using PuttyFTP

So I know at this point SSH works with key authentication from multiple sources.  So far, so good.

For my site on SiteGround, I have done the following:

  • Created a folder outside of the web structure called "ssh"
  • Uploaded the public and private keys to this folder
  • Set permissions to 600 on both files
  • Created a new profile in Akeeba Backup to test the configuration
  • Set the Host, Port, Username, Password (used in the key), and the path to the Private and Public keys, as well as the Initial Directory

When I test the connection, I get the following message:

Cannot log in to SFTP server using key files [username:private_key_file:public_key_file:password] = 
(Username):/home/customer/www/madalynmckay.com/akeeba/ssh/id_rsa:/home/customer/www/madalynmckay.com/akeeba/ssh/id_rsa.pub:(Key Password)

I know the key works, because I can successfully use it from multiple other locations.  SSH2 is enabled in PHP, and I've checked and re-checked the path and permissions on the two Key files.  Any guidance as to why the keys may be rejected?

System Task
system
The ticket information has been edited by Geoffrey Schaller (GJSchaller).

nicholas
Akeeba Staff
Manager

If the private key is encrypted (as it should!), you will need to provide its password in the password field.

If your keys are using ECDSA (or ED25519) they might not work with some servers (I am not sure which version of libssh2 the SSH2 extension is compiled against on SiteGround's host). Try using an RSA key pair instead (using ssh-keygen -t rsa).

If that still doesn't help, you need to ask SiteGround if they are blocking outbound SSH / SFTP connections from their server. This is a common security practice to prevent compromised sites acting as "zombies" in a botnet, attacking other servers.

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

GJSchaller

I did use RSA - I didn't specify that in my original ticket, but yes (I did read the docs first! :-), it's a standard RSA 4096 bit key.  Password for the key is in the Password field.

I'll check with SiteGround, I wasn't sure if this was already a known issue with them or not.

nicholas
Akeeba Staff
Manager

I haven't used SiteGround in nearly 3 years. Back then, it wasn't a problem, but since then they have moved to a different hosting platform they  have built themselves. It's no longer cPanel. I don't know what server configuration settings they may have implemented.

FWIW, sites hosted on Rochen using cPanel and Akamai (formerly Linode) using bare Ubuntu Server can connect to a Synology NAS over SFTP just fine using RSA key files with an encrypted private key, PHP versions tested were 7.4, 8.0, 8.1, and 8.2. The last time I tested that was in May; the SFTP upload code has not changed in over 4 years. That's why I am suspecting something something something firewall on either side of the connection (web host or SFTP server).

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

GJSchaller

I opened a ticket with SiteGround, and they were able to confirm that from the command line on my server, they could successfully log into my remote server using the keys.  So we know that SSH in general works from SG to my server.

Tonight when I'm home, I will set up a key without a password, and see if that works.

GJSchaller

Got home and tested using a key without a password - same result:

Cannot log in to SFTP server using key files [username:private_key_file:public_key_file:password] = 
(Username):/home/customer/www/madalynmckay.com/akeeba/ssh/id_rsa:/home/customer/www/madalynmckay.com/akeeba/ssh/id_rsa.pub:(Key Password)

What's damning about this is I can connect fine from multiple other sources (home, my office, and from the SiteGround server itself), the only thing that seems to fail is the Akeeba Backup option.

Let me try from a different host, and see if the issue persists there, too - I can try from both a Joomla and a WP site on a different server / host.

GJSchaller

As a sanity test, I enabled Password-based authentication (not using keys) on my remote server, and tried to connect from the WP install on the SG server.  I was able to connect without issue.

The issue only exists for key-based authentication.

GJSchaller

OK, I finally figured it out!

EDIT: No, I was in the wrong window.  Still working on this.  The perils of having more than one WP site open in different tabs...

GJSchaller

Let me ask to be sure - on the SiteGround server, what should the permissions and owner / group be on the key files?

At the moment, they are 644 and owned by the user that the account is associated with:

baseos | [email protected]:~/www/madalynmckay.com/akeeba/ssh$ ls -l
total 8
-rw-r--r-- 1 u1157-ghdhaikgegzl u1157-ghdhaikgegzl 3454 Jul 28 00:39 madalynmckay
-rw-r--r-- 1 u1157-ghdhaikgegzl u1157-ghdhaikgegzl  757 Jul 28 00:39 madalynmckay.pub

nicholas
Akeeba Staff
Manager

Here is my configuration:

This is a very real configuration I am using to back up a WordPress site on our NAS. As you can see, the file is there just fine:

nicholas@AkeebaNAS:~$ ls -l BACKUPS/wordpress-*
-rwxrwxrwx+ 1 nicholas users 102116722 Jul 28 10:46 BACKUPS/wordpress-20230728-074642.jpa

The id_rsa and id_rsa.pub file are owned by the same user the web server runs under and have 0600 permissions. The id_rsa.pub file is not password-protected.

This feature works. 

Once again, you are trying to convince me that a feature I've been using for well over a decade on a daily basis for my own needs is not working. Do you really not understand that this will get you absolutely nowhere? You are wrong, my man. I cannot help you when you start from a position which does not reflect objective reality.

You already had so many problems with FTP(S), another feature I am using on a daily basis you were trying to convince me it doesn't work. This should have made you think “hm, is my server actually working the way I suppose it's working? Does my mental model of what is going on match objective reality, or am I chasing windmills?”. Is it possible that your server is rejecting connections for some reason e.g. it blacklisted your web server's IP address because your SFTP server is running fail2ban (or something similar) and you've already failed authenticating several times from the same IP address, triggering the IP autoban in fail2ban? Or maybe you are giving the wrong paths to the key files because you misunderstood what the absolute path to your web root is? Or providing a key file password when it's not needed / not providing the key file password when it's needed which would indeed lead to authentication errors? Or giving the wrong hostname / the hostname is a DynDNS the remote server has not yet seen the change of its IP because the host's caching DNS server has not updated the entries yet? Or you may be giving the wrong port because, like our NAS here, there's a different port for SFTP than the one used for SSH proper? Or you may be giving the wrong initial directory, just like our NAS here only accepts relative paths to the home folder instead of absolute paths because its chroot-jails the SFTP login? These are all very real issue I cannot possibly help with. These are configuration issues. There is nothing in Akeeba Backup's code to do with them. You can always follow the code; Akeeba Backup is Open Source. You will see how ridiculously simple the code on our side is. Everything is handled by the PHP SSH2 extension which, in its turn, outsources all the work to libssh2, the same library used by the sftp and ssh commands in the OpenSSH client package of your Linux distribution.

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

GJSchaller

Nicholas, I am not trying to fight with you or tell you you are wrong.  I get that all day from my own end users.  I wouldn't wish it on anyone else.

There's something I am missing, that I don't understand, and I am looking for help in trying to find it and fix it.  I know your code works, and I am not blaming you or your product.  I'm trying to narrow down what the mystery is, so we can fix it.

We know the code works.

We know that SSH works, both from other systems and from the SiteGround server.

We know that SSH from SiteGround to the remote server works when using a password instead of a SSH key.

We know the keys work on other systems.

The settings look correct, from what I can see, unless there's something I am not seeing in a path or permission.

It looks like for some reason Akeeba can't access the keys properly, or is otherwise failing when trying to use them.  That's what I am trying to narrow down.

I'll keep digging on the paths, and see if that makes a difference.  I suspect that's where the issue lies.

GJSchaller

I was able to get it to work.  The change I had to make was to use "Upload to Remote SFTP (SSH) server using cURL" instead of the option without cURL.  Once I did that, it worked flawlessly.

For documentation purposes, for anyone else using SiteGround, a screenshot of the settings are attached.  Note that I created the "Akeeba" directory and "ssh" directory under it myself, they are not defaulted on SiteGround.  (This is in keeping with the recommendation of keeping the working directory outside of the website itself).

Nicholas, thank you for your help and guidance.  That is not sarcastic or snark, that is me being honest.  I don't know why the non-cURL method would fail while cURL did, but you helped me eliminate pirces of the puzzle until that was one of the only variables left to test.

 

nicholas
Akeeba Staff
Manager

I am glad that it's resolved now!

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

Support Information

Working hours: We are open Monday to Friday, 9am to 7pm Cyprus timezone (EET / EEST). Support is provided by the same developers writing the software, all of which live in Europe. You can still file tickets outside of our working hours, but we cannot respond to them until we're back at the office.

Support policy: We would like to kindly inform you that when using our support you have already agreed to the Support Policy which is part of our Terms of Service. Thank you for your understanding and for helping us help you!