Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

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.

share|improve this question
    
If you have userA and userB's cooperation, see When ssh'ing, how can I set an environment variable on the server that changes from session to session? –  Gilles Mar 15 '11 at 22:21

4 Answers 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/
share|improve this answer

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.

share|improve this answer

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.

share|improve this answer
    
that would only work if B cooperates fully. There is no way C can check whether the value sent by B is accurate or fabricated. –  Gilles Aug 12 '10 at 13:28
    
AcceptEnv has the potential to be used to relay the information i want. sadly only root can set AcceptEnv and default is to accept no environment variables. i do not have root access to the most machines i ssh to. –  lesmana Aug 13 '10 at 18:03
up vote 2 down vote accepted

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.
share|improve this answer
    
Many servers are configured to let LC_* variables through (these are normally used by locales, but you can subvert them). For example, LC_FOO=bar ssh localhost 'echo $LC_FOO' displays bar on my machine under the default setup (on Debian squeeze). –  Gilles Mar 15 '11 at 22:21
    
@Gilles Yes, if the server accepts LC_* then you can use that to sneak in a variable. I have encountered some really paranoid sysadmins whose servers do not accept even the standard LC_* variables, they just didn't accept any variable at all. –  lesmana Mar 17 '11 at 18:57

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.