SSH and screen, better together

I've just recently put some pieces together in my head, and have found this to be a very useful invocation to run in a Terminal window on my PowerBook:

while [ 1 ]; do ssh -t home '/usr/sbin/screen -R work'; done

(Update: Thanks to a comment by Leland Johnson, I've realized that the above just poorly reinvents autossh. Use it instead.)

Behind the scenes, here's what's up:

The end result is that I always have a window with a few shells open on a machine at home, as well as a slew of ports tunneled to machines back home to provide a rough sort of VPN. The connection is usually reestablished and waiting by the time I've gotten settled and get around to visiting that window.

Archived Comments

  • A great tip.

    Speaking of this, I was messing around the other day and found that it's really easy to create VIPs in OS X. Combine your above example with these directions for creating VIPs and you can set up a pretty functional VPN. I create VIPs for the hosts that are most interesting at work and have a custom hosts file map the work hostnames to the local IPs. Then when I open the tunnel with ssh I bind to the VIP IPs. It takes a little while to set everything up but the result is very nice.

    I'm in the process of building up a simple config file syntax for specifying which hosts/ports should be tunneled and a little script that does all the dirty work of creating the VIPs and opening the ssh connection.

  • Hmm... I see how to create a VIP, but what do you do with it once you have it—with respect to SSH tunnels, that is? Could you stick an SMB tunnel there on port 139, say, and keep it separate from port 139 on localhost?

  • Oh, duh, that's exactly what your links says:

    Now you have another IP that you can bring stuff up on that won't collide with other stuff running on the same port.

  • Right, right. Basically I can make it look like a small subset of the work LAN with just VIPs, hosts file modification, and ssh tunnels.

    So say I have two boxes at work - work-box-1 and work-box-2, running SMB and a web server, respectively. I create a host file that points the host names to IPs on my home lan:

    /etc/hosts.ssh-vip-vpn:

     192.168.1.130  work-box-1
    192.168.1.131  work-box-2
    

    Next, I have a little script that ups the VIPs using ifconfig, symlinks the hosts file, and opens the tunnels:

    ~/bin/open-vpn:

    #!/bin/bash
    ifconfig en1 inet 192.168.1.130 netmask 255.255.255.255 alias
    ifconfig en1 inet 192.168.1.131 netmask 255.255.255.255 alias
    ln -s /etc/hosts /etc/hosts.ssh-vip-vpn
    ssh -L192.168.1.130:445:real-work-ip1:445 \
    -L192.168.1.130:137:real-work-ip1:137 \
    -L192.168.1.131:80:real-work-ip2:80 external-work-hostname
    

    The cool thing is that everything pretty much looks exactly as it does at work. It's quite a lot to maintain and a real VPN would be a ton easier but what fun is that?

  • Just FWIW, the idiomatic way to express an infinite loop in sh is

    while : ; do foo ; done
    

    According to bash(1):

    : [arguments]
    

    No effect; the command does nothing beyond expanding arguments and performing any specified redirections. A zero exit code is returned.

  • Ryan: Swank--I'll have to tinker around with this bit of scripting to see how I can improve my masochistic semi-VPN :)

    Aristotle: Thanks for the pointer. I think while [ 1 ] is just one of those things I came to by trial-and-error.

  • Ryan: try vtun over SSH. It's a dead simple VPN system. There's a page on running vtun on OS X, though I don't know if it's up to date.

  • Why not use autossh? Instead of waiting for the connection to time out, it will know almost immediately. It also includes a script for doing exactly the same thing you do here (except with autossh of course).

  • Leland: Well, hey, whadda ya know? I'd never seen autossh before—it looks like exactly what I need. And it compiled on my PowerBook. Thanks for the pointer!

    I think I like this blogging thing. :)

  • I don't understand what you use this or autossh for could you please explain how it works?

    Do you run it on the computer you want to connect to or on the computer you are connecting from? I understand the screen part, that just allows your terminal session to keep running when the terminal is disconnected. Why do you need to force on this persistent connection?

  • Nathan: Well, the thing is that I'm doing all of this on a PowerBook which travels with me between home / work / coffee shop. I close it up, leave home, open it up on a new network. Repeat at least twice a day.

    What autossh does is start an SSH connection and monitor it continuously to be sure it's up. If the connection ever goes down, autossh starts it up again.

    So, instead of the usually SSH command to connect to a server at home, I use autossh. When I open my PowerBook in a new location, autossh sees that it's lost the connection to home and automatically reconnects. This way, I always have a terminal window to home—along with a handful of forwarded ports—even after travelling between networks. And, since I'm running screen at home, everything I was doing before travelling is all in the same state I left it.

  • OK, Thank you. So it just saves you the hassle of having to reconnect to your remote session manually.

    You might look at this program AlmostVPN. I have been trying to figure out how to use it because my school has a server that us students are allowed to use to compile things and what not. But it also stores all our files on it so I have been trying to setup [AlmostVPN][2] to forward the Apple File Share that has our home directories on it. Unfortunately, I have not gotten it to work yet, but that is mostly because I have very limited knowledge of SSH. I use it in place of telnet but that is all I know how to do right now.

Intelligent Design and the cessation of naming of things  Previous Chewbacca's a pervert Next