Mailing List Archive: ssh and netcat

ssh and netcat

Oct 2, 2009, 5:00 PM

Post #1 of 5 (5721 views)

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/secureshell@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?

Re: ssh and netcat [ In reply to ]

robert.lanning at gmail

Oct 5, 2009, 10:05 AM

Post #2 of 5 (5558 views)

Permalink

On Fri, Oct 2, 2009 at 5:00 PM, Josef Wolf <jw@raven.inka.de> wrote:
> 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.

--
And, did Galoka think the Ulus were too ugly to save?
-Centauri

Re: ssh and netcat [ In reply to ]

dtucker at zip

Oct 5, 2009, 3:53 PM

Post #3 of 5 (5564 views)

Permalink

Josef Wolf wrote:
> 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).

> 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").

--
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69
Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.

Re: ssh and netcat [ In reply to ]

jw at raven

Oct 7, 2009, 9:03 AM

Post #4 of 5 (5557 views)

Permalink

On Tue, Oct 06, 2009 at 09:53:27AM +1100, Darren Tucker wrote:
> Josef Wolf wrote:
>> 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).
>
>> 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://remoteuser@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?

Re: ssh and netcat [ In reply to ]

code at pizzashack

Oct 14, 2009, 11:02 AM

Post #5 of 5 (5480 views)

Permalink

On Mon, Oct 05, 2009 at 10:05:15AM -0700, Robert Hajime Lanning wrote:
> On Fri, Oct 2, 2009 at 5:00 PM, Josef Wolf <jw@raven.inka.de> wrote:
> > 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.
[...]
> 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.

--
Derek D. Martin
http://www.pizzashack.org/
GPG Key ID: 0x81CFE75D