1

Is it possible to log and/or restrict the source user of an ssh login?

For example:

user1@server1 logs into server2 as user2 .

also, user3@server1 logs into server2 as user2 .

By "source user" I mean user1 or user3 above.

I would like to be able to track which session was initiated by user1@server1 and which session was initiated by user3@server1.

The purpose for this is multiple users may be using the user2 account to e.g. manage processes on server2. (I realize there are security implications of this but part of this question is assessing the extent of those).

As mentioned in the man page of sshd_config(5), sshd is capable of restricting access to a particular user using the AllowUsers config option in sshd_config.

AllowUsers

This keyword can be followed by a list of user name patterns, separated by spaces. If specified, login is allowed only for user names that match one of the patterns. Only user names are valid; a numerical user ID is not recognized. By default, login is allowed for all users. If the pattern takes the form USER@HOST then USER and HOST are separately checked, restricting logins to particular users from particular hosts. The allow/deny directives are processed in the following order: DenyUsers, AllowUsers, DenyGroup, and finally AllowGroups.

But the USER specified in the above man page seems to be describing the username on the TARGET machine (server2 in the example).

I tested this by setting the AllowUsers option to user2@server1 , and found I was still able to login from user1@server1 -> user2@server2.

Also, the log does not seem to show any source user.

This is the log /var/log/secure on RHEL6, after logging in from user1@server1 -> user2@server2

Nov 17 16:14:59 server2 sshd[28349]: Set /proc/self/oom_score_adj to 0

Nov 17 16:14:59 server2 sshd[28349]: Connection from 10.1.2.3 port 36508

Nov 17 16:14:59 server2 sshd[28349]: Found matching RSA key: aa:bb:cc:dd:ee:ff:gg:..

Nov 17 16:14:59 server2 sshd[28350]: Postponed publickey for user2 from 10.1.2.3 port 36508 ssh2

Nov 17 16:14:59 server2 sshd[28349]: Found matching RSA key: aa:bb:cc:dd:ee:ff:gg:..

Nov 17 16:14:59 server2 sshd[28349]: Accepted publickey for user2 from 10.1.2.3 port 36508 ssh2

Nov 17 16:14:59 server2 sshd[28349]: pam_unix(sshd:session): session opened for user user2 by (uid=0)

Nov 17 16:14:59 server2 sshd[28349]: User child is on pid 28351

So, is there any way to

(a) change the logging or behavior of sshd so that it will track the source user making the ssh connection?

(b) restrict sshd to restrict connections based on the source user?

1
  • Are the logins to server2 (as user2) being done with passwords or public keys? If the latter then look at the AUTHORIZED_KEYS FILE FORMAT and see if command or environment might help you.
    – icarus
    Commented Nov 17, 2016 at 8:09

1 Answer 1

1

The short answer is no, the server will accept any valid login from the server side perspective.

There are however some possible workarounds to achieve what you want. Test and see if the following will suit your needs.

Note that this might be sufficient for 'average' users and requires that you also control the clients. Experienced users will find a way to forge the CLIENTUSER variable used below.

By using the AcceptEnv directive in /etc/ssh/sshd_config you can accept for instance a variable called CLIENTUSER:

AcceptEnv CLIENTUSER

Next step is to force the users login command to a login shell like:

ForceCommand /bin/bash -l

Restart your sshd service and add the following to /etc/profile

if [ -z "$CLIENTUSER" ] || [ "$CLIENTUSER" != "user3" ] && [ ! -z "$SSH_CLIENT" ]
then
       echo 'Client logon not allowed'
       logout
fi

The above will logout every client who does not send the CLIENTUSER variable or sending the CLIENTUSER variable with another value than user3.

You can test this using the following client commandline:

$ ssh user2@host
Client logon not allowed

$ CLIENTUSER=user3 ssh -o "SendEnv CLIENTUSER" user2@host
user2@host $

As you can see the CLIENTUSER can easily be forged from the commandline. To prevent this you can add the following to the client `/etc/profile:

declare -r CLIENTUSER="$USER"

When the user tries to change the value of the CLIENTUSER variable he/she will receive the following error:

bash: CLIENTUSER: readonly variable
2
  • +1 especially for the short answer of no. I see what you mean for using the environment variables, though I got around the readonly variable by just using ksh or a new bash instance after the initial login on the source machine server1.
    – hilcharge
    Commented Nov 18, 2016 at 6:26
  • @hilcharge, you are right. Therefore I've put the note above the workaround.
    – Lambert
    Commented Nov 18, 2016 at 8:36

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .