The FreeBSD Diary
Providing practical examples since 1998If you buy from Amazon USA, please support us by using this link.
ssh - authorized keys and chmod 5 April 2000
|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
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 firstname.lastname@example.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: 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.