SSPI SSP backup fail with "Failed to create SFTP client. Error: error creating sftp connection to server. Error: sftp: sftpConnect: ssh: handshake failed: ssh: unable to authenticate, attempted methods [none publickey], no supported methods remain"

Products

• VMware vDefend Firewall

Issue/Introduction

SSP and SSPI use public key authentication (passwordless) when backups are executed.
However, during backup configuration, SSP/SSPI validates connectivity using a password-based login.

Because of this behavior:

• Backup configuration may succeed (password authentication works)

• Actual backup execution may fail if public key authentication fails

When the backup job fails with the error shown above, it indicates that SSP/SSPI could not authenticate to the SFTP server using the configured public key.

This article explains server-side checks that must be validated before configuring SFTP backups, especially on hardened Linux systems or systems using a non-standard home directory (not /home/<username>).

---

Symptoms

• Backup configuration succeeds

• Backup execution fails with:

ssh: unable to authenticate, attempted methods [none publickey]

• SFTP login with password works

• Public key authentication fails

---

Validation Steps (Before SSP/SSPI Configuration)

Refer to KB 410727 for general SFTP validation guidance.

Step 1: Test public key authentication manually

sftp -i <private_key> <username>@<sftp-server>

• If this succeeds and backup still fails → this is a different issue

• If this fails → continue with the steps below on the SFTP server

---

Step 2: Verify user home directory

 

getent passwd <username>

Example:

<username>:x:1008:1008:Usuario Backups NSX SFTP:/SFTP_backup/<username>:/bin/bash

Note the home directory path, especially if it is not under /home.

---

Step 3: Create and validate .ssh directory

mkdir -p /SFTP_backup/<username>/.ssh 
chmod 700 /SFTP_backup/<username>/.ssh 
chown <username>:<username> /SFTP_backup/<username>/.ssh

---

Step 4: Install the public key

cat /SFTP_backup/<username>/.ssh/id_rsa.pub >>  /SFTP_backup/<username>/.ssh/authorized_keys 
chmod 600 /SFTP_backup/<username>/.ssh/authorized_keys 
chown <username>:<username> /SFTP_backup/<username>/.ssh/authorized_keys

---

Step 5: Test local SSH/SFTP authentication

 

ssh -i /SFTP_backup/<username>/.ssh/id_rsa <username>@localhost

If it fails, run with debug:

ssh -vvv -i /SFTP_backup/<username>/.ssh/id_rsa <username>@localhost

Capture the output.

---

Step 6: Review SELinux audit logs

 

sudo ausearch -m avc -ts recent 
sudo tail -n 50 /var/log/audit/audit.log

Look for entries similar to:

avc: denied { read } for pid=xxxx comm="sshd" scontext=system_u:system_r:sshd_t tcontext=unconfined_u:object_r:default_t

Environment

• Red Hat–based Linux distributions with SELinux

• Non-standard user home directory

• SSP / SSPI versions 5.0 and 5.1

 

Cause

• SELinux is Enforcing

• User home directory is non-standard, for example:

   

  /SFTP_backup/<username>

• sshd is denied access to:

   

  .ssh/authorized_keys

• SSH silently falls back to password authentication

• Public key authentication fails during backup execution

Resolution

Step 1: Verify SSH daemon configuration

Check /etc/ssh/sshd_config:

PubkeyAuthentication yes

If it is set to no, update it and restart SSH:

sudo vi /etc/ssh/sshd_config sudo systemctl restart sshd

---

Step 2: Confirm public key rejection behavior

If debug output shows:

Offering public key: /SFTP_backup/<username>/.ssh/id_rsa 
receive packet: type 51 
Authentications that can continue: publickey,password

This means:

• The client offered the key

• The server rejected it

• SSH fell back to password authentication

---

Step 3: Fix SELinux context (PERMANENT FIX)

Install required utilities:

sudo yum install -y policycoreutils-python-utils

Label the .ssh directory correctly:

sudo semanage fcontext -a -t ssh_home_t \ "/SFTP_backup/<username>/.ssh(/.*)?"

Apply the labels:

sudo restorecon -Rv /SFTP_backup/<username>/.ssh

---

Step 4: Validate again

 

ssh -i /SFTP_backup/<username>/.ssh/id_rsa <username>@localhost

Authentication should succeed without a password.

 

Additional Information

 

• This is a Linux / SELinux configuration issue

• SSP/SSPI behavior is expected and correct

• Always validate public key authentication independently before configuring SFTP backups

• SELinux must explicitly allow sshd to read authorized_keys when using non-standard home directories

 

Related KB: 

• https://knowledge.broadcom.com/external/article?articleNumber=395284
• https://knowledge.broadcom.com/external/article?articleNumber=410727