SSH into a wireless Cube before OSX login???

[mwnovak]

Here's the deal...

I have a G4 Cube (running 10.3.7) connected wirelessly to my home network. The Cube runs its AirPort card; the router is a NetGear WGR614. Remote Login is enabled on the Cube.

If I boot the Cube and log into OSX, I can SSH into Darwin from another machine.

If I boot the Cube, log in and wait for the UI to load, and then immediately log out, I can still SSH into it.

However, if I simply boot the Cube and leave it at the OSX login screen, I CANNOT get into Darwin via SSH.

As a test, I temporarily connected the Cube to my router via ethernet and ran through each of the above tests again. Using the ethernet connection, I can SSH into the Cube at all times... even if the Cube has been freshly booted and is sitting at the OSX login screen.

Note that all SSH scenarios discussed above are contained within my home network: nothing is coming from outside the router. I've also run through each test with the Cube's firewall completely disabled and get the same results.

It seems like the Cube's ethernet interface is initialized and ready to go at system startup, whether or not anyone has logged into OSX. The wireless interface, on the other hand, doesn't appear to start until _after_ a user logs into the GUI... and then it remains persistent from that point forward, even if the user logs out.

I want to be able to SSH into the Cube, regardless of whether or not a user has previously logged in via OSX. I think my problem boils down to initializing the wireless network services _before_ any user logs into the machine (i.e. at the same time the system initializes the ethernet interface).

Is that possible? Does anyone know how?

Any help would be greatly appreciated.

--MW

[hayne]

Your diagnosis seems accurate given what you have seen.
I'm not sure but maybe this has something to do with the Airport preferences (e.g. which network to connect to, what password, etc) being per-user? (Are they per-user?)

You could confirm your diagnosis by looking at the messages in system.log - you should see messages when the Airport network is attached to. Look to see at what time that is.

You might be able to add a StartupItem to attach to an Airport network.

[mwnovak]

I plugged my PB into the Cube via ethernet, booted the Cube, and SSH'd in from the laptop to check the system.log. I'm not sure exactly what I'm looking for, but it _seems_ to confirm my suspicions.

For boots with the ethernet connected, it identifies and configures the ethernet. Regarding the airport, it only sets it up upon a login to the GUI. For boots with the ethernet disconnected and the airport enabled, it doesn't appear to configure any network interface.

The research I've done suggests that adding something to Startupitems might be the solution, but I don't know where to begin.

Ideas?

--MW

[BigRedBall]

Have you got 'automatically connect to this network' set up in your Network preferences? That might counter the seemingly per-user nature of your AP connection, though I haven't tested this.

[mwnovak]

I've tried it both ways--"Automatic" and "A Specific Network"--with the same result.

I'm pretty green where Linux systems are concerned, but...

I know that some processes are scheduled to run during system startup, while others are reserved to run during the login process ("per user," perhaps?). I've found an Apple Developer page that breaks-down the processes (http://developer.apple.com/documentation/MacOSX/Conceptual/BPSystemStartup/index.html) but can't really make heads or tails out of what to _do_ with that information.

It seems like I could just move the AirPort init procedure from the post-login scripts into the system startup scripts and get the desired result... but I dunno (can't even find the relevant entries, to be honest).

--MW

[mwnovak]

Yes, system.log verified my initial analysis: ethernet initializes in any situation (with the dis/conncetion of the cable), while the AirPort _only_ loads after a user login.

Any tips on adding a startupitem for the AirPort? My research suggests that may be the way to go (in terms of "what loads when" during the startup/login sequences), and I've found several sites discussing the creation of startupitems... but I've no clue how to make one for the AirPort.

--MW

[aixccapt99]

Why not just set a dummy user to auto-login on startup? Give that user the AirPort login info, but nothing else.

[Las_Vegas]

Then you could add a script to that account's Startup files to log it back out. Now you have a connection at the login screen.

[mwnovak]

That _does_ seem like the available workaround... and it isn't like many people have physical access to the Cube (i.e. my workshop isn't a public lab). It just makes me uncomfortable in "principle": autologin and a dummy account simply to initialize a network interface? Yikes.

<sigh>

But, if that's the way... that's the way.

Can anyone following this thread point me to a good discussion of locking-down the OSX GUI on a per-user basis? The options in the Accounts pref. pane are a good start... but, if I'm going to do this fix with a dummy account, I'd like to restrict that account as much as possible (i.e. give that user the ability to logout... and not much/anything else).

Thanks, everyone, for your help. I've never posted to this forum before, and the experience has been very positive. :)

--MW

[Las_Vegas]

First, create the account with Admin access. Log into it and set it up to connect to your Airport. Go into Finder Preferences and turn off all Sidebar icons. Now, delete all of the folders in the User's folder except the Library. In the Library folder delete everything except the Preferences folder.

Logout and back in with your regular Admin account and change the new user to not have Admin access. This should remove just about all abilities from the dummy account. It should be pretty much just a shell of its former self. :)

Edit: Another little trick is to remove it from the Login window. To do this, go to NetInfo Manager and change the account's User ID to 499 (less than 500). Since you haven't given the account any privileges anyway, nothing else would need to be adjusted. This needs to be done after you remove Admin privileges since it will no longer appear in the Accounts prefs pane.

[poenn]

I just read your posts. Finally I know why Apple Remote Desktop won't work via Airport unless a GUI-User logs in!

I have this problem, too. And I'm also trying to access my Cube(!) so it seems to be specific to this Mac model?!?
For now I just use autologin, since I don't need high security there, but if anyone finds out about a more elegant way to start the interface without a GUI-login, please let us know!


Thanks
Björn

[mwnovak]

Just a follow-up...

I don't think this is specific to the Cube: I can readily re-create the behavior on my 12" PowerBook, and I found a lone post in the Apple Support forums from someone in the same situation with a newer iBook (no solution there, either). Seems like an OS thing, in the end.

I'd bet there's a FreeBSD guru out there who could figure out a shell script to bring the AirPort online at startup... or at least explain why it isn't possible. :)

Regardless, thanks for the tips on locking down the GUI... I'll go play with that, now.

Thanks again,

--MW

[mwnovak]

At the risk of getting too far off topic, I've an addition to the note about changing the "guest" account's User ID with Netinfo Manager.

After changing the UID to 499, the "guest" account lost many of the preferences that I'd set before locking down its GUI and removing its admin ability. A quick Google search revealed the following Terminal command:

nice -20 find . -user OLDUID -exec chown XXXX {} \;

OLDUID is the original UID of the account; XXXX is the short username of the account. Apparently, changing the UID of an account leaves some old files _without_ permissions. The above command transfers the old UID permissions to the new UID (if I understand correctly, that is).

Either way, it worked perfectly.

The link to the article: http://scgwiki.iam.unibe.ch:8080/SCG/483

Cheers,

--MW

[Las_Vegas]

Very usefull info MW! Thanks.

[Amos]

Hello. You can run "ifconfig -a" in a terminal window to see the staus of your interfaces. On my mac, the interface "en1" is my wireless interface. The command "sudo ifconfig en1 down" or "sudo ifconfig en1 up" will bring the interface up or down properly, at least while I'm logged in.

I suspect that my WPA passphrase is stored in my keychain though. So while I believe the ifconfig commands (minus the sudo bit - startup already runs as root) would work in a StartupItem to turn on the interface, I doubt it would be able to authenticate automatically to my preferred network since it would require the passphrase.

I bet it would work for non authenticated networks though. And come to think of it, perhaps if you enabled the root user and configured it with the WPA passphase, it might be able to authenticate from StartupItems.