Transfer Virtual Servers not working

I was eager to try the Transfer Virtual Servers feature, but it won't work. The first problem I found was the feature won't use anything other then port 22, I tried hostname:### and that didn't work.

I changed my SSH port back to 22 for testing, and I got an error message

Failed to transfer server : Failed to contact Virtualmin on destination system : root@destination.host.tld's password: Permission denied, please try again. root@destination.host.tld's password: Permission denied, please try again. root@destination.host.tld's password: Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password).

I am able to login from the command line ssh root@destination.host.tld ... same password ... works.

Status: 
Active

Comments

Using a SSH key I was able to get it to work, the password was definitely correct, I copied and pasted it into the SSH session as well as Webmin/Virtualmin.

So was the cause of the problem actually that your SSH password wasn't accepted?

If so, does it contain any special characters like @ or : ?

Lower case, upper case, and numbers, nothing else. Tried it from the command line and it worked. Error from the Transfer window.

I am testing on another machine to see if I can reproduce.

So you were able to do a transfer using the virtualmin transfer-domain shell API command?

On a second system I was unable to use password authentication to transfer, same error. I was able to successfully transfer using a SSH key again.

Failed to transfer server : Failed to contact Virtualmin on destination system : root@destination.host.tld's password: Permission denied, please try again. root@destination.host.tld's password: Permission denied, please try again. root@destination.host.tld's password: Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password).

I looked for that in the virtualmin command but there was nothing there, also

[root@destination ~]# virtualmin transfer-domain
Command transfer-domain.pl was not found

You might want to check the logs on the destination system to see why the password SSH login was rejected.

Usually something is logged to /var/log/secure or /var/log/auth.log

Feb 17 22:21:32 destination sshd[11261]: Failed password for root from source-ip port 47986 ssh2

The password was not incorrect, I copied and pasted it into the ssh window and was able to login. I am unable to get any password to work.

tpnsolutions's picture
Submitted by tpnsolutions on Tue, 02/18/2014 - 17:30

Hi,

Just an FYI, I was able to successfully utilize the transfer feature via the web on CentOS 5, however I had to delete and re-create the DNS settings as they didn't seem to update correctly.

Also, in the wizard when you tell it to "Disable the website" upon completion, it didn't seem to do this.

As for using my "root" password, that only required me to disable a setting inside my SSH config which I had set to disallow root password logins over SSH, though other than that the actual transfer ran without issue.

BTW: "virtualmin transfer-domain" also resulted in "command transfer-domain.pl not found" nor was it listed in the help context when you run "virtualmin" without a command.

-Peter

I double checked my SSH config when I initially had the problem, password login is working fine. I was able to login via SSH with the same password pasted from the clipboard.

The destination system is running CentOS 6 x86_64, and the two sources I tried are also CentOS 6 one is i386 and the other is x86_64.

Can you perform a regular SSH backup using Virtualmin to the same remote system you are trying to transfer to? The transfer does something similar.

Just noticed your post. The SSH backup option using the backup in VM does not work for me either. Looks like a buggggg. See my post for information. Tried many options. Removed host keys, connected using ssh for accepting the new host keys. and more.....

Does it still fail if you use the default SSH port?

How about if you backup to another user account via SSH, who just has an alpha-numeric password?

I'm trying to figure out what is triggering this, as SSH backups in general have been pretty well tested and are heavily used.

Hi,

Same issue here, I believe its a port problem and might be expecting port 22. I had it to work miraculously on version 4.05 and it was really cool, all dns record properly modified!

Probably a bug to be fixed next version.

Regards,