Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Autossh – automatically restart SSH sessions and tunnels

github.com

Post reply on HN
Print view View original

21–30 of 90 posts

Re: Autossh – automatically restart SSH sessions and tunnels

#21

Post by snailmailman »

amlib wrote: post #12
isoprophlex wrote: post #8

Not 100% the same use case as autossh was built for maybe, but I'm now simply throwing tailscale on every box i need to interact with. Does away with all the port forwarding stuff, it's absolutely delightful.

How much reliance on third party am I subjecting myself by using Tailscale? What happens if I make a local connection to a machine/service running on Tailscale, does it still go out of the local network? If so, is the bulk of the payload transferred locally? Is there any advantage on using it if the machine/service is easily accessible over ipv6?

It will route directly over the local network when possible.

It will be encrypted through the VPN, so there will be some overhead. But will be as direct as it can be. It only routes through tailscales servers as a last resort, when it can’t find a direct route at all (usually because NAT holepunching fails somehow). Their “DERP” relay servers just relay the encrypted connection. I think you can use your own relay servers, but I don’t know if that feature can be disabled entirely.

Headscale can be entirely self-hosted. It still uses the tailscale client applications- but is compatible.

Re: Autossh – automatically restart SSH sessions and tunnels

#22

Post by amelius »

Nice tool, but I'm getting tired of using port numbers for everything instead of more descriptive strings. My system has more than 10 tunnels and servers running, and since I only do sysadmin work once every half year or so, the port numbers are very cumbersome to deal with.

Re: Autossh – automatically restart SSH sessions and tunnels

#23

Post by beagle3 »

frizlab wrote: post #14

How is this different from this ssha () { while true do ssh "$@" sleep 1 done true } EDIT: Oh I think I know, autossh must be detecting when the connexion is closed but ssh does not automatically…

Ssh does with the right settings and has for about a decade - see the systemd example someone posted above.

Re: Autossh – automatically restart SSH sessions and tunnels

#24

Post by leetrout »

r0n22 wrote: post #10
leetrout wrote: post #9

I used autossh to do terrible things securing redis back in 2013. Fantastic tool.

Ohh tell me more?

Way back redis didnt have passwords at all. That got added but there was no secure transport support.

So I ran redis in a higher memory box at rackspace separate from my db and my app server. I used autossh to forward 6379 from localhost on the app server(s) to the redis server. Worked like a charm and never caused any issues.

Other commenters are right in that wireguard is a great modern solution to this!

Re: Autossh – automatically restart SSH sessions and tunnels

#27

Post by isoprophlex »

amlib wrote: post #12
isoprophlex wrote: post #8

Not 100% the same use case as autossh was built for maybe, but I'm now simply throwing tailscale on every box i need to interact with. Does away with all the port forwarding stuff, it's absolutely delightful.

How much reliance on third party am I subjecting myself by using Tailscale? What happens if I make a local connection to a machine/service running on Tailscale, does it still go out of the local network? If so, is the bulk of the payload transferred locally? Is there any advantage on using it if the machine/service is easily accessible over ipv6?

good questions, pretty well answered by other commenters. if you are happy with the level of encryption you have on your 'plain' ipv6 connection, sure, use that.

additionally the acl/auth system, their dns and service discovery thing is nice, though not essential.

Re: Autossh – automatically restart SSH sessions and tunnels

#28

Post by 8xeh »

xk3 wrote: post #6

If you have systemd, you could do this: [Unit] Description=look ma, no autossh After=network.target [Service] Type=exec ExecStart=/usr/bin/ssh -o ServerAliveInterval=60 -o ExitOnForwardFailure=yes -Nn -R 7070:localhost:22 pc 'sleep 20m' Restart=always RestartSec=20 RuntimeMaxSec=30m [Install] WantedBy=default.target

This approach works very well. I've had dozens of extremely remote systems hooked up this way for about 8 years. The only problem I've seen is that occasionally the server ssh process will get stuck, so you have to log in to the server and kill it. It seems to happen when a remote goes offline and reconnects without closing the old connection first.

If I were doing it now, I'd probably use wireguard, probably. This is simpler to set up and works great.

Re: Autossh – automatically restart SSH sessions and tunnels

#29

Post by jclulow »

amelius wrote: post #22

Nice tool, but I'm getting tired of using port numbers for everything instead of more descriptive strings. My system has more than 10 tunnels and servers running, and since I only do sysadmin work once every half year or so, the port numbers are very cumbersome to deal with.

I believe these days SSH is willing to forward a UNIX domain socket to a remote TCP port, or a local TCP port to a remote UNIX domain socket, or any combination of the two families really. You could use names locally, if your client tools are willing to do AF_UNIX!

Re: Autossh – automatically restart SSH sessions and tunnels

#30

Post by mjw1007 »

jclulow wrote: post #29
amelius wrote: post #22

Nice tool, but I'm getting tired of using port numbers for everything instead of more descriptive strings. My system has more than 10 tunnels and servers running, and since I only do sysadmin work once every half year or so, the port numbers are very cumbersome to deal with.

I believe these days SSH is willing to forward a UNIX domain socket to a remote TCP port, or a local TCP port to a remote UNIX domain socket, or any combination of the two families really. You could use names locally, if your client tools are willing to do AF_UNIX!

The nice thing about this is that, with filesystem permissions on one end and a check for SCM_CREDENTIALS or SO_PEERCRED on the other, you can effectively get user-based access control working between two machines.

I think this is the one remaining advantage of ssh tunnels over using a VPN.

NB if you're doing this sort of thing, you probably want to add `StreamLocalBindUnlink yes` to the ssh options.

Post reply on HN