Dave, In our backup environment the backup user needs a shell and home dir for ssh keys as you described. The passwd is disabled and ssh keys are required. We also limit access to the backup user to specific source ip addresses like the backup server.
We also use ssh wrappers. Using the command argument in the ssh keys file you can have a script check what command is being run. The backup user only needs to accept rsync so that is what we are validating. If any other command is run or if a shell is requested the connection is denied. This is a link to the explanation of our backup methodology and at the bottom is an example of the rsync wrapper script. Rsync remote files to backup server http://calomel.org/backup_server_rsync.html As Nick explained, if you have untrustworthy admins any setup can be compromised. I suggest writing a script to execute a simple command like "ls" using the backup user. If "ls" is successful, the wrapper in not working. If anyone has any other recommendations I would be interested in hearing about them. There is always room for improvement. -- Calomel @ http://calomel.org Open Source Research and Reference On Tue, Nov 13, 2007 at 10:17:07PM -0500, Nick Holland wrote: >Dave Harrison wrote: >> Hi all, >> >> I've been wondering how to deal with this particular issue for quite >> some time now, and I can't find any references to "the right way"(TM) >> to handle it. >> >> I always prefer to run automated tasks as limited privilege users on >> my OpenBSD hosts - such as tasks that pull files across from other >> hosts, and other such nightly tasks. To make this work the drop priv >> user account needs a shell and a home dir (for SSH keys etc), and has >> no need for a password. However this causes the /etc/security script >> to generate warnings every night such as, >> >> """ >> Login nightlysync is off but still has a valid shell and alternate >> access files in home directory are still readable. >> """ >> >> The tasks that this user performs are scheduled through cron. >> >> Is there a better way for me to be setting up these kinds of tasks so >> that this warning doesn't get raised ? Or is the warning spurious ? > >here's my way of squishing those messages: >* create the user, give it a non-trivial (but easy to type) PW. This > is often useful in the development stage anyway. Don't use a trivial > password in case you forget to do the next step... >* When ready to kill the PW, rather than clearing it, by putting a > few repeated chars in the encrypted PW string, for example, "----", > using vipw. > >You now have an account that technically has a PW, but it is unlikely >anyone will find something that hashes to the string you created. The >string probably has the wrong number of characters anyway. Daily is >happy, you are happy, and no one can log in. > >...you hope. > >Here's a problem. You may want to be aware of "funny" accounts on >your system. Let's say you "kill" a password as I suggested, then >your evil co-administrator, Bob, decides he wants to keep having >access to this machine after he quits. So, he quietly does a chpass >on that account, then puts in his resignation. You run around and >delete all his accounts, and think, "Job done". > >Bob now logs into that account, and uses the ssh key he also dropped >in place to get wherever he wanted to go (assuming a little pre- >planning, of course). > >So, you might WANT to have as part of your daily routine verifying >that you have X insecurity reports, and that they are there for the >reasons you expect. > >'course, that's hardly the only attack vector. If seeing >"Insecurity Report" freaks your boss out, you might find it safer >to eliminate the report ("Windows never tells me how insecure it >is, so it must be better!). Otherwise, treat it as just part of >your daily mails. > >(Interestingly, your subject line auto-filed your message into my >"Insecurity Reports" folder, and it rather concerned me that a new >message suddenly arrived there. :) > >Nick.
