Is it possible to find out which ssh key was used to access an account? I have an account on a server that I let several (trusted!) people have access to via ssh. I'd find it useful to be able to know who logged in and when. I have root access so I can look at the logs, but there doesn't seem to be anything there. Is there some configuration switch that will put some way of identifying the key in the logs?
If you go into the sshd config file (usually
...you can see something like this in the logs:
Some scripts for proper installation
There is a full useable method to track/log ssh connections by key with expention to username.
In addition to @Caleb 's anwer, I would like to share some little tricks there:
Nota: I'm working on Debian 6.0.
SSHD Log level
First ensuring that server config has sufficient logging level:
as root, this will set and active verbose loggin:
Or more precisely (this will modify sshd_config file only if needed and comment out old config):
Could be written:
or in a sed script:
Which could be run as:
Than for activating this:
Syslog: making fingerprints user readable
Now take fingerprints in user readable file:
This will print current sessions's fingerprint:
You can try this:
Suppose that users "joe" and "deb" have access to account "x". Then in account x's
Also in the wrapper script you can do anything you want, logging that joe's private key has been using
In addition to @F. Hauri answer, I prepare useful "LoggedIn prompt".
One additional file is optional ($HOME/.ssh/users):
This part should be pasted to
Somewhat similar to @user37161's answer. If the shared account is running a custom shell and the shell needs to know what user is there, then running the "wrapper" script might not be sufficient, since information there isn't passed into the custom shell except through methods that could cause race conditions.
Instead you can use the
Then the custom shell, or any of the various rc scripts, can read the
However, note that if you're using a standard shell, then the logged-in user is capable of modifying the file to thwart various things. Also, there is some risks in allowing users to set environment variables such as