Apr 052000

ssh – authorized keys and chmod

Regular readers (aren’t you all?) will remember the article (How to copy files around without anyone seeing them) where I used scp to copy files from one box to another.  The solution involved the use of ~/.ssh/authorized_keys.  This article shows how changing the permission on a directory can break this solution.

The problem I wanted to solve

I was in the process of looking at the files which were copied from one box to another box using the process described in the original article (How to copy files around without anyone seeing them).   I using my normal login and not the owner of the directory.  I wanted to create a directory and extract some of the files from one of the tarballs into that directory.

The first solution

My first solution was to add myself to the group which owned the directory.  So I used su to become root and modified /etc/group to include my login in the group.

Then I logged out of my root connection and tried to create a directory in /home/secretuser.   I failed.  Hmmm, so I checked the permissions on /home/secretuser.   They were:

drwxr-xr-x 3 secretuser secretuser 1024 Apr 5 19:19 secretuser

The above permissions are 755, which is not group writable.  So I changed them to 775 by doing this:

chmod 775 /home/secretuser

Which made the permissions look like this

drwxrwxr-x 3 secretuser secretuser 1024 Apr 5 19:19 secretuser

I was then able to create a directory, extract my files, and get on with my life.   Sure.

The first problem

After I did the extract, looked around, and deleted some files, I decided it was time to do another backup.  So I ssh’d to the other box and invoked the backup script.   I was rather rudely greeted with the following:
$ sh dump_database.sh
tar: Removing leading / from absolute path names in the archive
secretuser@othersite.org's password:

Needless to say I was confused.  Umm, the whole point of the authorized_keys file is to avoid the use of passwords.  Now it wants a password.

My first guess was that the authorized key was wrong.  So I made sure they were the same.  They were.

Then I did what I should have done in the first place.  Yes, I checked the error logs.  That’s the FIRST thing anyone should do when they encounter a problem. After all, that’s what the error logs are for.  Here is what I found in /var/log/auth.log:

Apr  5 19:16:27 ducky sshd[31973]: RSA authentication refused
                for secretuser: bad ownership or modes for

OH!  Permissions.  Well, dah.  I changed them back and the authorized keys problem went away.

OK. so this solution isn’t perfect.

How did I accomplish what I set out to do?  I copied the file from /home/secretuser to /home/dan and worked on it there.

As always, if you can provide more information on this (or indeed any other topic), please add your comments.