An old (and out of date) Ubuntu 16 installation used to connect to an even older and more out of date cloud server through passwordless ssh and visa-versa. This is needed for automation scripts to synchronize folders from remote server to the cloud.

The cloud server is being de-resed so we are setting up an new cloud server, jumping from Ubuntu 14 to Ubuntu 18. We started with a fresh install of 18.04.3 and simply copied our data over.

The versions of ssh are:

Ubuntu Server 16.04.4 LTS OpenSSH_7.2p2 Ubuntu-4ubuntu2.4, OpenSSL 1.0.2g 1 Mar 2016 and Ubuntu Server 18.04.3 LTS OpenSSH_7.6p1 Ubuntu-4ubuntu0.3, OpenSSL 1.0.2n 7 Dec 2017

I can't get an account on the old remote machine to login to the new cloud machine as a different user without a password prompt. But the opposite works.

I have used ssh-copy-id to update the user on the cloud server's authorized_keys file. The odd thing is: it always updates even though the file already has the key. If I run the copy-id command over and over, it keeps adding the key to authorized_keys. I wonder if it's related to the fact that the home directories aren't in /home.

I have tried setting the permissions of the cloud server's .ssh directory to 700 and the authorized_keys file to 600. I have created an authorized_keys2 file that matches authorized_keys.

When the remote system user tries to ssh to the cloud server user it still prompts for a password.

Anyone have any ideas?

Thanks much.

Update ssh -v has this at the end...

debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/USER/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /home/USER/.ssh/id_dsa
debug1: Trying private key: /home/USER/.ssh/id_ecdsa
debug1: Trying private key: /home/USER/.ssh/id_ed25519
debug1: Next authentication method: password
  • Have you installed the new server with an encrypted home directory? We've got two identical setups (except for the encrypted home), and the encrypted one always asks for the password because the daemon can't decrypt the home dir where the keys are stored. Search on askubuntu how to move the keys from the home dir and try if it works. – Velkan Aug 30 '19 at 7:44
  • That's a great idea! I checked and there is no encryption. But it does seem like something like that. I noticed in ssh -vvv the client for the direction that works shows the key it is sending, where as the direction that fails the client shows nothing except the location of the file. It really does look like some access issue. – Raydude Aug 30 '19 at 16:48
  • I looked in /var/log/auth.log on the server and found something really interesting: "rexec line 31: Deprecated option RSAAuthentication." I'll research this, perhaps the latest sshd stopped accepting RSA? – Raydude Aug 30 '19 at 17:00

I found the issue. It was related to the home directories as I thought.

The issue is: the users home directory group must be the same as the owner. I had changed it to enable the users to rsync to each other's directories. That is a no no for openssh's sshd.

Here is the error message I got in /var/log/auth.log:

Authentication refused: bad ownership or modes for directory /wtecData/sjprod

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.