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 environment= option in authorized_keys file to set an environment variable, which the custom shell can then read.

Inside your .ssh/authorized_keys file, prepend each line with an environment variable set, like the following:

environment="REMOTEUSER=jrhacker" ssh-rsa .... environment="REMOTEUSER=jbloggs" ssh-rsa .... 

Then the custom shell, or any of the various rc scripts, can read the $REMOTEUSER variable and take the appropriate action.

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 LDPRELOAD. See the sshd_config documentation about PermitUserEnvironment.

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 environment= option in authorized_keys file to set an environment variable, which the custom shell can then read.

Inside your .ssh/authorized_keys file, prepend each line with an environment variable set, like the following:

environment="REMOTEUSER=jrhacker" ssh-rsa .... environment="REMOTEUSER=jbloggs" ssh-rsa .... 

Then the custom shell, or any of the various rc scripts, can read the $REMOTEUSER variable and take the appropriate action.

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 LDPRELOAD. See the sshd_config documentation about PermitUserEnvironment.

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 "environment=" option in authorized_keys file to set an environment variable, which the custom shell can then read.

Inside your .ssh/authorized_keys file, prepend each line with an environment variable set, like the following:

environment="REMOTEUSER=jrhacker" ssh-rsa .... environment="REMOTEUSER=jbloggs" ssh-rsa .... 

Then the custom shell, or any of the various rc scripts, can read the $REMOTEUSER variable and take the appropriate action.

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 LDPRELOAD. See the "sshd_config" documentation about "PermitUserEnvironment".

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 environment= option in authorized_keys file to set an environment variable, which the custom shell can then read.

Inside your .ssh/authorized_keys file, prepend each line with an environment variable set, like the following:

environment="REMOTEUSER=jrhacker" ssh-rsa .... environment="REMOTEUSER=jbloggs" ssh-rsa .... 

Then the custom shell, or any of the various rc scripts, can read the $REMOTEUSER variable and take the appropriate action.

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 LDPRELOAD. See the sshd_config documentation about PermitUserEnvironment.