From a terminal window, I tried it out using an account I had set up during the device initialization:

# telnet 192.168.1.70 Trying 192.168.1.70... Connected to 192.168.1.70. Escape character is '^]'. NSLU2 login: tom Password: No directory, logging in with HOME=/ Cannot execute /dev/null: Permission denied Connection closed by foreign host.

Close but no cigar. A telnet server was running and my username and password were accepted, but the account had the shell set to /dev/null. This told me that users set up with the web interface were valid Linux accounts, but only second-class citizens as far as access. This is a common practice for users who can use some services, but are not allowed to have an interactive login.

Attempting to login as root - a standard Linux account - failed because I didn't know the password and the obvious ones (admin, root, etc.) didn't work. It was time to come at the problem from a different angle.

Linksys documentation claimed that a disk initialized by the NSLU2 can only be used with the NSLU2, but I didn't believe it. A file system is a complicated piece of software and it wasn't likely that Linksys wrote a new one for this little box. Some write-ups indicated (and a Linksys spokesperson confirmed) that the filesystem was a Linux ext3 filesystem because of the partition type, but as far as I could tell, no one had tried mounting it.

Being too lazy to take my NSLU2 initialized disk downstairs to my Mandrake Linux system, I downloaded ext2 (a subset of ext3) drivers for my MacOs X iBook and plugged the disk into its USB port.

Tip: The Mac OS X ext2 drivers I used can be downloaded from the ext2 for Mac OS X SourceForge project. There is also a read-only ext2 driver for Windows NT/2000/XP that you can try here. It was used to create the screenshot shown in Figure 3.

Up popped two mounted filesystems: a large filesystem with all of my data files on it, and a small filesystem with several configuration files including my favorite, passwd.

Figure 3: The filesystem containing configuration files

As expected, the passwd file showed the user accounts I had created with a /dev/null for the shell. But there were two accounts that had a real shell: root and an interestingly named account - ourtelnetrescueuser, that looked like a back door account used for debugging or recovery purposes.

root:WeeOvKUvbQ6nI:0:0:root:/root:/bin/sh bin:x:1:1:bin:/bin: lp:x:4:7:lp:/share/spool: mail:x:8:12:mail:/var/spool/mail: ftp:x:14:50:FTP User:/: nobody:x:99:99:Nobody:/: ourtelnetrescueuser:scFf7ZMXBMl4I:100:100::/home/user:/bin/sh guest:scEPG0VnVyqmE:501:501:::/dev/null admin:sclzZZfodiRXY:502:501::/home/user/admin:/dev/null test_user:scEPG0VnVyqmE:2000:501:::/dev/null test2:scEPG0VnVyqmE:2001:501:::/dev/null test3:sc50wKPq.zChw:2002:501:::/dev/null

But in order to use these accounts, I would need to have their passwords. I started down the path of cracking the passwords before I came out of my stupor and realized all I had to do was edit the passwd file and replace the encrypted password with a known encrypted password from one of my other accounts! I could also just add a valid shell to one of my accounts, but for starters, decided to just put a new password in for root and leave the rest of the accounts alone.