#698390 autossh: init.d script

Package:
autossh
Source:
autossh
Description:
Automatically restart SSH sessions and tunnels
Submitter:
Lluís Gili
Date:
2014-07-26 11:45:10 UTC
Severity:
wishlist
#698390#5
Date:
2013-01-17 20:48:48 UTC
From:
To:
Package: autossh
Severity: wishlist
Tags: patch

The maintainers of the autossh package received the attached mail.
Forwarding it to the BTS to better be able to track this.

		Regards, Axel

#698390#12
Date:
2014-07-24 14:34:30 UTC
From:
To:
Hello autossh maintainers,

Just wanted to express my support for including the patch in the
autossh package.  I was about to write an initscript for autossh for
my  own use before finding this bug report, but I've found the
attached script serves my purposes quite well and the quality seems
very good to me.  I'm sure other users from benefit from it as well.

If it's not worth installing the init script by default, I'd recommend
including it in /usr/share/doc/autossh/examples as a reference.

The only suggestion I have is to avoid calling not_configured in the
init script when $START is 0, especially if the init script is
installed by default.  Users who do not want to run autossh as a
daemon are unlikely to want to see an attention-grabbing 3-line
warning about it on every boot.  Convention seems to be to print a
single-line "Starting autossh: not configured" or similar.

Thanks for considering, and thanks to Lluís for writing it,
Kevin

#698390#17
Date:
2014-07-24 15:03:46 UTC
From:
To:
Hi Kevin and Lluís,

Kevin Locke wrote:

I must admit that I'm reluctant to add an init script as I consider
automatically starting ssh sessions at boot up as something very
seldom (and IMHO dangerous).

Then again I see that if you really want such a thing, autossh would
be very helpful.

That's a good idea!

Indeed.

		Regards, Axel

#698390#22
Date:
2014-07-24 15:14:43 UTC
From:
To:
Hi Axel,

Agree that it's likely rare.  I'm basically using it as a poor-man's VPN
to port-forward for a special-case application for a limited time.

But I'm curious why it might be dangerous.  Is it a security concern or
from a connection-stability perspective?  Could be worth adding a
comment to the docs to warn users against it if there's a common issue
that it introduces.  (I'm hardly an expert, but try not to compromise my
systems too horribly.)

Works for me.

One other note change that would probably be worth making would be to
run autossh as a user other than root.  It's hard to make this generic
since the sysadmin will likely want to create an unprivileged user and
install SSH keys for it to use.  Perhaps another motivation for putting
it in the examples with some usage notes.

Thanks,
Kevin

#698390#27
Date:
2014-07-24 15:33:05 UTC
From:
To:
Hi Kevin,

Kevin Locke wrote:

Security concern. Starting SSH sessions from init scripts will need
SSH keys without passphrase. IMHO this always needs much care so that
the private key can't do much harm if leaked.

Yes, I'll likely add something like that.

Hrm. Maybe in that case a user cron job with @reboot may be an easier
way?

		Regards, Axel

#698390#32
Date:
2014-07-24 15:49:36 UTC
From:
To:
Right.  Good point.

Sure, that could work.  It might be a little more difficult to manage
(for runlevels and starting/stopping it).  Tradeoffs.  I was thinking
about adding the --user option to start-stop-daemon with a $USER that
the sysadmin could set.  But I didn't mean to keep adding to the amount
of work needed to get this into the package.  I'm sure it would be a
useful reference even in the current state.

Thanks again for considering all of this,
Kevin

#698390#37
Date:
2014-07-26 11:05:37 UTC
From:
To:
Hi all,

please take a look at this initscript with readme that includes separate
system UID/GID at both server and client machines and a very restricted
authorized_keys entry:
https://github.com/obfusk/autossh-init

IMO it eliminates at least some of the security concerns and it suits my
usecase (a server behind a poorly managed firewall needs to be accessed
via SSH, on init it connects an accessible server and creates an -R
localhost:X:localhost:22 tunnel).

It would be very convenient to have the system user/group and its
private ssh key created with package installation, maybe in a separate
package. In case you are willing to accept this but not to implement it,
I might send a patch. Thanks for considering.

Regards,
Pavel