Is SSH logging capabilities equivalent to su logging for private/public key authentication?

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.

Solution 1:

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.

Solution 2:

Another way would be to move authorized_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 a given account. It is quite common for each user account there is a respective group as well.

Using public/private keys is a way better method for controlling 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 employee left your company just remove their 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.

Solution 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   
...