Hi
I am trying to backup my servers to a new server via ssh but it fails.
The server doing the backup is running Debian 4.0, Webmin version 1.470, Virtualmin version 3.69 Pro The server backing up to via ssh is running Debian 5.0, Webmin version 1.480, Virtualmin version 3.69 Pro
This is the error I get
// Starting backup of 1 domains to /root/transfers on SSH server xxx.xxx.xxx.xxx ..
Failed to connect to SSH server : root@xxx.xxx.xxx.xxx's password: Permission denied, please try again. root@xxx.xxx.xxx.xxx's password: Permission denied, please try again. root@xxx.xxx.xxx.xxx's password: Permission denied (publickey,password). lost connection
Backup failed! See the progress output above for the reason why. //
I can transfer using scp without a problem.
Comments
Submitted by JamieCameron on Sun, 06/28/2009 - 22:15 Comment #1
Sounds like you may not have configured Virtualmin to use the right password for root.
Check what gets logged to /var/log/secure or /var/log/authlog on the destination system - the reason why the backup is denied may be there.
Submitted by xkeywee on Sun, 06/28/2009 - 22:23 Comment #2
Thanks
You have pointed me in the right direct "authlog" on the destination server.
Jun 29 13:19:29 sv15 sshd[17077]: reverse mapping checking getaddrinfo for xx-xxx-xx-xx.bitstream.orcon.net.nz [xx.xxx.xx.xx] failed - POSSIBLE BREAK-IN ATTEMPT! Jun 29 13:19:29 sv15 sshd[17077]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=xx.xxx.xx.xx user=root Jun 29 13:19:31 sv15 sshd[17077]: Failed password for root from xx.xxx.xx.xx port 33761 ssh2 Jun 29 13:19:32 sv15 sshd[17077]: Failed password for root from xx.xxx.xx.xx port 33761 ssh2 Jun 29 13:19:35 sv15 sshd[17077]: Failed password for root from xx.xxx.xx.xx port 33761 ssh2 Jun 29 13:19:35 sv15 sshd[17077]: PAM 2 more authentication failures; logname= uid=0 euid=0 tty=ssh ruser= rhost=xx.xxx.xx.xx user=root Jun 29 13:19:35 sv15 sshd[17080]: reverse mapping checking getaddrinfo for xx-xxx-xx-xx.bitstream.orcon.net.nz [xx.xxx.xx.xx] failed - POSSIBLE BREAK-IN ATTEMPT! Jun 29 13:19:35 sv15 sshd[17080]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=xx.xxx.xx.xx user=root Jun 29 13:19:37 sv15 sshd[17080]: Failed password for root from xx.xxx.xx.xx port 33762 ssh2 Jun 29 13:19:39 sv15 sshd[17080]: Failed password for root from xx.xxx.xx.xx port 33762 ssh2 Jun 29 13:19:42 sv15 sshd[17080]: Failed password for root from xx.xxx.xx.xx port 33762 ssh2 Jun 29 13:19:42 sv15 sshd[17080]: PAM 2 more authentication failures; logname= uid=0 euid=0 tty=ssh ruser= rhost=xx.xxx.xx.xx user=root
Looks like the reverse DNS is wrong and causing the issue.
I am moving my server to a new location as this is the sort of things that keep happening with this location.
Submitted by JamieCameron on Sun, 06/28/2009 - 23:14 Comment #3
Ok .. so if you fix the reverse mapping (or configure SSHd on the remote system to stop checking it), does the SSH backup work now?
Submitted by xkeywee on Tue, 06/30/2009 - 05:50 Comment #4
I have had to stop reverse checking (added UseDNS no in sshd_config) as we have been unable to get the reverse mapping fixed.
I now get the following when doing the server
Failed to connect to SSH server : root@xxx.xxx.xxx.xxx's password: Permission denied, please try again. root@xxx.xxx.xxx.xxx's password: Permission denied, please try again. root@xxx.xxx.xxx.xxx's password: Permission denied (publickey,password). lost connection
and the destination server auth.log
Jun 30 20:42:47 sv15 sshd[11855]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=60.234.78.35 user=root Jun 30 20:42:49 sv15 sshd[11855]: Failed password for root from xxx.xxx.xxx.xxx port 35361 ssh2 Jun 30 20:42:51 sv15 sshd[11855]: Failed password for root from xxx.xxx.xxx.xxx port 35361 ssh2 Jun 30 20:42:54 sv15 sshd[11855]: Failed password for root from xxx.xxx.xxx.xxx port 35361 ssh2 Jun 30 20:42:54 sv15 sshd[11855]: PAM 2 more authentication failures; logname= uid=0 euid=0 tty=ssh ruser= rhost=xxx.xxx.xxx.xxx user=root Jun 30 20:42:54 sv15 sshd[11858]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=xxx.xxx.xxx.xxx user=root Jun 30 20:42:56 sv15 sshd[11858]: Failed password for root from xxx.xxx.xxx.xxx port 35369 ssh2 Jun 30 20:42:58 sv15 sshd[11858]: Failed password for root from xxx.xxx.xxx.xxx port 35369 ssh2 Jun 30 20:43:00 sv15 sshd[11858]: Failed password for root from xxx.xxx.xxx.xxx port 35369 ssh2 Jun 30 20:43:00 sv15 sshd[11858]: PAM 2 more authentication failures; logname= uid=0 euid=0 tty=ssh ruser= rhost=xxx.xxx.xxx.xxx user=root
Submitted by JamieCameron on Tue, 06/30/2009 - 09:19 Comment #5
So it looks like the password Virtualmin is trying to use to login to the remote server is wrong.
Are you sure it is set correctly on the backup form? Also, does it contain any special characters of any kind?
Submitted by xkeywee on Tue, 06/30/2009 - 16:01 Comment #6
The password contains letters, numbers and the % symbol
Will the % be causing the problem?
Submitted by JamieCameron on Tue, 06/30/2009 - 16:23 Comment #7
Could be .. you might want to try with a different password, if possible.
Submitted by JamieCameron on Tue, 06/30/2009 - 16:24 Comment #8
Also, check that the other server allows SSH logins by root .. sometimes this is disabled by default.
Submitted by xkeywee on Tue, 06/30/2009 - 20:16 Comment #9
I created another user with a password containing alphanumeric characters only and it worked fine, it is obviously the % in the other password that is causing the issue.
Thanks for your help
Submitted by JamieCameron on Wed, 07/01/2009 - 00:28 Comment #10
Interesting .. although a % really should work. If you change the other user's password to contain a %, do the backups work?
Submitted by xkeywee on Wed, 07/01/2009 - 01:22 Comment #11
I changed the new user to use a password with a % in it and it wouldn't work either.
Submitted by JamieCameron on Wed, 07/01/2009 - 12:37 Comment #12
Wow .. so it looks like the tar command doesn't like passwords containing %. Sadly there isn't much Webmin can do about this, as it doesn't make the SSH connection directly..
So the 'fix' is to use a different password :-(
Submitted by Issues on Wed, 07/15/2009 - 13:18 Comment #13
Automatically closed -- issue fixed for 2 weeks with no activity.