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/

For the passphrase we left it empty. In very simple terms – the id_rsa is the private part of the key, the 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/ /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 (' 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_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/ >> /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/ 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 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/
# chmod +rx /data/local/

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

# cat /data/local/


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).

More RAM for your G1

I’m a big fan of the cyanogenmod alternate firmware. It has allowed me to enjoy the latest versions of Android (Froyo!) on the original HTC G1. One of the most notable limitations of this device vs. almost all of the others is the amount of RAM available. The G1 has 192MB of RAM, of which only 95MB is available for programs under CM 6.0. Recently there has been a hack “EzRAM” which enables an additional 15MB of RAM for a total of 110MB. This additional RAM really makes a difference in performance.

Read on for the details of the upgrade process..

Continue reading “More RAM for your G1”

When Android Fails

I really have myself to blame.  Android is the right smart phone platform for me: provided you have a rooted phone, you can get inside the device and tinker and there are community created ROMs which let you change the base system.  It is effectively an embedded Linux platform with a java like application stack.  I tend to follow the CyanogenMod crowd.

On my ADP1, I’ve got the developer friendly “fastboot”.  Using this you can install what is called a “recovery image” – a secondary boot mode which lets you get in and do maintenance etc.  Recently I found myself in a state where I had lost my recovery image.  The forum has some good basic advice if this happens to you.

As I found myself needing to reinstall.  The recommended recovery image is Amon_RA.  I used the fastboot flash method, from my Ubuntu desktop using the fastboot binary.  Once I had the binary, it really was as easy as booting into fastboot mode (hold camera button while phone is booting) and runnning the fastboot program.

fastboot flash recovery recovery_of_choice.img

Now what got me to this state of no recovery image, was most likely a finger fumble while I was trying to recover the phone from a bad state.  (Did I mention I was to blame here?)  Now I suspect there is some sort of latent bug in the Dalvik cache management that leads to this bad state, but I don’t yet have enough data to make a strong statement here.

What happens is at one point, apps stop opening properly for me.  Specifically things like the web browser.  The 1st time this happened, I ended up wiping the phone and starting again from scratch. While this is a recommended step if you’re going to play in the ROM scene, it is annoying to lose all of your state.  To my dismay it happened again.

The symptom is a boot loop when you reboot.  Using some of the tools from the Android SDK, you can watch things as they happen on boot.  I use ddms for this.  In the most recent failure, the loop looked like this in the log:

07-04 16:17:28.114: DEBUG/AndroidRuntime(249): >>>>>>>>>>>>>> AndroidRuntime START <<<<<<<<<<<<<<
07-04 16:17:28.114: DEBUG/AndroidRuntime(249): CheckJNI is OFF
07-04 16:17:28.284: DEBUG/AndroidRuntime(249): --- registering native functions ---
07-04 16:17:28.544: ERROR/AndroidRuntime(249): JavaVM unable to find main() in ''
07-04 16:17:28.544: DEBUG/AndroidRuntime(249): Shutting down VM
07-04 16:17:28.544: WARN/dalvikvm(249): threadid=3: thread exiting with uncaught exception (group=0x4001e178)
07-04 16:17:28.574: DEBUG/dalvikvm(249): DestroyJavaVM waiting for non-daemon threads to exit
07-04 16:17:28.574: DEBUG/dalvikvm(249): DestroyJavaVM shutting VM down
07-04 16:17:28.574: DEBUG/dalvikvm(249): VM cleaning u

Not good.  Something can’t be found that is fairly critical, so the Dalvik system is continually bailing out on its start-up, then trying again.

The fix was quite easy (if we ignore the step where during the investigation, I mess up my recovery image).  The adb tool found in the Android SDK is much more powerful than I initially understood it to be.  We can use it to stop the Android sytem.

> adb shell stop

This effectively stops the boot loop from spinning around and around.  Now issuing:

> adb shell

Gets you into the device, and we can go and fix the filesystem.  I located and cleared the Dalvik caches (deleted the contents of the directories).

You may only need to clear the 3rd one, but that is the list I cleared out to get back into a working state.  Much easier than a full wipe and reconfigure.