transfer information about the connection from ssh client to ssh server

Question

suppose I have the following ssh session:

userA@boxA -> userB@boxB -> userC@boxC

now, from boxC, as userC, I would like to have the information that the ssh connection came from userB@boxB which in turn came from userA@boxA.

now I have the following ssh session along with the first ssh session:

userD@boxD -> userB@boxB

from boxB, as userB, I would like to have the information that the connection came from userD@boxD and that there is a second ssh session coming from userA@boxA.

is this information available and accessible as user? is it even available at all?

if not, is there any "easy" way to make this information available? with easy I mean without hacking and recompiling sshd, and without having to have root access on the machines.

Answer 1

The official way to send environment variables from client to server is through SendEnv and AcceptEnv. The problem is that you need root access on the server to configure AcceptEnv. Most servers are configured to accept no or only a few predetermined variables.

I found two tricks to send environment variables from client to server, both work without needing root access on the server.

trick one:

ssh -t server SSH_ORIGIN=$USERNAME@$HOSTNAME bash

this will connect to server and then execute the command SSH_ORIGIN=$USERNAME@$HOSTNAME bash, with $USERNAME and $HOSTNAME already replaced on the client side. then, on the server side, you can further process the information contained in the variable SSH_ORIGIN.

the -t is needed otherwise bash will be started on the server without a tty (try it, you will see).

a slight modification will allow to pass the information transitively down a longer ssh chain.

ssh -t server SSH_ORIGIN=$USERNAME@$HOSTNAME:$SSH_ORIGIN bash

discussion:

• bash is started as an interactive non-login shell (.profile is not read).
• bash is run twice (.bashrc is read twice). once by sshd and once by the user command.
• it will always start bash, ignoring your default shell on the server.

trick two:

first you must generate a ssh key and transfer that to ~/.ssh/authorized_keys on the server. then prepend the line with command="$SHELL". see the sshd manpage for more information on this.

connect to ssh server using the command:

ssh -t server SSH_ORIGIN=$USERNAME@$HOSTNAME

this will connect to the server but this time the variable assignment is not executed. instead, the string is stored in the environment variable $SSH_ORIGINAL_COMMAND. then the command provided in ~/.ssh/authorized_keys is executed. once you are in the shell you can process the information contained in $SSH_ORIGINAL_COMMAND.

as above, you can make this transitive:

ssh -t server SSH_ORIGIN=$USERNAME@$HOSTNAME:$SSH_ORIGIN

discussion:

• it will start the default shell on the server.
• it will always start the default shell on the server. any command you give to the ssh command will be ignored and stored in $SSH_ORIGINAL_COMMAND. if you want to execute a command over ssh you can use a different ssh key or have your shell init file to detect and execute $SSH_ORIGINAL_COMMAND.

Answer 2

The command who tells you who else is logged in now on the same machine and where they logged in from. The command last gives the same information for past sessions. Depending on machine configuration and login methods, the information may not always be complete, up-to-date or available to non-root users.

In your A@A->B@B->C@C scenario, it is impossible from machine C to know that B@B was logged into B via an ssh session from A. In the 1980s, when everybody trusted everybody, you could have tried finger or ident, but these days machine B is unlikely to be even running a finger or ident daemon.

Answer 3

I think you could force environment variable on hostB to write address of hostA. Then on hostC use AcceptEnv to get environment from hostB, voila :)

read sshd_config a bit, parts regarding environment stuff.

Answer 4

From Box C, without access to Box B, you would not be able to tell that the user had come from Box A. In fact, you may not be able to tell how the user got to Box C. It simply depends on how the administrator has set things up.

Same answer for the "suppose further" question. It depends on the permissions that the system administrator has given you and the programs he or she has installed.

Relevant commands that would help you if you had permissions (but you probably don't):

finger - http://www.manpagez.com/man/1/finger/

last - http://www.manpagez.com/man/1/last/