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.
secretuser:*:2960:dan
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 '/home/secretuser/'.
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.