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