SSH - logging - again

[Jeff Smee]

I've seen various ssh discussions on logging/keys but haven't seen an answer I'm looking for.

We have MANY servers that MANY S/A's log into with a shared account (say saadm).
The problem is we need to track which S/A actually logged into the server.
Is there a way to turn on some ssh logging that shows which key/phrase was used to login so we can tell which S/A actually logged in?
I've tried various debug levels, it seems to only show the IP the connection came from, not the key that was used to gain access to the shared account.

Jeff

[Steven E. Protter]

Shalom Jeff,

If the keyphrase were logged it would compromise the security of SSH.

SEP

[Jeff Smee]

I don't need to see the key phrase in the log, just which key it was tied to.

[skt_skt]

dont the SA login as themselves before switching to root?

[Jeff Smee]

All the S/As login with the same account (saadm). We have too many servers to change our passwords on every 30 days as directed by company policy which is why we use a shared account. But we need some way to track which S/A logged in with that account.

Ideas?
Anyone?

[Patrick Wallek]

>>....shared account. But we need some way to track which S/A logged in with that account.

A shared account and tracking who uses that account are generally mutually exclusive requirements.

This shows why this is a bad practice. When something happens, you will not know who actually caused the problem.

[Jeff Smee]

I agree, but we have hundreds of servers and no easy way to change our password on them every 30 days as directed. Hence the shared account with a password that never expires.

[Heironimus]

You could probably come up with a way to log it if you used forced commands. You'd want the shared account's .ssh directory and authorized_keys to be writable only by root. But in the end that's going to be a lot of effort just to rearrange the deck chairs on the Titanic.

You're already using public key auth, which is the big hurdle I've seen in the past because it moves so much control off of the server and on to the desktop. I don't see why you couldn't use personal accounts with locked passwords and key authentication instead of a shared account.

[Bill Hassell]

While changing passwords every month is a good idea (I work at a financial services company and it is a mandatory requirement), all that security is busted because of the shared accounts. Not only does it give a hacker easy access to many servers at once, a single user may mess up a login and lock out all users of that account. Our auditors would fail any system where the actual user could not be specifically identified.

Since you are using ssh, there is a much, much easier mechanism. Use public keys between the servers. You can setup a user account on 100 servers in a few seconds with scripting. Then create the public key on each server with ssh-keygen and pull a copy of the public key into a local authorized_keys file. Then copy that composite key file to all the servers under that user's login. Now each server can authenticate to every other server without using a password. This assumes that all SA's are trusted users.

Password changes can be automated with expect scripts or they can be eliminated with sshd config file settings (public key or nothing).

Other than that, the only data you can capture is the user's IP address. Use something like who -muR and grab the last field in /etc/profile like this:

IPADDR=$(who -muR | awk '{print $NF}')

Then write the userID and the IP address to a logfile. At least you'll have some idea what PC or system was used to login.

[Ralph Grothe]

Hi Jeff,

we were faced with a similar wish because we Unix admins share a common login account with RSA key authorization from which we su into the root account on a remote host.
The workaround I suggested then was based on the fact that the format of the authorized_keys file (as described in man sshd) allows for each key therein to be prepended by a comma separated list of options,
of which one is called "environment", and which may appear repeatedly.
This then would enable any admin user to place in his RSA public key file some environment variable such as e.g.

environment="SAADM_USER=jeff" 1024 35 121343091Ã 88297...

The admins' real user's public key should be distributed via cronjob script from your central admin login server to all the hosts they require access to, and appended to the ~saadm/.ssh/authorized_keys on each host.

However, to make the remote hosts' sshd processes honour user defined environment variables you must set PermitUserEnvironment to yes in the /etc/ssh/sshd_config file of those hosts and send their sshd a SIGHUP.

But beware, and read the warning in man sshd_config about possible perils with library preloading exploits if this per default disabled feature is enabled (see below)

Then to make use of the propagated admin's identity you could fiddle some rc script which would refer to SAADM_USER and which you place in ~saadm/.ssh/rc (read man sshd).

It must be said that this is no enforced security and can easily be subverted by the admin users.
It is only meant as one possible way to track the user's origin within a trusted community of admin peers.


PermitUserEnvironment
Specifies whether ~/.ssh/environment and environment= options in
~/.ssh/authorized_keys are processed by sshd. The default is "no".
Enabling environment processing may enable users to bypass access
restrictions in some configurations using mechanisms such as
LD_PRELOAD.