Feb 022014
 

If you use ssh agent forwarding in combination with screen and disconnect from the screen session just to reconnect later to maybe connect to another host you are asked for the password. The reason is quickly explained. When you start a screen session for the first time it sets the SHELL variables for the current SSH session:

root@test1:~# export | egrep 'TERM|SSH'
declare -x SSH_AUTH_SOCK="/tmp/ssh-XFKYAHW930/agent.930"
declare -x SSH_CLIENT="192.168.122.1 10841 22"
declare -x SSH_CONNECTION="192.168.122.1 10841 192.168.122.10 22"
declare -x SSH_TTY="/dev/pts/0"
declare -x TERM="screen"
declare -x TERMCAP="SC|screen|VT 100/ANSI X3.64 virtual terminal:\\
root@test1:~# 

When you disconnect from the host and reconnect later, the SHELL variables were already set in the existing screen session. Below the variables direclty after reconnecting to the host:

root@test1:~# export | egrep 'SSH|TERM'
declare -x SSH_AUTH_SOCK="/tmp/ssh-oPRczk7046/agent.7046"
declare -x SSH_CLIENT="192.168.122.1 10875 22"
declare -x SSH_CONNECTION="192.168.122.1 10875 192.168.122.10 22"
declare -x SSH_TTY="/dev/pts/0"
declare -x TERM="xterm"
root@test1:~# 

And the variables after reconnecting and within the screen session:

root@test1:~# export | egrep 'TERM|SSH'
declare -x SSH_AUTH_SOCK="/tmp/ssh-XFKYAHW930/agent.930"
declare -x SSH_CLIENT="192.168.122.1 10841 22"
declare -x SSH_CONNECTION="192.168.122.1 10841 192.168.122.10 22"
declare -x SSH_TTY="/dev/pts/0"
declare -x TERM="screen"
declare -x TERMCAP="SC|screen|VT 100/ANSI X3.64 virtual terminal:\\
root@test1:~# 

The solution is quite easy and can be found on a number of pages, e.g. http://www.deadman.org/sshscreen.php or (as I just noticed) even more comfortable by linking the SSH_AUTH_SOCK variable.

I might give the linking SSH_AUTH_SOCK variable a go, though in the past I used the PROMPT_COMMAND variable, which get’s called prior running a command in bash, for zsh you can use the precmd (man zshmisc) function.

Add the following to the ~/.bashrc

if [ $TERM != "screen" ]; then
    ${HOME}/bin/setssh.sh
fi
PROMPT_COMMAND=". ${HOME}/tmp/fixssh"

Create 2 directories in your home directory:

# mkdir -p ~/{tmp,bin}

Place the below setssh.sh script (original from http://www.deadman.org/sshscreen.php) in ~/bin/

#!/bin/sh
SSHVARS="SSH_CLIENT SSH_TTY SSH_AUTH_SOCK SSH_CONNECTION DISPLAY"

for x in ${SSHVARS} ; do
    (eval echo $x=\$$x) | sed  's/=/="/
                                s/$/"/
                                s/^/export /'
done 1>$HOME/tmp/fixssh

Whenever you reconnet to the host it will run the setssh.sh scrip and sets the SSH variables for the current session. In the screen session you have to run one command before (or just hit “return”) to source the values from ~/tmp/fixssh.

Jun 172012
 

When setting up port forwarding to a web server, request were failing and command line returned:

channel 3: open failed: administratively prohibited: open failed

There were no firewalls blocking requests and curl just replied with “curl: (52) Empty reply from server”

After reestablishing ssh with -v as argument, the message came a bit clearer:

debug1: channel 3: new [direct-tcpip]                                                                                                                                                 
channel 3: open failed: administratively prohibited: open failed                                                                                                                      
debug1: channel 3: free: direct-tcpip: listening port 8000 for 192.168.33.7 port 80, connect from 127.0.0.1 port 38887, nchannels 4 

Looking into sshd man page and checking sshd options, showed the potential issue straight away:

 AllowTcpForwarding no 

After setting above to yes and a sshd reload all worked smoothly.

 Tagged with: