2718.us blog » ssh

OS X, Wake-on-LAN, and Passworded Screensavers

2718.us — Wed, 13 Aug 2008 20:35:04 +0000

The other day, I realized while I was at work that I needed some files from my Mac desktop at home. Normally, no problem, ssh into my firewall and open a tunnel to my desktop (this is better done with authpf, but that’s a post for another time), use sftp, and done. The problem is that because of unexplained kernel panics (probably a bad RAM module), my desktop would crash hard if left on all day, so I’ve been putting it to sleep when I go to work. Now, with my Mac set to wake for remote admin access, I ought to be able to run a wake-on-LAN utility to wake it up and be fine, except that I use a passworded screensaver. With a passworded screensaver, waking the machine locally or remotely will give 30-60-second window during which the computer is awake and expecting a password to be entered at the physical machine; there doesn’t seem to be a way to do this remotely and unlike earlier versions of OS X, since 10.3 or 10.4 or so, you can’t just kill the screensaver process from the command line (i.e. by logging in with ssh).

On the other hand, ssh is a very robust protocol and somehow ssh sessions seem to readily survive disconnect/reconnect cycles. Making use of this, it is possible to get a workable, if slow, connection to a passworded-and-sleeping Mac. On one connection to the firewall machine, run a loop of the wake-on-LAN command so that the magic packets that make the Mac wake are being sent every second or so. Use another connection to ssh into the Mac and do whatever you need to do. It helps to plan out what you need to do so that you can get the commands in fast, but even during the cycle where the Mac goes back to sleep and gets reawakened by the wake-on-LAN loop, you can type commands; they just won’t appear (not even echoed) until ssh recovers the connection.

While this is an annoying way to use a machine and it’s probably not good for the hardware to cycle in and out of sleep repeatedly in such a short time span, it does give a way to get at a passworded and sleeping Mac remotely.

Steps to “Unsling” the NSLU2

2718.us — Mon, 14 Jul 2008 00:39:33 +0000

Since I’m on my second of what will probably be 4 or 5 unslung NSLU2 “slug” units (with identical 1GB flash drives from eBay), I figured it was time to write down specific step-by-step directions, if perhaps only for my own use later. (As an aside, having the two ethernet ports on my Mac Pro is really helpful at times like this when I’m monkeying around with some piece of hardware that doesn’t do DHCP out of the box, forcing me onto some specific subnet.) CAUTION: I take absolutely no responsibility for what you may do to your hardware/software/life/etc. if you follow these directions. You should read lots of other, more thorough instructions like the how-to’s at the Unslung HomePage.

Verify that the slug can do Reset Button Upgrade Mode.
Get the Unslug firmware.
On the admin web page for the slug (default IP is 192.168.1.77), go to Administration > Advanced > Upgrade (default username/password is admin/admin), browse to the unslung firmware, and do the upgrade. (This step takes a few minutes.) Wait for the reboot.
Verify that the admin web page now shows the unslung firmware version.
Do any network config you need (set IP address, etc.)—avoid DHCP as it doesn’t seem to work (the slug does a DHCPDISCOVER, my server(s) do DHCPOFFER, but the exchange goes no further).
Enable telnet access (Home > Manage Telnet). Note that this must be done before any disks are connected.
Telnet into the slug (username/password is root/uNSLUng). Keep this session open through the next steps, so there’s guaranteed root access.
Plug the 1GB flash drive into the upper USB port (closer to the ethernet jack).
Once the slug recognizes the disk, go to Administration > Advanced > Disk and format the flash drive (Disk 2). This again takes several minutes (especially with the cheapo slow 1GB flash drives I’m using). When the page shows “Formatted (EXT3)” for Disk 2, it’s ready for the next step.
In the telnet session from step 7, type “unsling disk2″. Enter a new root password here.
Reboot by typing “DO_Reboot” in the telnet session. The device will beep when it’s fully booted.
Go to the admin web page and verify that it says “uNSLUng status: Unslung to disk2, /dev/sda1″ in the bottom blue bar.
Enable telnet again and connect to the device again, verifying that the “NOTE: THIS SYSTEM IS CURRENTLY UNSLUNG” banner shows upon login.
Run “touch /.ext3flash” so that (after the next boot) the OS will try not to thrash the flash drive.
Verify internet connectivity (e.g. ping google.com).
Run “ipkg update” to update the package system.
Run “ipkg install openssh” so we can get to the slug without having to enable telnet.
Verify that SSH works by logging into the slug over SSH. Disable telnet.
Run “ipkg install openssh-sftp-server” so we can use SFTP to edit files on the slug.
Set the admin web page password (it is independent of the root password).

Other notes:

The MAC address label on the bottom of the device is the default device name and seems to be “LKG” + the latter half of the MAC address; it seems that the correct MAC address is found by replacing “LKG” with “00:18:39″.

SSH Tunneling on a Mac

2718.us — Fri, 13 Jun 2008 22:55:27 +0000

Since my employer’s wireless network is unencrypted and since I use other open WiFi networks with some frequency, I’ve gotten in the habbit of tunneling everything through SSH, using the SOCKS5 proxy mechanism built in to SSH. In WinXP, there’s a nice little program called Tunnelier that makes the setup of the tunnel simple and it reconnects automatically, so the tunneling part is virtually automatic (even though proxy setup is still tricky and/or annoying).

On the Mac, however, I have tried several programs and never really been happy. So I wrote a little AppleScript that not only sets up the SSH tunnel, but also deals with switching my location to set the system’s network settings to use the proxy (the code is after the cut). Combine this with System Proxy for Firefox and all my application traffic goes through the SSH tunnel. Note also that if you’re using a SOCKS5 proxy with Firefox, you probably want to set it to do DNS lookups through the proxy.

This script also stores the info for creating the tunnel (server, login, pw) in the keychain.

Here’s the “library” script where I put the functions to do the underlying work (since I have various different tunnels I use):

on startTunnel(targetServer) –returns PID of ssh for killing later
tell application "Keychain Scripting"
set sshTunnelKeys to every Internet key of current keychain whose (name is "autoSSHTunnel") and (server is targetServer)
if sshTunnelKeys is {} then
set sshKey to my makeSSHKeyWithServer(targetServer)
else
set sshKey to item 1 of sshTunnelKeys
end if
set user to account of sshKey
set passwd to password of sshKey as string
set sshHost to server of sshKey as string
end tell
set sshCommand to "ssh -fND 9999 " & user & "@" & sshHost
set expectScript to "spawn " & sshCommand & "
expect assword
send \"" & passwd & "\\n\"
sleep 1"
do shell script "/usr/bin/expect -c '" & expectScript & "' &>/dev/null &"
set tries to 0
repeat
set tries to tries + 1
try
set sshPIDstring to (do shell script "sleep 1;bash -c 'ps ax -o pid,tt,command | grep \"??\" | grep \"" & sshCommand & "\" | grep -v grep | grep -v expect'")
set sshPID to first word of sshPIDstring
set gotPID to true
on error
set gotPID to false
end try
if gotPID then
exit repeat
end if
if tries > 10 then
exit repeat
end if
end repeat
if gotPID then
return sshPID
else
return false
end if
end startTunnel
on setUseTunnel()
do shell script "scselect 'Use SOCKS5 Proxy on localhost:9999'"
end setUseTunnel
on clearUseTunnel()
do shell script "scselect 'Automatic'"
end clearUseTunnel
on stopTunnel(pid)
do shell script "kill " & pid
end stopTunnel
on makeSSHKeyWithServer(targetServer)
tell application "Keychain Scripting"
repeat
set acctBox to display dialog "Enter your SSH login for host " & targetServer & ":" default answer "" buttons {"Cancel", "OK"} default button 2
set myAcct to the text returned of acctBox
set myButton to the button returned of acctBox
if myButton is "Cancel" then
–quit
else
if myAcct is not "" then
exit repeat
else
display dialog "bad login"
end if
end if
end repeat
repeat
set passBox to display dialog "Enter your password:" default answer "" buttons {"Cancel", "OK"} default button 2 with hidden answer
set myPass to the text returned of passBox
set myButton to the button returned of passBox
if myButton is "Cancel" then
–quit
else
if myPass is not "" then
exit repeat
else
display dialog "can't use blank passwd"
end if
end if
end repeat
set newSSHKey to make new Internet key with properties {name:"autoSSHTunnel", account:myAcct, password:myPass, server:targetServer, authentication:default, protocol:SSH}
end tell
return newSSHKey
end makeSSHKeyWithServer

And here’s the actual script I run.

property Lib : (path to scripts folder from user domain as text) & "Script Library:"
property sshTunnelLib : load script Lib & "ssh_tunnel.scpt" as alias
sshTunnelLib's setUseTunnel()
set sshPID to sshTunnelLib's startTunnel("fqdn.of.your.server")
if sshPID is not false then
set noPIDtxt to ""
set buttonTxt to "Kill SSH and Exit"
else
set noPIDtxt to " (but couldn't get PID)"
set buttonTxt to "Exit"
end if
display dialog "SSH-tunneled SOCKS5 proxy running on localhost:9999" & noPIDtxt buttons {buttonTxt}
if sshPID is not false then
sshTunnelLib's stopTunnel(sshPID)
end if
sshTunnelLib's clearUseTunnel()

Trying for more than Just a Home Network

2718.us — Sat, 17 May 2008 20:50:59 +0000

The OpenBSD router machines I installed at my place and my parents’ have been failing and I’ve been doing band-aid fixes of little things as they break, but it’s annoying. My new idea is to use hardware routers, but to install one or more “slug” NSLU2 devices, unslung, inside each network to provide DNS and DHCP (more than one should easily give redundancy). At $50-60 on eBay and potentially running some variant of Linux from a small USB flash drive, it should be reasonable to set up two identically-configured “slugs” so that if one goes bad, the other can handle the load until the bad one can be replaced. My first NSLU2 for testing should arrive in the middle of this coming week. Details on the previous setup and history after the cut.

Since the point where both my parents and I had DSL, I’ve been fiddling with ideas of how to make it easier to share files across our two networks, easier for me to debug issues on their computers, and, well, just more technologically cool. About a year and a half ago, I replaced the D-Link routers at both sites with a matched pair of used Dell business machines I’d bought on eBay, outfitted with OpenBSD (by far the best OS for trying to run a secure gateway). This seemed to fit the bill, as it enabled me to more easily connect to my home network from elsewhere without opening up any of my internal machines directly to the outside world, it allowed me to similarly access my parents’ network without exposing any of their internal machines, and (at the peak of its working-ness) we had an encrypted VPN unifying the two sites so I could connect to shared drives on their machines and print to their color laser printer as if all those devices were on my own network.

But somewhere along the way, things started to go south. A few months ago, the gateway router Dell box on my end died–just wouldn’t power up anymore. I swapped in an old D-Link hardware router to keep my internet access up and I’ve been working on an Alix unit to replace it, but getting OpenBSD properly tweaked to run off a compact flash card took some time and I still haven’t quite gotten that install happy with PPPoE DSL connections, so it’s still not in place.

Now, making things worse, the machine at my parents’ place isn’t working quite right. After an extended power failure that wore through the UPS, the machine appears to start up (even sounds right when I stood there and watched it “boot”), but it never shows up on the network, much less makes the DSL connection and joins the network to the DSL. This led to a similar swap-in of a spare hardware router unit at their place. Unfortunately, things got messier for them.

These OpenBSD machines I’d been using as routers on both ends had also been running DHCP and DNS for the internal networks and while my internal network had a second OpenBSD box that was able to step in and take over the DNS (it was already serving as a secondary DNS server) and the DHCP (it had been doing DHCP before I got the other machines), my parents’ network had no such machine. Suddenly, lots of things stopped working correctly. Printing over the network didn’t work because the IP printing port in Windows was trying to use the (former) FQDN of the printer, or maybe even its old IP address. This is what got me looking at the slug.