Nabble - SSH (Secure Shell)

Re: remote port forwarding unstable

2009-11-24T02:05:00Z

On Mon, 19 Oct 2009, Adriana Rodean wrote:

> I always do a remote port forwarding with openssh on 1026 port let's
> say ( ssh -R 1026:localhost:55555 ). Most times the port is opened on
> remote machine. But sometimes i notice that ssh can't do remote port
> forwarding to that port 1026. I looked on the remote machine (netstat
> -an) and no one is using that port, so the port is free.
> Only way to fix this is do a remote port forwarding to another port
> lets say 1056, successfully done, then try again and do it for 1026,
> this time remote port forwarding successfully works... Sometimes it
> works if i try again with 1026, but other times i need to open another
> port then try again with 1026 port...
>
> [..]
>
> I use version of OpenSSH 5.1p1 on remote machine and the client is
> OpenSSH for Windows 3.8.1p1

Nobody uses the port, but it is still in TIME_WAIT state.
Usually openssh uses SO_REUSEADDR to say the kernel that the
port can be reused while in TIME_WAIT state, but to avoid X11
man-in-the-middle attack the portable version of OpenSSH
5.1 does not set it if you have X11UseLocalhost=no.

So, you should either wait a little after each closing of the
port before trying to use it again, or set X11UseLocalhost=yes.

--
Regards,
ASK

Re: Remotely replaced sshd_config, CentOS 5.3/SSH 4.3p2-36el5_4.2

2009-11-13T09:08:50Z

68.50.70.187 is the attackers' IP.

Leif Nixon wrote:

> Adam Hubscher <offbeatadam@...> writes:
>
>> These servers run cPanel and have been updated to the following
>> specs:
>>
>> 2.6.18-164.el5PAE #1 SMP Thu Sep 3 04:10:44 EDT 2009 i686 i686 i386
>> GNU/Linux
>
> This seems vulnerable to CVE-2009-3547 and CVE-2009-2695. If SELinux is
> enabled, you can trivially get root on these machines if you can run
> commands as a logged in user.
>
> I would start by looking very hard at all successful ssh logins the
> hours before the known intrusion. It is very possible that some of them
> are performed using stolen ssh keys.
>
>> I have logs from these servers, if you need other information to
>> possibly help track this down that is possible. I'm having a hard time
>> finding the vector for this attack though...
>
> If you could share the IP number of the attacking host, that could be
> useful. Does /root/.bash_history contain anything interesting? Is there
> anything suspicious in /dev/shm? (There won't be, if the machine has
> been rebooted after the intrusion.)
>

smime.p7s (4K) Download Attachment

Re: Remotely replaced sshd_config, CentOS 5.3/SSH 4.3p2-36el5_4.2

2009-11-13T08:46:33Z

2009/11/12 Adam Hubscher <offbeatadam@...>:
> Early (around midnight-1am CST) this morning we had a widespread attack via
> an unknown vector. In the attack, the only thing that I can find is the
> following (IP blacked out, although it is the attackers' address):

A couple of colleagues at UK universities have reported seeing things
similar to the following (they run RHEL5/CentOS/Scientific Linux) :-

A user account was used to log in from two sites:

195.22.101.220 (server14.Xuna.nl)
195.22.100.126 (server12.xuna.nl)

On the compromised systems (RHEL5) the ssh and sshd binaries were
replaced with ones that logged username and plain text password
information to a file called /etc/X11/fonts/misc/s1

The new ssh and sshd had the dates set to the originals, but they didn't
have a and i attributes set. Their new sizes were

334768 /usr/bin/ssh
445512 /usr/sbin/sshd

The output of 'strings /usr/sbin/sshd' included the following:

/etc/X11/fonts/misc/S1
/etc/X11/fonts/misc/s1
/etc/X11/fonts/misc/s1.tmp
rm -rf /etc/X11/fonts/misc/s1; cp /etc/X11/fonts/misc/s1.tmp
/etc/X11/fonts/misc/s1; chmod o+w /etc/X11/fonts/misc/s1; rm -rf
/etc/X11/fonts/misc/s1.tmp
/usr/X11R6/bin/xauth
no-X11-forwarding

and 'strings /usr/sbin/ssh' included:

/etc/X11/fonts/misc/S1
/etc/X11/fonts/misc/s1

Where a compromised system had had the openssh-server and openssh-clients
rpms updated after the compromise, 'rpm -V' on openssh-server and
openssh-clients looked ok (but the /etc/X11/fonts/misc/s1 file still
existed).

Regards,

Mark

Remotely replaced sshd_config, CentOS 5.3/SSH 4.3p2-36el5_4.2

2009-11-12T09:55:37Z

Hello Everyone,

Fighting a bit of a nasty morning... anyone seen this before?

We have a number of servers that have password authentication disabled
as well as shell access disabled for all users except those whom have
keys. These servers run cPanel and have been updated to the following specs:

2.6.18-164.el5PAE #1 SMP Thu Sep 3 04:10:44 EDT 2009 i686 i686 i386
GNU/Linux
openssh-4.3p2-36.el5_4.2

Early (around midnight-1am CST) this morning we had a widespread attack
via an unknown vector. In the attack, the only thing that I can find is
the following (IP blacked out, although it is the attackers' address):

Nov 12 04:31:22 sharedserver/sharedserver sshd[16083]: Received
disconnect from 100.100.100.100: 11: No supported authentication methods
available
Nov 12 04:32:14 sharedserver/sharedserver sshd[11265]: Received signal
15; terminating.
Nov 12 04:32:14 sharedserver/sharedserver sshd[16570]: Server listening
on :: port 2.
Nov 12 04:32:14 sharedserver/sharedserver sshd[16570]: error: Bind to
port 2 on 0.0.0.0 failed: Address already in use.
Nov 12 04:32:27 sharedserver/sharedserver sshd[16611]: Accepted password
for root from 100.100.100.100 port 3630 ssh2
Nov 12 04:32:27 sharedserver/sharedserver sshd[16611]:
pam_unix(sshd:session): session opened for user root by (uid=0)

The concerning part is that it obviously appears that there is someone
reloading SSHD, but there is no successful login (at all) via shell
prior to this.

This time corresponds with a modified sshd_config that then allows
password authentication, whereby the user then logs in as root and has a
good time, so to speak.

I know that the following vulnerability is out in the wild:

Linux Kernel 'sock_sendpage()' NULL Pointer Dereference Vulnerability

However, since the user never actually logged into the server from what
I can see, I'm still searching for the real way that this occurred.

I have logs from these servers, if you need other information to
possibly help track this down that is possible. I'm having a hard time
finding the vector for this attack though...

Any assistance would be greatly appreciated.

smime.p7s (4K) Download Attachment

SOLUTION ! [BUG?] sshd closes the connection after 2^16 bytes

2009-11-12T01:15:50Z

Hi,

Rather unbelievable, but upgrading the _kernel_ from 2.6.18-128.7.1 to
2.6.18-164.6.1 fixed the problem (we had good reasons not to upgrade,
but we worked around them).

Thanks,

Matthieu Moy <Matthieu.Moy@...> writes:

> Hi,
>
> I'm having trouble with the sshd on one particular machine. In short:
>
> $ head -c 196481 /dev/zero | ssh machine-name 'LANG=C wc'
> 0 0 65536
>
> (the 65536 here should have been a 196481 ...)
>
> This happens whether I launch the command from the machine, or from
> another remote machine. The OpenSSH version is:
>
> OpenSSH_4.3p2, OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008
>
> with:
>
> $ cat /etc/redhat-release
> Red Hat Enterprise Linux Server release 5.4 (Tikanga)
> $ uname -a
> Linux machine-name 2.6.18-128.7.1.el5 #1 SMP Wed Aug 19 04:08:13 EDT 2009 ppc64 ppc64 ppc64 GNU/Linux
>
> One surprising thing:
>
> $ head -c 196481 /dev/zero | ssh machine-name 'LANG=C wc'
> 0 0 65536
> $ head -c 196480 /dev/zero | ssh machine-name 'LANG=C wc'
> 0 0 196480
>
> So, the bug is triggered when sending 196481 bytes or more, but the
> consequence is a truncation of the input at 65536=2^16 bytes.
>
> Any idea what's going on?
>
> Thanks,
>
> (please, keep me Cc-ed, I didn't subscribe to the list)

--
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: Reverse port forwarding (-R) seems not working

2009-11-11T10:34:25Z

On Wed, Nov 11, 2009 at 11:01:28AM +0100, Vincenzo Romano wrote:
> It's not yet working though.
>
> If I enable the GatewayPorts on the sshd_config (not ssh_config), then
> no RPF works anymore on the dummy interfaces or the loopback.
> They all fail with:
> Warning: remote port forwarding failed for listen port 139, despite
> there's no process listening on that interface and that port.

In your original example you had "user@...". If "user" is
not root then you probably don't have permissions to bind to
low-numbered ports (with or without sshd).

If that's not it, I suggest running the server in debug mode
(eg /path/to/sshd -ddde -p222 to run it on port 222), point your client
at it and see what the reason given for the bind failure is.

--
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: [BUG?] sshd closes the connection after 2^16 bytes

2009-11-11T05:31:29Z

Matthieu Moy <Matthieu.Moy@...> writes:

> Hmm, even funnier:
>
> (head -c 196480 /dev/zero; sleep 0.25; head -c 196480 /dev/zero) | ssh localhost "wc -c"
> 392960
> (head -c 196480 /dev/zero; sleep 0.2; head -c 196480 /dev/zero) | ssh localhost "wc -c"
> 65536

Actually, just

(sleep 0.1; head -c 196481 /dev/zero) | ssh localhost "wc -c"
65536
(sleep 0.2; head -c 196481 /dev/zero) | ssh localhost "wc -c"
196481

And interestingly, if I do

echo 'sleep 1' > ~/.bashrc

then

(sleep 1.0; head -c 196481 /dev/zero) | ssh localhost "wc -c"
65536
(sleep 1.1; head -c 196481 /dev/zero) | ssh localhost "wc -c"
196481

Also,

ensibm:~>(head -c 196480 /dev/zero; sleep 1.2; echo boom) | ssh localhost "wc -c"
196485
ensibm:~>(head -c 196480 /dev/zero; sleep 1.0; echo boom) | ssh localhost "wc -c"
65536

and,

ensibm:~>rm ~/.bashrc
ensibm:~>(head -c 196480 /dev/zero; sleep 1.0; echo boom) | ssh localhost "sleep 1; wc -c"
65536
ensibm:~>(head -c 196480 /dev/zero; sleep 1.2; echo boom) | ssh localhost "sleep 1; wc -c"
196485

and more precisely,

ensibm:~>(head -c 196480 /dev/zero; sleep 1; echo boom) | ssh localhost "head -c 16383 | wc -c; sleep 2; wc -c"
16383
49153
ensibm:~>(head -c 196480 /dev/zero; sleep 1; echo boom) | ssh localhost "head -c 16384 | wc -c; sleep 2; wc -c"
16384
180101

The last one says that if strictly more than 196480 bytes are sent to
ssh, _and_ if strictly less than 16384 bytes (= 16KiB) are consumed
quickly, then the bug occurs.

--
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: Reverse port forwarding (-R) seems not working

2009-11-11T05:10:49Z

On Tue, Nov 10, 2009 at 11:17:58PM +0100, Vincenzo Romano wrote:
> ssh -N -n -R 127.0.1.1:139:somelocalhost:139 user@...

> What happens instead is that, upon ssh connection on the remotehost I
> see a listening socket on the interface 127.0.0.1!

-R [bind_address:]port:host:hostport
...
By default, the listening socket on the server will be bound to
the loopback interface only. This may be overridden by specify-
ing a bind_address. An empty bind_address, or the address `*',
indicates that the remote socket should listen on all interfaces.
Specifying a remote bind_address will only succeed if the serv-
er's GatewayPorts option is enabled (see sshd_config(5)).

Re: Reverse port forwarding (-R) seems not working

2009-11-11T02:01:28Z

It's not yet working though.

If I enable the GatewayPorts on the sshd_config (not ssh_config), then
no RPF works anymore on the dummy interfaces or the loopback.
They all fail with:
Warning: remote port forwarding failed for listen port 139, despite
there's no process listening on that interface and that port.

The client is:
OpenSSH_4.4p1, OpenSSL 0.9.8d 28 Sep 2006
The server is:
OpenSSH_4.1p1, OpenSSL 0.9.7g 11 Apr 2005
and I won't be able to update them.

What could be the next hint?

Thanks.

2009/11/11 Darren Tucker <dtucker@...>:

> Vincenzo Romano wrote:
>>
>> Hi all.
>> I need to create a number of different reverse port forwarding (RPF)
>> with the -R option.
>> On the remote system I have set up a number of different dummy local
>> interfaces (dummy0=127.0.1.1 to dummy9=127.0.1.10).
>> A single RPF should look like this:
>>
>> ssh -N -n -R 127.0.1.1:139:somelocalhost:139 user@...
>>
>> (it's actually for SAMBA printers reachability).
>> What happens instead is that, upon ssh connection on the remotehost I
>> see a listening socket on the interface 127.0.0.1!
>> That's the lo (loopback) and not the dummy0.
>> In an attempt to troubleshoot this problem I've changed the sshd
>> configuration in order to have it listening on every single interface
>> (as poosed to the default "one catches them all" setup). No luck.
>
> If you're using OpenSSH then you need to set "GatewayPorts clientspecified"
> in sshd_config and restart sshd. If your sshd doesn't understand
> "clientspecified" then it also doesn't have the code to handle this case and
> you'll need a newer version.
>
> quoth ssh_config(5):
>
> GatewayPorts
> Specifies whether remote hosts are allowed to con-
> nect to ports forwarded for the client. By
> default, sshd(8) binds remote port forwardings to
> the loopback address. This prevents other remote
> hosts from connecting to forwarded ports.
> GatewayPorts can be used to specify that sshd
> should allow remote port forwardings to bind to
> non-loopback addresses, thus allowing other hosts
> to connect. The argument may be "no" to force
> remote port forwardings to be available to the
> local host only, "yes" to force remote port for-
> wardings to bind to the wildcard address, or
> "clientspecified" to allow the client to select the
> address to which the forwarding is bound. The
> default is "no".
>
> --
> 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.
>

--
Vincenzo Romano
NotOrAnd Information Technologies
cel. +39 339 8083886 | gtalk. vr@...
fix. +39 0823 454163 | skype. notorand.it
fax. +39 02 700506964 | msn. notorand.it
--
NON QVIETIS MARIBVS NAVTA PERITVS

Re: Reverse port forwarding (-R) seems not working

2009-11-10T21:49:54Z

Great!
Isn't mine a FAQ?
Thanks.

2009/11/11 Darren Tucker <dtucker@...>:

Re: Reverse port forwarding (-R) seems not working

2009-11-10T20:40:57Z

Vincenzo Romano wrote:

> Hi all.
> I need to create a number of different reverse port forwarding (RPF)
> with the -R option.
> On the remote system I have set up a number of different dummy local
> interfaces (dummy0=127.0.1.1 to dummy9=127.0.1.10).
> A single RPF should look like this:
>
> ssh -N -n -R 127.0.1.1:139:somelocalhost:139 user@...
>
> (it's actually for SAMBA printers reachability).
> What happens instead is that, upon ssh connection on the remotehost I
> see a listening socket on the interface 127.0.0.1!
> That's the lo (loopback) and not the dummy0.
> In an attempt to troubleshoot this problem I've changed the sshd
> configuration in order to have it listening on every single interface
> (as poosed to the default "one catches them all" setup). No luck.

If you're using OpenSSH then you need to set "GatewayPorts
clientspecified" in sshd_config and restart sshd. If your sshd doesn't
understand "clientspecified" then it also doesn't have the code to
handle this case and you'll need a newer version.

quoth ssh_config(5):

GatewayPorts
Specifies whether remote hosts are allowed to con-
nect to ports forwarded for the client. By
default, sshd(8) binds remote port forwardings to
the loopback address. This prevents other remote
hosts from connecting to forwarded ports.
GatewayPorts can be used to specify that sshd
should allow remote port forwardings to bind to
non-loopback addresses, thus allowing other hosts
to connect. The argument may be "no" to force
remote port forwardings to be available to the
local host only, "yes" to force remote port for-
wardings to bind to the wildcard address, or
"clientspecified" to allow the client to select the
address to which the forwarding is bound. The
default is "no".

--
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: Reverse port forwarding (-R) seems not working

2009-11-10T19:38:02Z

--- On Tue, 11/10/09, Vincenzo Romano <Vincenzo.Romano@...> wrote:

> On the remote system I have set up a number of different
> dummy local
> interfaces (dummy0=127.0.1.1 to dummy9=127.0.1.10).
> A single RPF should look like this:
>
> ssh -N -n -R 127.0.1.1:139:somelocalhost:139 user@...
>
> (it's actually for SAMBA printers reachability).
> What happens instead is that, upon ssh connection on the
> remotehost I
> see a listening socket on the interface 127.0.0.1!

I'm not very clear on what your goal is, but anything beginning with 127 (127.x.y.z) is going to be treated the same-- localhost. You can address all 16 million possibilities any way you want, but they all will appear the same localhost to the system.

What is your specific goal?

Also, your -R needs 1 argument: RemotePort:Ip-relative-to-Target:Port-on-relative-Target IP-of-Target

Reverse port forwarding (-R) seems not working

2009-11-10T14:17:58Z

Hi all.
I need to create a number of different reverse port forwarding (RPF)
with the -R option.
On the remote system I have set up a number of different dummy local
interfaces (dummy0=127.0.1.1 to dummy9=127.0.1.10).
A single RPF should look like this:

ssh -N -n -R 127.0.1.1:139:somelocalhost:139 user@...

(it's actually for SAMBA printers reachability).
What happens instead is that, upon ssh connection on the remotehost I
see a listening socket on the interface 127.0.0.1!
That's the lo (loopback) and not the dummy0.
In an attempt to troubleshoot this problem I've changed the sshd
configuration in order to have it listening on every single interface
(as poosed to the default "one catches them all" setup). No luck.

Now I see two options:
either I'm missing something important
or this is a bug.

I hope for the first option so I can hope in a simple solution.

Any hint on this?

--
Vincenzo Romano
NON QVIETIS MARIBVS NAVTA PERITVS

Re: [BUG?] sshd closes the connection after 2^16 bytes

2009-11-09T23:13:16Z

Lamont Granquist <lamont@...> writes:

> i can't replicate that, but what does this return for you:
>
> head -c 196481 /dev/zero | cat -u | ssh machine-name 'LANG=C wc'

head -c 196481 /dev/zero | cat -u | ssh localhost 'LANG=C wc'
0 0 65536

--
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: [BUG?] sshd closes the connection after 2^16 bytes

2009-11-09T14:15:05Z

i can't replicate that, but what does this return for you:

head -c 196481 /dev/zero | cat -u | ssh machine-name 'LANG=C wc'

On Mon, 9 Nov 2009, Matthieu Moy wrote:

> Hi,
>
> I'm having trouble with the sshd on one particular machine. In short:
>
> $ head -c 196481 /dev/zero | ssh machine-name 'LANG=C wc'
> 0 0 65536
>
> (the 65536 here should have been a 196481 ...)
>
> This happens whether I launch the command from the machine, or from
> another remote machine. The OpenSSH version is:
>
> OpenSSH_4.3p2, OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008
>
> with:
>
> $ cat /etc/redhat-release
> Red Hat Enterprise Linux Server release 5.4 (Tikanga)
> $ uname -a
> Linux machine-name 2.6.18-128.7.1.el5 #1 SMP Wed Aug 19 04:08:13 EDT 2009 ppc64 ppc64 ppc64 GNU/Linux
>
> One surprising thing:
>
> $ head -c 196481 /dev/zero | ssh machine-name 'LANG=C wc'
> 0 0 65536
> $ head -c 196480 /dev/zero | ssh machine-name 'LANG=C wc'
> 0 0 196480
>
> So, the bug is triggered when sending 196481 bytes or more, but the
> consequence is a truncation of the input at 65536=2^16 bytes.
>
> Any idea what's going on?
>
> Thanks,
>
> --
> Matthieu Moy
> http://www-verimag.imag.fr/~moy/
>

[BUG?] sshd closes the connection after 2^16 bytes

2009-11-09T06:26:23Z

Hi,

I'm having trouble with the sshd on one particular machine. In short:

$ head -c 196481 /dev/zero | ssh machine-name 'LANG=C wc'
0 0 65536

(the 65536 here should have been a 196481 ...)

This happens whether I launch the command from the machine, or from
another remote machine. The OpenSSH version is:

OpenSSH_4.3p2, OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008

with:

$ cat /etc/redhat-release
Red Hat Enterprise Linux Server release 5.4 (Tikanga)
$ uname -a
Linux machine-name 2.6.18-128.7.1.el5 #1 SMP Wed Aug 19 04:08:13 EDT 2009 ppc64 ppc64 ppc64 GNU/Linux

One surprising thing:

$ head -c 196481 /dev/zero | ssh machine-name 'LANG=C wc'
0 0 65536
$ head -c 196480 /dev/zero | ssh machine-name 'LANG=C wc'
0 0 196480

So, the bug is triggered when sending 196481 bytes or more, but the
consequence is a truncation of the input at 65536=2^16 bytes.

Any idea what's going on?

Thanks,

--
Matthieu Moy
http://www-verimag.imag.fr/~moy/

ssh tools and SSH_ASKPASS

2009-11-02T06:50:02Z

Hello all!

I've played this weekend with the SSH_ASKPASS feature of ssh-add
and ssh tools, and I must say that I like the idea, because it allows
me to input the passwords for either a key or authentication from a
(more) secure terminal. (For example if I don't trust my applications
running in the same X session, I can use a custom SSH_ASKPASS to query
the password from /dev/tty11, which I did.)

But now there is a problem... You really have to try hard to
convince ssh-add and ssh tools to use the SSH_ASKPASS feature, by
resorting to the following tricks:
* ssh-add ... </dev/null;
* notty ssh -t ...; (where notty is a custom application that
detaches the application from the controlling terminal);

So my question is: woldn't it be nice to have all the tools always
obey the SSH_ASKPASS setting?

Thanks,
Ciprian Craciun.

Re: Setting permissions of ssh access

2009-10-26T15:40:15Z

Yes, my main goal is to use rsync-backup once I have a good test case
going. I spent a lot of time on OS X getting two machines to talk to
each other with passwordless logins and using a root account. I was
pulling the backup from the client, to the server.

I went by this article, which expressly states that push backups are
not the way to go:
http://www.connect.homeunix.com/lbackup/network_backup_strategies

It struck me as odd as well, and I am going to go back to pushing the
data from the machines out to the single backup machine, which I can
section off to not even be accessible to the outside world.

As I go through this process, I will document it, as there were some
pretty strange thins happening with sshd_conf and not letting me have
a root login.

Thanks for your comments, as soon as I have more, I will follow up.

--
Scott * If you contact me off list replace talklists@ with scott@ *

On Oct 26, 2009, at 11:04 AM, Quintin Beukes wrote:

> Rather PUSH backups. This way you can
> 1) Close the backup machine to allow ONLY access from the specified
> machines on an IP/MAC bases (since it's local net)
> 2) You don't have to open up root access for any machines
> 3) You can have the rsync client run as root to allow it to copy all
> files on it's own machine, then copying it to a lower access user on
> the target machine.
>
> If you want your backup files to be stored with the same
> ownership/permissions as on the source machine, you would have to
> login as root on the backup machine. If it's closed from outside
> access this is safer than allowing root access to your public machine.
> Further restricting it by IP/MAC makes this even more secure.
>
> If using something like rsync-backup, you're basically running a
> static command on the backup server's side, which provides an extra
> level of security if you want to have the backup server side execute
> as root as well. Let me explain it like this:
> 1) You have the source machine S - it's public
> 2) You have the machine machine B - it's completely closed up and only
> allows IP/MAC level filtering on incoming port 22 from machine S
> 3) On machine B you have a root account with a password for you to
> login
> 4) You want machine S to use this root account to copy it's backups
> 5) You use rsync-backup wrapped in ssh to do this. This means you have
> 2 commands run by ssh, the rsync-backup client command and
> rsync-backup server side command
> 6) You setup a public key on the root account on machine B, which is
> only allowed to run a single command, the rsync-backup command. This
> means rsync-backup authenticates using the public key, but is only
> allowed to run a fixed command, which is the one it uses to copy the
> backups. So it is authenticated as root, which allows you to copy all
> types of ownership/permissions, even setuid bits, but you can't do ANY
> other than what rsync-backup command and it's protocol allows.
>
> Have you heard of rsync-backup? It's a utility which uses rsync's
> libraries, but provides common backup features like exclusions,
> incremental backups + increment management, etc. The technique listed
> above is what I use to make all my backups. It's really simple, works
> brilliantly and with the specified would be very secure as well. Since
> it's running as root there is always the risk of exploitation to gain
> root access, which could cause compromise of your other machines,
> though it's already very secure and always possible to add extra
> levels of security.
>
> Quintin Beukes
>
>
>
> On Fri, Oct 23, 2009 at 9:28 PM, Scott Haneda <talklists@...>
> wrote:
>> Hello, I've looked around and found a few different approaches to
>> this.
>> Looking for a discussion of the pros, cons, and best practices.
>>
>> I want to use rsync over an ssh connection to clone one machine to
>> another.
>> This means one end will need root login.
>>
>> Right now I have passwordless keys to allow myself to login. Root
>> login is
>> disabled.
>>
>> Would an acceptable method be to allow root login from a specific IP
>> address? Or is there some other way to allow root privilege use
>> between a
>> source and destination host without opening it up by IP?
>>
>> This is for backups, and only ever will be machine to machine, same
>> subnet.
>> I'm not immediately seeing how to set granular permissions based on
>> conditions like IP, MAC, or other harder to spoof credentials.
>>
>> I'd it better to pull backups or push backups, or equivalent?
>>
>> The backup machine could be made to have no public access at all.
>> Thanks for
>> any pointers.
>>
>> --
>> Scott
>> Iphone says hello.
>

Re: Setting permissions of ssh access

2009-10-26T11:04:03Z

Rather PUSH backups. This way you can
1) Close the backup machine to allow ONLY access from the specified
machines on an IP/MAC bases (since it's local net)
2) You don't have to open up root access for any machines
3) You can have the rsync client run as root to allow it to copy all
files on it's own machine, then copying it to a lower access user on
the target machine.

If you want your backup files to be stored with the same
ownership/permissions as on the source machine, you would have to
login as root on the backup machine. If it's closed from outside
access this is safer than allowing root access to your public machine.
Further restricting it by IP/MAC makes this even more secure.

If using something like rsync-backup, you're basically running a
static command on the backup server's side, which provides an extra
level of security if you want to have the backup server side execute
as root as well. Let me explain it like this:
1) You have the source machine S - it's public
2) You have the machine machine B - it's completely closed up and only
allows IP/MAC level filtering on incoming port 22 from machine S
3) On machine B you have a root account with a password for you to login
4) You want machine S to use this root account to copy it's backups
5) You use rsync-backup wrapped in ssh to do this. This means you have
2 commands run by ssh, the rsync-backup client command and
rsync-backup server side command
6) You setup a public key on the root account on machine B, which is
only allowed to run a single command, the rsync-backup command. This
means rsync-backup authenticates using the public key, but is only
allowed to run a fixed command, which is the one it uses to copy the
backups. So it is authenticated as root, which allows you to copy all
types of ownership/permissions, even setuid bits, but you can't do ANY
other than what rsync-backup command and it's protocol allows.

Have you heard of rsync-backup? It's a utility which uses rsync's
libraries, but provides common backup features like exclusions,
incremental backups + increment management, etc. The technique listed
above is what I use to make all my backups. It's really simple, works
brilliantly and with the specified would be very secure as well. Since
it's running as root there is always the risk of exploitation to gain
root access, which could cause compromise of your other machines,
though it's already very secure and always possible to add extra
levels of security.

Quintin Beukes

On Fri, Oct 23, 2009 at 9:28 PM, Scott Haneda <talklists@...> wrote:

> Hello, I've looked around and found a few different approaches to this.
> Looking for a discussion of the pros, cons, and best practices.
>
> I want to use rsync over an ssh connection to clone one machine to another.
> This means one end will need root login.
>
> Right now I have passwordless keys to allow myself to login. Root login is
> disabled.
>
> Would an acceptable method be to allow root login from a specific IP
> address? Or is there some other way to allow root privilege use between a
> source and destination host without opening it up by IP?
>
> This is for backups, and only ever will be machine to machine, same subnet.
> I'm not immediately seeing how to set granular permissions based on
> conditions like IP, MAC, or other harder to spoof credentials.
>
> I'd it better to pull backups or push backups, or equivalent?
>
> The backup machine could be made to have no public access at all. Thanks for
> any pointers.
>
> --
> Scott
> Iphone says hello.
>

alternate output for progressmeter

2009-10-24T14:34:41Z

Hi,

I used scp in some background process for transferring large files
which took some hours.
For this I needed a less fancy output, preferable parseble by a script
, so I could regularly see how far the transfer was

The adaptions I made to progressmeter.c and .h are underneath my mail as a patch

Some sample output how it looks now:
:~/src/openssh-5.3p1$ ./scp -l 60000 test.bin hans@localhost:.
progress test.bin : 0% 0 0.0KB/s --:-- ETA
progress test.bin : 7% 7488KB 7.3MB/s 00:12 ETA
progress test.bin : 15% 14MB 7.3MB/s 00:11 ETA
..
progress test.bin : 98% 94MB 7.3MB/s 00:00 ETA
progress test.bin : 100% 95MB 7.3MB/s 00:13 done

With a simple script you can now easily control the output and save
the progress somewhere:

#!/bin/bash
# --- only update status every 10 seconds
statfn=scp1.status
refresh=10
no=0
./scp -l 60000 test.bin hans@localhost:. 2>&1|while read id fn sep
perc size speed estim eta
do
((state=no % refresh))
[[ "$eta" = "done" || $state -eq 0 ]] && echo "`date +"%Y-%m-%d
%H:%M:%S"` $fn $perc $size $speed $estim $eta" >$statfn
((no=no+1))
done

The patch only adds this functionality as an option, default the
original layout is used.
Only when variable progresstype is set to nonzero this alternate
output is selected.
For selecting the alternate output it would only require some
commandline option in scp.c and do the isatty check only when
progresstype==0

Let me know your comments...

Hans

--- progressmeter.h 2006-03-26 05:30:02.000000000 +0200
+++ progressmeter_new.h 2009-10-24 20:35:35.168288539 +0200
@@ -23,5 +23,7 @@
* THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*/

+extern int progresstype;
+
void start_progress_meter(char *, off_t, off_t *);
void stop_progress_meter(void);

--- progressmeter.c 2006-08-05 04:39:40.000000000 +0200
+++ progressmeter_new.c 2009-10-24 20:32:45.455788330 +0200
@@ -74,12 +74,15 @@
static int win_size; /* terminal window size */
static volatile sig_atomic_t win_resized; /* for window resizing */

+int progresstype = 0; /* use default tty progress reporting */
+
/* units for format_size */
static const char unit[] = " KMGT";

static int
can_output(void)
{
+ if (progresstype) return 1;
return (getpgrp() == tcgetpgrp(STDOUT_FILENO));
}

@@ -158,9 +161,9 @@

/* filename */
buf[0] = '\0';
- file_len = win_size - 35;
+ file_len = (progresstype)?(strlen(file)+11):(win_size - 35);
if (file_len > 0) {
- len = snprintf(buf, file_len + 1, "\r%s", file);
+ len = snprintf(buf, file_len + 1, (progresstype)?"progress %s
:":"\r%s", file);
if (len < 0)
len = 0;
if (len >= file_len + 1)
@@ -195,7 +198,7 @@
stalled = 0;

if (stalled >= STALL_TIME)
- strlcat(buf, "- stalled -", win_size);
+ strlcat(buf, (progresstype)?"-stalled-":"- stalled -", win_size);
else if (bytes_per_second == 0 && bytes_left)
strlcat(buf, " --:-- ETA", win_size);
else {
@@ -219,10 +222,14 @@
if (bytes_left > 0)
strlcat(buf, " ETA", win_size);
else
- strlcat(buf, " ", win_size);
+ strlcat(buf, (progresstype)?" done":" ", win_size);
}

- atomicio(vwrite, STDOUT_FILENO, buf, win_size - 1);
+ if (progresstype) {
+ strlcat(buf,"\n",win_size);
+ atomicio(vwrite, STDOUT_FILENO, buf, strlen(buf));
+ } else
+ atomicio(vwrite, STDOUT_FILENO, buf, win_size - 1);
last_update = now;
}

@@ -234,7 +241,7 @@

save_errno = errno;

- if (win_resized) {
+ if (progresstype==0 && win_resized) {
setscreensize();
win_resized = 0;
}
@@ -257,12 +264,16 @@
stalled = 0;
bytes_per_second = 0;

- setscreensize();
+ if (progresstype)
+ win_size=MAX_WINSIZE;
+ else {
+ setscreensize();
+ signal(SIGWINCH, sig_winch);
+ }
if (can_output())
refresh_progress_meter();

signal(SIGALRM, update_progress_meter);
- signal(SIGWINCH, sig_winch);
alarm(UPDATE_INTERVAL);
}

@@ -278,7 +289,8 @@
if (cur_pos != end_pos)
refresh_progress_meter();

- atomicio(vwrite, STDOUT_FILENO, "\n", 1);
+ if (progresstype==0)
+ atomicio(vwrite, STDOUT_FILENO, "\n", 1);
}

/*ARGSUSED*/

Setting permissions of ssh access

2009-10-23T12:28:57Z

Hello, I've looked around and found a few different approaches to
this. Looking for a discussion of the pros, cons, and best practices.

I want to use rsync over an ssh connection to clone one machine to
another. This means one end will need root login.

Right now I have passwordless keys to allow myself to login. Root
login is disabled.

Would an acceptable method be to allow root login from a specific IP
address? Or is there some other way to allow root privilege use
between a source and destination host without opening it up by IP?

This is for backups, and only ever will be machine to machine, same
subnet. I'm not immediately seeing how to set granular permissions
based on conditions like IP, MAC, or other harder to spoof credentials.

I'd it better to pull backups or push backups, or equivalent?

The backup machine could be made to have no public access at all.
Thanks for any pointers.

--
Scott
Iphone says hello.

Re: remote port forwarding unstable

2009-10-21T02:31:24Z

On Tue, Oct 20, 2009 at 7:03 PM, Quintin Beukes <quintin@...> wrote:
> Hey,
>
> How do you close the console? And, can you share the command with the
> list please.

The reason I'm asking this is that the fact it is a bind: address
already in use error, means the bind() call failed. So according to
the networking stack that port is still bound. A netstat command on
the remote server should definitely show this. The commands Greg
listed (the lsof -i :1026 and netstat -antp) will give you this
information.

Remember to run the 2 commands as root (lsof needs to be root, and for
netstat's -p to work as well).

Further, you can also try: netstat -antpl | grep :1026
This will filter into only showing matching listening ports. I often
do this because it's so easy to miss it among all those ports.

Q

Re: remote port forwarding unstable

2009-10-20T23:16:19Z

Thank you all for your replies :)

This is the command i use: ssh -L 30300:localhost:8080 -R
1026:localhost:55555 -F ssh_config -N ipp@...
And i close the ssh process by closing the windows console, or by
killing the ssh process from another application. Either way when i
look in processes list after closing ssh process is gone when i try to
reconnect again.

I guess that's the explanation suggested above why sometimes it
doesn't allow me to reconnect with same port, TCP connection staying
in a wait state even after previous ssh client process terminates and
it keeps that remote port busy.
Maybe that's why it didn't showed with "netstat -an" command.
Next time i will use the other commands suggested :)

Thank you again,
Adriana

Re: remote port forwarding unstable

2009-10-20T10:15:08Z

On Tue, Oct 20, 2009 at 08:53:49AM +0300, Adriana Rodean wrote:
> IPP-Linux:~# cat /var/log/auth.log | grep 18737
> Oct 19 13:37:47 IPP-Linux sshd[18737]: error: bind: Address already in use
> Oct 19 13:37:47 IPP-Linux sshd[18737]: error:
> channel_setup_fwd_listener: cannot listen to port: 1026
>
> But i closed the previous console with ssh listening to that port, and
> is no ssh process on client when i want to connect again on the same
> port. So how come it still says that port is in use on server?

Use "lsof -i :1026" (lsof is not standard, but it's very common)
or "netstat -antp | grep :1026" (netstat -p is Linux only) to see what
is listening on port 1026.

Re: remote port forwarding unstable

2009-10-20T10:03:37Z

Hey,

How do you close the console? And, can you share the command with the
list please.

For some reason replying on this list does so to the sender and not to
the list by default. So the list didn't receive the reply you did.

Quintin Beukes

On Tue, Oct 20, 2009 at 7:53 AM, Adriana Rodean <adrya1984@...> wrote:

> Hi,
>
> Here is some more info after little investigation :)
>
> Message i get is: "Warning: remote port forwarding failed for listen port 1026"
>
> SSH makes connection but port isn't opened and in server logs i see:
>
> IPP-Linux:~# cat /var/log/auth.log | grep 18722
> Oct 19 13:37:20 IPP-Linux sshd[18722]: error: bind: Address already in use
> Oct 19 13:37:20 IPP-Linux sshd[18722]: error:
> channel_setup_fwd_listener: cannot listen to port: 1026
> IPP-Linux:~# cat /var/log/auth.log | grep 18737
> Oct 19 13:37:47 IPP-Linux sshd[18737]: error: bind: Address already in use
> Oct 19 13:37:47 IPP-Linux sshd[18737]: error:
> channel_setup_fwd_listener: cannot listen to port: 1026
>
> But i closed the previous console with ssh listening to that port, and
> is no ssh process on client when i want to connect again on the same
> port. So how come it still says that port is in use on server?
>
> This happens in only 2% of the cases, very rare, i change nothing in
> the way i connect or close the client, but somehow it seems that port
> still hangs on server after closing ssh console ... or at least that's
> what sshd says because with "netstat -an" i don't see that port busy
>
> Thank you Rabbi for that command, next time when it happens i'll use it :)
>
> Thanks,
> Adriana
>

Re: Manipulating Forwards on an existing shell

2009-10-20T00:53:46Z

I know -D (socks) and ~C (then -Lx:y:z), which is what I use
currently. And I have to use normal port forwards.

What I'm looking for is to make this easier with a zenity dialog at
the click of a button, then have to terminal pipe somewhere and become
a background process.

Is there perhaps some options I can supply to SSH so it accepts ~C
(then the options + \n) from stdin?

Quintin Beukes

On Tue, Oct 20, 2009 at 4:11 AM, Darren Tucker <dtucker@...> wrote:

> Quintin Beukes wrote:
>>
>> Is there any way at all to manipulate local forwards on an existing
>> shell?
>
> Use the ~C escape, which is documented in ssh(1) thusly:
>
> ~C Open command line. Currently this allows the addition of port
> forwardings using the -L, -R and -D options (see above). It also
> allows the cancellation of existing remote port-forwardings using
> -KR[bind_address:]port. !command allows the user to execute a
> local command if the PermitLocalCommand option is enabled in
> ssh_config(5). Basic help is available, using the -h option.
>
> Depending on what you're doing, you may be better served by
> -D/DynamicForward which allows you to use SOCKSified clients rather than
> created new (local) forwards for each purpose.
>
> --
> 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: remote port forwarding unstable

2009-10-19T22:53:49Z

Hi,

Here is some more info after little investigation :)

Message i get is: "Warning: remote port forwarding failed for listen port 1026"

SSH makes connection but port isn't opened and in server logs i see:

IPP-Linux:~# cat /var/log/auth.log | grep 18722
Oct 19 13:37:20 IPP-Linux sshd[18722]: error: bind: Address already in use
Oct 19 13:37:20 IPP-Linux sshd[18722]: error:
channel_setup_fwd_listener: cannot listen to port: 1026
IPP-Linux:~# cat /var/log/auth.log | grep 18737
Oct 19 13:37:47 IPP-Linux sshd[18737]: error: bind: Address already in use
Oct 19 13:37:47 IPP-Linux sshd[18737]: error:
channel_setup_fwd_listener: cannot listen to port: 1026

But i closed the previous console with ssh listening to that port, and
is no ssh process on client when i want to connect again on the same
port. So how come it still says that port is in use on server?

This happens in only 2% of the cases, very rare, i change nothing in
the way i connect or close the client, but somehow it seems that port
still hangs on server after closing ssh console ... or at least that's
what sshd says because with "netstat -an" i don't see that port busy

Thank you Rabbi for that command, next time when it happens i'll use it :)

Thanks,
Adriana

Re: Manipulating Forwards on an existing shell

2009-10-19T19:11:58Z

Quintin Beukes wrote:
> Is there any way at all to manipulate local forwards on an existing
> shell?

Use the ~C escape, which is documented in ssh(1) thusly:

~C Open command line. Currently this allows the addition of port
forwardings using the -L, -R and -D options (see above). It also
allows the cancellation of existing remote port-forwardings using
-KR[bind_address:]port. !command allows the user to execute a
local command if the PermitLocalCommand option is enabled in
ssh_config(5). Basic help is available, using the -h option.

Depending on what you're doing, you may be better served by
-D/DynamicForward which allows you to use SOCKSified clients rather than
created new (local) forwards for each purpose.

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

Manipulating Forwards on an existing shell

2009-10-19T13:01:04Z

Hey,

Is there any way at all to manipulate local forwards on an existing
shell? I basically have a script which I run to setup a bunch of port
forwards to create a pseudo-VPN. It's much stabler through SSH than it
is through our PPTP VPN. So it would be nice to create a zenity script
to setup instant forwards without having to first close SSH and reopen
it. To establish the connection takes quite long due to the
authentication, where creating a new forward is almost instantaneous.
Further I will also not loose my existing connections.

My SSH version: OpenSSH_4.7p1 Debian-8ubuntu1.2, OpenSSL 0.9.8g 19 Oct 2007

It doesn't really matter if the only way to do it is dirty, because
I'm not really aiming at portability. It's mostly only for me to use
on my home machines.

Quintin Beukes

remote port forwarding unstable

2009-10-19T05:31:39Z

Hi,

I'm not sure if this is a bug or not, maybe someone noticed it also...

I always do a remote port forwarding with openssh on 1026 port let's
say ( ssh -R 1026:localhost:55555 ). Most times the port is opened on
remote machine. But sometimes i notice that ssh can't do remote port
forwarding to that port 1026. I looked on the remote machine (netstat
-an) and no one is using that port, so the port is free.
Only way to fix this is do a remote port forwarding to another port
lets say 1056, successfully done, then try again and do it for 1026,
this time remote port forwarding successfully works... Sometimes it
works if i try again with 1026, but other times i need to open another
port then try again with 1026 port...

What can cause this instability to remote port forwarding?
Is there another command than "netstat -an" to see if that port is
really free or something is using it?
If is a bug can it be fixed?

I use version of OpenSSH 5.1p1 on remote machine and the client is
OpenSSH for Windows 3.8.1p1

Thanks in advance,
Adriana

Re: ssh and netcat

2009-10-14T11:02:05Z

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

attachment0 (196 bytes) Download Attachment

Re: ssh and netcat

2009-10-07T09:03:30Z

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?

Re: ssh and netcat

2009-10-05T15:53:27Z

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

2009-10-05T10:05:15Z

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

ssh and netcat

2009-10-02T17:00:21Z

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?