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/secureshell@.../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]

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

[Darren Tucker]

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.

[Josef Wolf]

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

[Derek Martin]

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@...> 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