Many times your managed server has only one user account into wich every admin logs in with his personal ssh-key. Most times it’s done with the root account, but that’s a nother topic 😉 As a result of this behaviour your are not able to see who logged in and what he or she did. A often suggested solution would be using different user account per person with only one ssh-key for authorization. This adds the „overhead“ of memorizing (except when you use ~/.ssh/config) and managing the sudoers file for all the accounts.
A more clever way is to use the SSH Environment feature in your authorized_keys file. First you need to enable this feature within the /etc/sshd/sshd_config file:
PermitUserEnvironment yes |
After that you can configure your ~/.ssh/authorized_keys file:
environment="SSH_USER=USER1" ssh-rsa AAAAfgds... environment="SSH_USER=USER2" ssh-rsa AAAAukde.. |
This sets the SSH_USER variable on Login in reference to the used ssh-key. NOw that this variable is updated on every login you can go on and work with it. First of to the logging of the actuall key that logs in. Under normal circumstances the ssh-dameon logs only the following information
sshd[21169]: Accepted publickey for user_account from 127.0.0.1 port 46416 ssh2
Additinally you could pass the SSH_USER content on to the syslog-dameon to log the actual user:
if [ "$SSH_USER" != "" ]; then logger -ip auth.notice -t sshd "Accepted publickey for $SSH_USER" fi |
This writes the following into the /var/log/auth (Debian) or /var/log/messages (RedHat) file:
sshd[21205]: Accepted publickey for USER1
Further more you can change the bash history file to a personal user file:
export HISTFILE="$HOME/.history_$SSH_USER" |
All together it looks like this:
if [ "$SSH_USER" != "" ]; then logger -ip auth.notice -t sshd "Accepted publickey for $SSH_USER" export HISTFILE="$HOME/.history_$SSH_USER" fi |
Puppet
To use the environment option within your ssh-key management in puppet you need the options field from the ssh_authorized_key function:
ssh_authorized_key { "${username}": key => "AAAAsdnvslibyLSBSDFbSIewe2131sadasd...", type => "ssh-rsa, name => "${username}", options => ["environment=\"SSH_USER=${username}\""], user => $user, ensure => "present", } |
Hope this helps, have fun!
p.s.: This is a guest post by Martin Mörner, a colleague from Aperto.
Hi,
I’m wondering to know where you put your small script for the logging ?
Is it in the /etc/profile ? /etc/ssh/sshrc, or another place ?
Thanks
You can use the the .bashrc or the more default .bash_profile
Pingback: Multiple SSH keys, one account | nimic.net
PermitUserEnvironment yes
^ is this not a massive security risk.
Enabling environment processing may enable users to
bypass access restrictions in some configurations using
mechanisms such as LD_PRELOAD.
This works fine and cannot be modified by users (files must be executable):
/etc/profile.d/ssh.csh:
if [ „$SSH_USER“ != „“ ]; then
logger -ip auth.notice -t sshd „Accepted publickey for $SSH_USER“
setenv HISTFILE „$HOME/.history_$SSH_USER“
fi
/etc/profile.d/ssh.sh:
if [ „$SSH_USER“ != „“ ]; then
logger -ip auth.notice -t sshd „Accepted publickey for $SSH_USER“
export HISTFILE=“$HOME/.bash_history_$SSH_USER“
fi
Bests
ah 2nd…
SSH_USER can make problems when ssh login to another server is made because this ENV is used as remote username when connecting.
=> Rename the variable to LC_SSH_USER and you have no problems… AND… it’s accepted by package default:
# grep LC /etc/ssh/sshd_config
AcceptEnv LANG LC_*
Bests 😉