Cyanogenmod 7 and sshd

Remote access to your phone might seem a bit odd, but being able to access my NexusOne from a computer with a real keyboard is nice when you need to poke around inside the internals. It also makes updating the photos, music, or movies possible without additional apps or cabling the phone to my PC. Today I forgot my phone at home, and was able to verify that I had “lost” it at home vs. somewhere else by ssh‘ing into my home network, then connecting over the local network to my phone using ssh.

There were 3 main steps:

  1. set the phone hostname on boot
  2. configure sshd
  3. make it start on boot

Step one was really easy, turns out it is a supported feature of CyanogenMod 7 (CM7). Enter the Settings menu,  choose Applications then Development, now select Device Host Name. That’s it, I didn’t even need to reboot (the setting is persistent across reboots).

Step two is the most involved, the cyanogenmod wiki has some instructions as does this tutorial. I’ll attempt to provide a guided walk-through here.

a) Let’s assume you’ve got a linux desktop machine. First we’ll create some ssh client keys. We’re going to do this as the dropbear in CM7 doesn’t support key passphrases, so passwords are not an option. The other benefit to ssh client keys is that we can automate connecting to the phone.

So on the linux destop we’ll execute:

$ ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/youruser/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/youruser/.ssh/id_rsa.
Your public key has been saved in /home/youruser/.ssh/id_rsa.pub.

For the passphrase we left it empty. In very simple terms – the id_rsa is the private part of the key, the id_rsa.pub is the public one. We’re going to put the public key file onto the phone later. The private one will stay safe and secure on your desktop.

b) I’ll also assume you’ve got adb installed. By connecting the phone to the desktop machine via USB we can push the key file using adb.

$ sudo platform-tools/adb push /home/youruser/.ssh/id_rsa.pub /sdcard/authorized_keys

c) Now we’ll use adb to execute a shell on the phone. This is how I used to get in with a keyboard, but doing so without a wire hook up is very convenient.

$ sudo platform-tools/adb shell

d) Time to configure dropbear, these are all executed within the shell we just created on the phone. You’ll find this is pretty much exactly what the CM wiki describes.

# mkdir /data/dropbear
# mkdir /data/dropbear/.ssh
# cp /sdcard/authorized_keys /data/dropbear/.ssh/
# dropbear-keygen

Initially I had thought I could avoid running dropbear-keygen, but it turns out this is a required step. [Edit: In CM 7.1.0 RC1 dropbear-keygen is not installed, nor does it appear to be required] Now we initialize the keys.

# dropbearkey -t rsa -f /data/dropbear/dropbear_rsa_host_key
# dropbearkey -t dss -f /data/dropbear/dropbear_dss_host_key

And set permissions to keep things happy.

# chmod 755 /data/dropbear /data/dropbear/.ssh
# chmod 644 /data/dropbear/dropbear*host_key
# chmod 600 /data/dropbear/.ssh/authorized_keys

e) Now we get to try it.

# dropbear -v -s -g

The -v option tells it to be verbose, handy if something has gone wrong. You should now be able to connect via ssh from the linux desktop machine, but only from the user id that created the public/private key combination (of which we’ve moved the public key to the phone). Since in step 1 we set the hostname, we can do:

$ ssh myphone
The authenticity of host 'myphone (192.168.1.174)' can't be established.
RSA key fingerprint is 00:c0:b2:78:2b:af:04:72:90:bb:0d:46:f9:14:cc:3f.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'myphone' (RSA) to the list of known hosts.
# ls
dropbear.pid dropbear_dss_host_key dropbear_rsa_host_key

[edit: CM 7.1.0 seems to be causing me some trouble, in two areas. a) it requires the username matches, so use “ssh root@myphone” b) it doesn’t like rsa public keys but dsa works, so use “ssh-keygen -t dsa”. You’ll know you have the problem as you get a “permission denied (publickey)” error.]

f) Bonus step. We’ll add more keys from other systems we want to be able to connect to the phone from. We repeat (a) on each machine / user id we want to connect from and append the public key to the authorized_keys file.

cat /sdcard/newmachineid.pub >> /data/.ssh/authorized_keys

Now on to step three – making sshd start on boot. I’ll assume you don’t already have a /data/local/userinit.sh file yet for some other modification, if you do I’m sure you can sort this out.

[Edit – as was pointed out by Devon, the original version had !# instead of #! in the userinit.sh script, I’ve fixed the post to reflect the correct code – no worries, the wrong way still works fine as my comment indicates]
On the phone (using ssh or adb to access the shell) you run the following commands:

# echo -e '#!/system/bin/sh\n\ndropbear -s -g' > /data/local/userinit.sh
# chmod +rx /data/local/userinit.sh

You can even run vi if you want (it works!). We can check the resulting file with cat:

# cat /data/local/userinit.sh
#!/system/bin/sh

 

dropbear -s -g

That’s it, we’re done. The next logical step is to start including your phone as part of your nightly rsnapshot backups, or building some scripts to make updating music on the phone easy (and wireless).

KeePass: password management

Most of us have a multitude of online systems we connect to, some on a regular basis and others from time to time. Each of these systems usually has a unique user ID and password. How many of these can we reasonably remember? Many, many people attempt to keep at least the passwords aligned across systems and often user name as well. The risk is that one of these systems is compromised (or worse, malicious) and suddenly someone other than you has the keys to the castle.

There is also the challenge of picking a strong password. There are several online password generators, and tools that help verify the strength of a password. For a while I was relying on my browser to remember my password (via a cookie) and using randomly generated passwords, when the cookie expired I’d use the “I lost my password” feature to fix it (or just recreate a user). This works ok for throw-away sites (web forums) but really sucks for a site like PayPal.

So I was guilty of password re-use across a number of sites. No longer now that I’ve moved to KeePass. Of course, now I need to ensure that I have one password (for KeePass) that I will not forget and is secure enough. To help in creating one I’ll reference a great article on the usability of passwords, I encourage everyone to read this.

You can get versions of KeePass for almost any platform. For my needs I needed to cover Windows, Linux and Android. On first launch you’ll be asked to create a database (to store passwords) and assign it a password and/or a keyfile.

From the documentation “Key files provide better security than master passwords in most cases. You only have to carry the key file with you, for example on a floppy disk, USB stick, or you can burn it onto a CD. Of course, you shouldn’t lose this disk then.” This is a neat option, but not very practical on my NexusOne.

Once you’ve created your .kdb database on one of your systems, in my case an Ubuntu box – you can move that DB to other systems you’ve got KeePass on. The Android app KeePassDroid happily consumed the (1.x) database created by KeePassX. You need to figure out a method for synchronizing that database across your systems, some people use dropbox or just simply scp.

By using KeePass it is easy to create strong passwords (a generator is built into the app) and track your unique user id and password for all sites you access. Giving yourself a rule that says you’ll switch to a KeePass based password on your next visit to the site will help you move over relatively quickly.

If you need any more encouragement to rethink how you handle passwords and account, just do a quick google search. Better to lose control of one account than all.

How To: Replace BlackBerry 9700 Keyboard

My brother in-law managed to lose the ALT key from his BlackBerry Bold 9700. He had been living with the lack of the key for some time as he didn’t realize how cheap it would be to replace it. I was happy to do the work simply because it let me take a new device apart.

Off to eBay for a new keyboard. There were many options. The prices ranged from $3 shipping included, $8 from a USA based source, or $12 within Canada (you can pay much more if you want). Lately I’ve had some trouble with shipments from China taking 60 days (or more) and my brother in-law was happy to pay a bit more to get the part sooner so we went with the $12 part.

A bit of searching located a good textual description of how to replace the keyboard on a 9700. The same thread references a youtube clip that provides a visual of the disassembly. You’ll need a Torx T5 and either slightly long fingernails, or some sort of plastic pry tool. Unfortunately my trusty micro-tip set from Lee Valley failed me here, the smallest Torx driver it has is a T6 – I cheated and used a small flathead from another micro screwdriver set which seemed to work ok.

The first step should be to remove the back and battery. You can leave the SIM and microSD cards in place.

Now we remove the bottom cover. This felt really tricky, but as we get further we’ll discover this is the easy part. Pry using your fingernail or the plastic pry tool under the “tops of the U-shape” on either side, releasing one side then the other.

You can see the two exposed screws. The lower one (in the picture) has a white dot on it, this is the tamper proof sticker. Some people have been able to slide this onto a razer blade / exacto knife and have been able to preserve the sticker. I tried, but it tore partially. In the end I just trashed it. Remove the two screws.

Removing the bezel was the tricky part. I found this youtube video to be the most instructive. You start by popping up the bottom lip (the part held down by the screws we took out). Then you need to free the clips on either side of the screen. These come free best by working outwards from the screen. Once the bottom half is free, then the top part pops / slides upwards on the phone. It took me a good 15 minutes of gentle prying and poking to determine how it came off, but once I had it sorted out it was quite easy to do again. Some folk do manage to ruin the bezel doing this procedure, so I’d suggest working as carefully as possible – you can always purchase a replacement if needed.

At this point swapping the keyboard is trivial. Re-assembly is quite simple. Again the bezel is the tricky part. Press the bezel down onto the phone 1st, then once it is in place you’ll want to squeeze the sides inwards to set the bezel correctly. Things should all click into place easily.

I ended up taking the phone apart and reassembling it twice. The second time was quite easy, once I had the feel for it. This is easier than taking an iPod apart, but harder than the Nokia 5310 mostly because of the bezel.

Things didn’t go entirely smoothly, the blame falls entirely on the replacement part.

One of the keys on the new keyboard simply fell out. This wasn’t a huge problem as a little super glue and the key was back in place. The keyboard is made up of the frame, a rubber membrane, and the keys. The membrane allows the keys to move within the frame. The key that fell out wasn’t properly bonded to the membrane. I’ve held onto the old keyboard in case more keys go missing. The original problem was a missing ALT key, but in that case the rubber membrane had torn away as well.

Above you can see the second problem, and what led me to disassemble the phone a 2nd time. The ALT key pictured above on the right is raised more than the keys around it. I thought that maybe there was something jammed under the key preventing it from lying flat. Upon inspection it appears that it is a manufacturing defect.

Certainly worth doing. While I had issues with the part quality, I suspect this was just bad luck. The slightly raised ALT key functions fine and really isn’t a big deal.