rodrigop
Dec 16, 2022 05:08 PM
rodrigop
Dec 16, 2022 05:32 PM
rodrigop
Dec 16, 2022 06:11 PM
Hi,
I upgraded from 6.7 to 7.0.3 latest. Backup configuration was wiped out during the upgrade, so I had to reconfigure that
While reconfiguring, I noticed that SCP is no longer supported, but SFTP is available to use, fine.
I can not use regular password authentication, any connection to machines over SSH transport (this means SSH, SCP, SFTP) needs to use password-less authentication with public/private key pairs.
So, just I like I used to do with new 6.x appliances, I logged in to the appliance root shell and generated a RSA SSH key for the root user. The public key of the root user was then added to the authorized keys of the backup user in the backups server. I then test a simple connection from the root shell, the host key is added to ssh's known_hosts, and all should be good.
However, In the scheduled backup configuration wizard, when It tests the connection, the logs show:
2022-12-16T16:18:25 PM UTC [25505]ERROR:plugins.FtpStorageIOLib:sftp cmd failed. RC: 67, Err: curl: (67) Authentication failure
, Cmd: ['/usr/bin/curl', '--fail', '-u', 'backupuser:****', '--connect-timeout', '120', '--ssl-reqd', '-k', '--noproxy', '*', '--silent', '--show-error', '--list-only', 'sftp://backupshost/location/']
However, if I run the curl command directly in the root shell, it works fine (the password doesn't really matter, can be random, because the ssh public key will be used as credential):
/usr/bin/curl --fail -u backupuser:whatever --connect-timeout 120 --ssl-reqd -k --noproxy * --silent --show-error --list-only sftp://backupshost/location
.
..
vCenter
And this looks perfectly fine for me! BTW, the exit code of that command is 0, not 67.
I cannot understand where that Authentication Failure in the logs comes from.
Any hints?
Thanks in advance!
Looks like the curl process is launched by a Python process:
│ ├─python /usr/lib/applmgmt/base/bin/vherdrunner /usr/lib/applmgmt/transport/bin/serve
│ │ ├─curl --fail
And probably when launched this way it doesn't look into /root/.ssh.
check the environment of both processes, there's no $HOME set, so it's no wonder that it doesn't look into /root/.ssh, neither will it try to use /root/.curlrc
Well I was able to workaround this by replacing /usr/bin/curl with a shell wrapper that injects key location as one of the curl arguments.
But this is such a dirty hack, now I feel like I should take a shower! Not to mention that with every update of the curl package will require to place the wrapper again.
If anyone has a better solution for this, please let me know!
For VMware, this is a security regression that should be addressed!
Terms of Use
