ssh and netcat

[Josef Wolf]

Hello,

a while ago, I asked this list about usage of the ProxyCommand. As a
response, Darren Tucker gave me a great suggestion in this post:

http://www.mail-archive.com/***@securityfocus.com/msg02638.html

I then tried to build upon Darren's idea:

# dns.name is how we find the IP for the gateway to the net
# domain.name is my private name for the network
Host *.domain.name
ProxyCommand /usr/bin/sshproxy dns.name gateway.domain.name %h %p

and here`s the corresponding sshproxy:

#! /bin/sh
extdns=$1
gateway=$2
host=$3
port=$4
DOMAIN=`hostname -d|sed 's/\./\\\./g'`
netcat="netcat -w1 $host $port"
if echo $host | egrep "$DOMAIN$" >/dev/null ; then
# we are already on the target network, no proxy needed
exec $netcat
else
if [ "x$host" = "x$gateway" ] ; then
# we're connecting to the gateway. take in account that it's external
# name is different from the name we called him
exec ssh -o "HostKeyAlias $gateway" $extdns $netcat
else
# we're going behind the gateway. Use the gateway as a hop to the
# real destination.
exec ssh $gateway $netcat
fi
fi

This works great! But there's one drawback: at the end of every session,
a "Killed by signal 1." error is reported. This, of course, gives me a bad
feeling. BTW: the signal number varies, sometimes it is 1, sometimes it
is 2.

I can get rid of this error message by deleting the "exec" keywords from
the above script. But this effectively ignores the error.

So the question is: what causes this "Killed by signal X"? Is it some sort
of incompatibility between ssh and netcat? Or am I using ssh and/or netcat
in a way it was not designed for? Any ideas how to properly get rid of this
error?

[Robert Hajime Lanning]

Post by Josef Wolf
This works great! But there's one drawback: at the end of every session,
a "Killed by signal 1." error is reported. This, of course, gives me a bad
feeling. BTW: the signal number varies, sometimes it is 1, sometimes it
is 2.
I can get rid of this error message by deleting the "exec" keywords from
the above script. But this effectively ignores the error.
So the question is: what causes this "Killed by signal X"? Is it some sort
of incompatibility between ssh and netcat? Or am I using ssh and/or netcat
in a way it was not designed for? Any ideas how to properly get rid of this
error?

It is a normal exit mode.

Signal 1 is SIGHUP, the HangUP signal. This is sent by shells, to all their
children (backgrounded commands) at exit. It tells everything that the terminal
(modem) has hung up. This allows the backgrounded commands to catch
that the session has ended and gracefully exit.

Signal 2 in SIGINT, the Interrupt signal. This is generated by CTRL-C. And is
passed by the shell to the process group of the current running command.

What you are seeing is a race condition. The signal is reaching the
process faster
than the closing of the pipes (normal exit.) By not having the "exec"
key word, there
is one more level of process tree that the signal has to traverse.
This is slowing it
down just enough, so the detection of the closed pipe happens, before
it sees the
signal. So, without the "exec" the error condition is actually not
being ignored, it is
just not happening.

In the end, the "error" can be ignored.

[Derek Martin]

Post by Robert Hajime Lanning

Post by Josef Wolf
This works great! But there's one drawback: at the end of every session,
a "Killed by signal 1." error is reported. This, of course, gives me a bad
feeling. BTW: the signal number varies, sometimes it is 1, sometimes it
is 2.

[...]

Post by Robert Hajime Lanning
Signal 1 is SIGHUP, the HangUP signal. This is sent by shells, to all their
children (backgrounded commands) at exit. It tells everything that the terminal
(modem) has hung up. This allows the backgrounded commands to catch
that the session has ended and gracefully exit.

Minor correction: it's sent by the terminal driver (i.e. the kernel)
to all processes in the foreground process's process group. W.
Richard Stevens has a good discussion of this in Advanced
Programming in the Unix Environment, Chapter 10 on signals, though
other good references exist as well.

[Darren Tucker]

Post by Josef Wolf
I can get rid of this error message by deleting the "exec" keywords from
the above script. But this effectively ignores the error.
So the question is: what causes this "Killed by signal X"? Is it some sort
of incompatibility between ssh and netcat?

The "outer" ssh command sends a SIGHUP to the proxycommand when it shuts
down (some versions of netcat don't check for the closure of their
stdin/stdout and would hang around forever).

By default, if ssh is killed by a signal it reports which one, which is
what you're seeing (on Linux, 1=SIGHUP, 2=SIGINT).

Post by Josef Wolf
Or am I using ssh and/or netcat
in a way it was not designed for? Any ideas how to properly get rid of this
error?

You can either keep doing what you're doing (without the "exec", the ssh
command has a parent shell, and the shell catches the SIGHUP but it does
keep the shell process around for the duration of the connection) or
tell ssh to be quiet and not report the signal (change "exec ssh foo" to
"exec ssh -q foo").

[Josef Wolf]

Post by Darren Tucker

Post by Josef Wolf
I can get rid of this error message by deleting the "exec" keywords from
the above script. But this effectively ignores the error.
So the question is: what causes this "Killed by signal X"? Is it some sort
of incompatibility between ssh and netcat?

The "outer" ssh command sends a SIGHUP to the proxycommand when it shuts
down (some versions of netcat don't check for the closure of their
stdin/stdout and would hang around forever).
By default, if ssh is killed by a signal it reports which one, which is
what you're seeing (on Linux, 1=SIGHUP, 2=SIGINT).

Post by Josef Wolf
Or am I using ssh and/or netcat
in a way it was not designed for? Any ideas how to properly get rid of this
error?

You can either keep doing what you're doing (without the "exec", the ssh
command has a parent shell, and the shell catches the SIGHUP but it does
keep the shell process around for the duration of the connection) or tell
ssh to be quiet and not report the signal (change "exec ssh foo" to "exec
ssh -q foo").

Thanks for the description, Darren!

What would be the safe way when a real problem occurs? When I ignore the
error (either how I did it or by telling ssh to be quiet), will e.g. scp
properly report any problems?

In addition, I have one more problem with this setup: when I am localuser
on the local host and I try to connect as remoteuser like this:

git clone ssh://***@remote.host/some/repository

then it tries to go through the proxy as "localuser", only on the far end
it tries to login as "remoteuser".

So the question extends to: is there a way to find out from the proxycommand
as which user the connection should be done on the far end?