Migration stuck

Hi
I am using the ISPConfig migration tool to try and migrate an ISPConfig 3 installation from a very old Ubuntu 14.04 VPS to a new 22.04 linode.
I have installed ISPConfig on the destination and setup remote user (following the guide here@: https://www.howtoforge.com/tutorial...-confixx-plesk-to-ispconfig-31-single-server/ ).
running migrate (dry run) on the source is getting stuck in a loop repeating:

What is the ip for the target web server to connect via SSH? [109.74.202.98]:
What is the SSH port? [22]:
Now we transfer the key to the target server.
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
[email protected]'s password:
Number of key(s) added: 1
Now try logging into the machine, with: "ssh -p '22' -o 'StrictHostKeyChecking=no' -o 'ConnectTimeout=5' '[email protected]'"
and check to make sure that only the key(s) you wanted were added.

...any ideas how I can move it on?

 

Did the ssh-copy-id work? Can you login to the remote host without a password now?

 

SSH as root - No actually I can't - what might be causing this to fail? and can I bypass the issue?

 

BTW I did enable root login in ssh (and I can login with password)

 

In the guide you posted there are two possible solutions mentioned:

You could temporiarily enable SSH root login on the remote host.

 

I was trying the second route - I'll have a go at the first... Thanks

 

Just set "PermitRootLogin yes" in the sshd config on the remote system and try to login with root@remoteserver from the other system. This should work

 

Yeah that has been in place all along.
Manually used ssh-copy-id [email protected] to copy key to destination and it is appearing in .ssh/authorized_keys there
but still can't login without password
THe sshd_config authorization on destination now (I changed PubkeyAuthentication to yes and uncommmented AuthorizedKeysFile line) reads:

Authentication:
#LoginGraceTime 2m PermitRootLogin yes #StrictModes yes #MaxAuthTries 6 #MaxSessions 10
PubkeyAuthentication yes
Expect .ssh/authorized_keys2 to be disregarded by default in future.
AuthorizedKeysFile .ssh/authorized_keys .ssh/authorized_keys2
#AuthorizedPrincipalsFile none
#AuthorizedKeysCommand none #AuthorizedKeysCommandUser nobody
For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
#HostbasedAuthentication no
Change to yes if you don't trust ~/.ssh/known_hosts for
HostbasedAuthentication
#IgnoreUserKnownHosts no
Don't read the user's ~/.rhosts and ~/.shosts files
#IgnoreRhosts yes

 

You don't need key-based authentification at all. Just enable root login via PermitRootLogin as you already have and try to login to the remote host with root@remoteserverip and the password. If that is working you can use the migration toolkit

Just remember to disable root login after the migration, for obvious security reasons

 

My understanding is that migrate doesn't just use password authentification, it just uses it to setup the passwordless ssh (don't know why!) - from the guide:
'...Or allow root access via ssh to the target by password (temporarily). The Migration Tool will then call ssh-keygen and ssh-copy-id for you...'
I tried it with just password authentification several times and it falls over when it copies the key and (presumably) tries to establish a connection... starts looping back to 'What is the ip for the target web server to connect via SSH?'
I ended up with loads of copies of the key in authorized_keys on destination....
I have now run out of ideas...

 

That is true. But i do not understand why it shouldn't work.

So just to make this clear:

You generate a keypair on the Source with (Don't specify a password for the key itself just hit enter):
ssh-keygen -t rsa -b 2048

Then you use this command on the Source system:
ssh-copy-id root@remote_host

Make sure you are logged in with the user you are running the migration toolkit with!

After that connect to the remote system:
ssh -vvv root@remote_host

May provide the output of that verbose ssh connect command to see what might cause the issue

 

That is a good hint indeed. The ssh -vvv option will confirm this if thats the case

 

Nice one Til - that solved it!
Many thanks

 

...and thanks for your help @pyte!