Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

Here at work, we have a non-root shared login account on UNIX that is used to admin a particular application. The policy is to not allow direct logins to the shared account; you must login as yourself and use the "su" command to change over to the shared account. This is for logging/security purposes.

I've started using SSH public/private key authentication with an agent to allow me to enter my password once a day and let the agent forwarding eliminate the password prompts for the rest of the day. It is really nice.

However, some systems are locked down so I really have to use the "su" command to get to the shared account. Arg! Back to entering passwords all the time!

Is there enough info logged with SSH public/private key authentication such that I could have a reasonable chance of requesting a policy change to allow remote logins to a shared account if public/private keys are used?

I had an admin look in /var/log/secure and it just says that a public key was accepted for a user account from a particular IP address. It didn't say who's public key it was, or who's private key did the authentication.

share|improve this question

3 Answers 3

SSH public/private key authentication is separate from the host authentication. You are out of luck here. You could request though that members of particular group be allowed to run certain administrative commands via sudo without password - like the example bellow allows users in the secretaries group to manage accounts:


# file: /etc/sudoers
...
%secretaries    ALL= NOPASSWD: /usr/bin/adduser, /usr/bin/rmuser   
...
share|improve this answer
    
Second this.. it is much, much easier to audit when you use SUDO.. you can see user joe typed "sudo appname -options" which is much simpler than seeing root typed "appname -options" and then have to go reconcile who all was logged in as root at that time. –  Brian Apr 4 '11 at 3:06
    
OK, that helps. However, some of our tasks are to start and stop daemon processes. Will sudo allow us to run the "start" and "stop" scripts as the shared group username? (that is non-root) We want the processes to be owned by the shared account username we setup. –  David I. Jun 9 '11 at 20:24
    
Yes, the -u option lets you do that, see the manual sudo.ws/sudo/man/1.8.1/sudo.man.html –  Nikolai N Fetissov Jun 10 '11 at 1:27

There are many levels of logging available through the sshd_config file. See the man page and look for LogLevel. The default level is INFO but it's trivially easy to bump it up to VERBOSE or even one of the DEBUG# levels.

Additionally, you should explore sudo as an alternative to su. A full discussion of the benefits of sudo would be a question of its own. But I can say that with sudo you can tailor how often you have to enter your password, which commands may be run, etc., all controllable through the sudoers config file.

share|improve this answer
    
Voted up for suggesting a sudo replacement. –  Matt Simmons May 28 '09 at 19:26

Another way would be to move autorhized_keys outside of the user's scope (for example to /etc/ssh/authorized_keys) so that only sysadmins would control which public keys can be used to log to given accounts.

We used to change the AuthorizedKeysFile directive in sshd_config to something like the following.

AuthorizedKeysFile /etc/ssh/authorized_keys/%u

Then create and populate /etc/ssh/authorized_keys directory with files for each user that's supposed to be able to login, making sure root file is readable/writable only to root and other files readable by an appropriate user, like this:

-rw-------  1 root root    1,7K 2008-05-14 14:38 root
-rw-r-----  1 root john     224 2008-11-18 13:15 john

Each file contain a set of public keys that will be allowed to log into given account. It is quite common that for each user account there is a respective group as well.

IMO using public/private keys is a way better method for controling remote user access. You don't have to change the password every month (you don't have to set it either), and don't have to change it just because an employer left your company (just remove his public key). And of course with SSH options (http://www.openbsd.org/cgi-bin/man.cgi?query=sshd&sektion=8#SSHRC) you can fine-grain to what and from where a given user might have an access.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.