[SOLVED] Detecting an SSH Session

Woodsman · 12-13-2009, 12:48 PM

When in an SSH session I modify my command prompt by appending (ssh) to the command prompt string. Works nicely to remind me I'm in an SSH session.

I also modify the prompt command by inserting the host name, but the (ssh) string really helps.

Works nicely until I run the su - {username} command. Using the "-" option ignores the original SSH environment variables that are created.

Of course, when not using the "-" option then the original SSH environment variables are preserved.

Any ideas how I can determine I am in an SSH session to modify the command prompt after using the "-" option?

Thanks again.

voyciz · 12-13-2009, 01:20 PM

Can't you just modify the files in ~/.ssh (such as ~/.ssh/config ~/.ssh/environment ~/.ssh/rc) ?

acid_kewpie · 12-13-2009, 01:57 PM

you should be able to check the $TTY variable to know if you're on a local terminal of not, i think.

kjhambrick · 12-13-2009, 07:11 PM

Quote:

Originally Posted by Woodsman

When in an SSH session I modify my command prompt by appending (ssh) to the command prompt string. Works nicely to remind me I'm in an SSH session.

I also modify the prompt command by inserting the host name, but the (ssh) string really helps.

Works nicely until I run the su - {username} command. Using the "-" option ignores the original SSH environment variables that are created.

Of course, when not using the "-" option then the original SSH environment variables are preserved.

Any ideas how I can determine I am in an SSH session to modify the command prompt after using the "-" option?

Thanks again.

Woodsman --

Do you have an SSH_TTY env varb ?

Code:

############ local xterm ##############

[konrad@kjhlt4 ~]$ env |grep SSH_TTY
[konrad@kjhlt4 ~]$ [ "$SSH_TTY" != "" ] && echo "ssh session" || echo "bash session"
bash session

############ ssh session ##############

[konrad@kjhlt4 ~]$ ssh localhost
konrad@localhost's password:
Last login: Fri Dec 11 09:21:33 2009
Linux 2.6.24.3-smp.

Man is a rational animal who always loses his temper when he is called upon
to act in accordance with the dictates of reason.
                -- Oscar Wilde

[konrad@kjhlt4 ~]$ env |grep SSH_TTY
SSH_TTY=/dev/pts/17

[konrad@kjhlt4 ~]$ [ "$SSH_TTY" != "" ] && echo "ssh session" || echo "bash session"
ssh session

############# su - ##################

[konrad@kjhlt4 ~]$ su -
Password:

"Whom are you?" said he, for he had been to night school.
                -- George Ade

[root@kjhlt4 ~]# [ "$SSH_TTY" != "" ] && echo "ssh session" || echo "bash session"
bash session

[root@kjhlt4 ~]# exit
logout

############ ssh session ##############

[konrad@kjhlt4 ~]$ [ "$SSH_TTY" != "" ] && echo "ssh session" || echo "bash session"
ssh session

[konrad@kjhlt4 ~]$ exit
logout

############ local xterm ##############

Connection to localhost closed.
[konrad@kjhlt4 ~]$ [ "$SSH_TTY" != "" ] && echo "ssh session" || echo "bash session"
bash session

HTH

-- kjh

ljb643 · 12-13-2009, 08:02 PM

Since "su -" gives you a 'clean' environment, by design, the SSH environment won't help. The terminal name (`tty`) won't help, since xterms and such also use ptys. The only way I can think of is this somewhat crude hack.

Code:

# Must be sourced to shell, not run as a script.
gppid=$(awk '/^PPid:/ {print $2}' /proc/$PPID/status)
if grep -q ^sshd /proc/$PPID/cmdline /proc/$gppid/cmdline
then
  echo YES we got here via ssh
else
  echo NO I do not recall getting here via ssh
fi

Works for me via ssh or one level of su [-] after ssh. It has to run in your top-level process, or via ". script" (like .profile), not in a subshell. It won't work for another (nested) su, but it could be extended to check more levels.

Woodsman · 12-13-2009, 09:03 PM

Quote:

Do you have an SSH_TTY env varb ?

Yes, but . . .

Quote:

Since "su -" gives you a 'clean' environment, by design, the SSH environment won't help.

Yes, the three SSH environment variables created by the SSH session disappear.

Quote:

The terminal name (`tty`) won't help, since xterms and such also use ptys.

I concluded the same thing after exploring trying to work with the tty command.

Quote:

The only way I can think of is this somewhat crude hack.

Crude or not, I had spent a couple of hours scratching my head before posting. Your solution works wonderfully and you opened the door to learning something new. I never knew about /proc/$PPID/cmdline.

Thanks much!

kjhambrick · 12-14-2009, 04:27 AM

Quote:

Originally Posted by ljb643

Since "su -" gives you a 'clean' environment, by design, the SSH environment won't help. The terminal name (`tty`) won't help, since xterms and such also use ptys. The only way I can think of is this somewhat crude hack.

Code:

# Must be sourced to shell, not run as a script.
gppid=$(awk '/^PPid:/ {print $2}' /proc/$PPID/status)
if grep -q ^sshd /proc/$PPID/cmdline /proc/$gppid/cmdline
then
  echo YES we got here via ssh
else
  echo NO I do not recall getting here via ssh
fi

Works for me via ssh or one level of su [-] after ssh. It has to run in your top-level process, or via ". script" (like .profile), not in a subshell. It won't work for another (nested) su, but it could be extended to check more levels.

Dooh !

Thanks ljb643, I COMPLETELY misread Woodsman's original post !

Interesting code there !

-- kjh

ljb643 · 12-14-2009, 06:22 PM

Thanks.
I should have provided a few details for those trying to learn...
"gppid" is "grandparent process ID", the parent of PPID (parent process ID).
Get the GPPID from the parent process's "status" file, by looking at his "Parent Process ID".
Then check the both parent and grandparent process' command line (cmdline) to see if either is running sshd.