I have a backup script that is failing for one user and was hoping some of you could point me in the right direction. I think I'm close, but worried to make any mistakes. The destination server is a jail SCP environment with 4 different users/home folders. The backup server is able to backup 3 of the 4 user/folders, but fails for one user of them each time. They all use the same SSH key and ref the same keyfile.

I'm not sure how this happened, but would like to see how I can get the user4 backing up again. I'm not sure how to do it without creating a new key or something like that, but don't want to break the other users. Basically, I just want to add the 4th user back in to the mix so he can use the key.

Here's whats happening.

chen-backup (backup server)
dest-server (destination server, SCP jailed, 4 home directories that are being backed up, each home directory has ownership from user1, user2, user3 and user4::user4 cannot backup)

Script runs on chen-backup, using rsync and a config file located in root/.ssh/chebackconfig

chbackconfig: Host dest-server Hostname dest-server.apples.com IdentityFile ~/.ssh/dest_backup_id

The SSH file for dest_backup_id is just a normal SSH file.

If I run ssh user4@dest-server I get prompted for a PW (that I don't know). If I run that for every other user, it just lets me in without any issues. If I go on to the destination server and change the PW for User4, will I have to create a new ssh-keygen? Also, if I change user4 PWs, will that break the keys that other systems are using to access dest server?

I guess I'm having a bit of a hard time fully understanding the keys and stuff.

1 Answer 1


if you manually explicitly specify the key in your test, like:

ssh -i ~/.ssh/dest_backup_id user4@dest-server

does that succeed?

You can use a -v with ssh to increase the verbosity of output, which can be helpful in isolating problems of this nature.

The first thing I would check is that user4 has a $HOME/.ssh/authorized_keys file, and that the public key is properly in there.

If the key is properly listed, make sure the permissions on the $HOME/.ssh directory and all files within are right. And $HOME as well.

chmod go-w /home/$USERNAME
chmod 700 /home/$USERNAME/.ssh
chmod 644 /home/$USERNAME/.ssh/authorized_keys

Also, make sure that the files are all owned by the right user:

chown -R $USERNAME /home/$USERNAME/.ssh

Also, it's a good idea to check logs. Typically, sshd logs to /var/log/auth.log, but you can verify that in the /etc/ssh/sshd_config file. Increase the verbosity of logging, if you need to, and restart ssh services.

In my experience, when ssh with a key isn't working as expected, though, it's a permissions issue. Maybe someone copied a file as root, and forgot to chown it, or maybe the permissions are too open on the private key, or something.

And, no, changing the password will not have any effect on the use of the ssh_keys. While a password and an ssh_key seem to perform similar functions in terms of allowing access to a system, they do it through very different mechanisms, and sshd really has no reliance on the password (although generally there must be an account, and it must not be locked out).

  • Thanks for the reply Tim! Most appreciated. I took your advice and made all the recommended changes and still kept failing. Very weird. I ended up making a copy of the private and renaming it and then referencing that private key in my config file. After that, I pulled my public from the dest server and then re-added the public key to the auth_keys. It worked! Wooohooo! E: Thanks again for the help! :)
    – saleetzo
    Mar 16, 2017 at 16:55
  • I am glad to hear you got it all working. Thanks for letting me know. :) Mar 16, 2017 at 17:18

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .