Tag Archives: SSH

Google G1: Six Months On

So six months ago I bought my Google G1, my first impressions were excited and extremely positive. Has this phone stood the test of time though?

Physically

The phone is still in good physical condition, which is more than I could have said about my old XDA Atom Flame after six months. There are a few scratches on the screen, but I bought a screen protector for it so I can simply peel them off. Surprisingly the various crevices on the phone have avoided build ups of dust which commonly plagues my phones. The battery is beginning to fade, and can only last me around 12 hours with my ordinary usage (which is probably considered heavy usage). This makes weekends away from home interesting as I have to avoid using my phone to stretch the battery over 24 hours.

When I first got the phone I expected that the keyboard keys would fade, or that the keyboard snap mechanism would somehow break. I was wrong, the keys are still as visible as when I first got it, and the snap mechanism still works perfectly.

The OS

In the time I’ve had this phone Android has gone from 1.1 to 2.0. Sadly there haven’t been any official new releases of the phone software. There have however been releases of the well known mod for this phone called ‘CyanogenMod’. Currently CyanogenMod is at Android version 1.5 with parts of 2.0 ported across.

Since the first week I had the phone I’ve been using CyanogenMod and have seen the improvements in it take it from strength to strength. Originally it looks almost the exact same as the original OS but now it includes several features that I could not live without. My favorites would be:

  • Tethering to my Linux PC
  • OpenVPN settings
  • 360 degree rotation
  • Improved contacts screen with direct call links
  • Voice Search

The Applications

Like any mobile OS the best part is the applications. This is where an OS either make it or breaks it. While Google have been constantly improving the Android platform old apps have remained around and stayed compatible with the phone. Google has also held two developer competitions during the time I’ve had the phone which has brought loads of new apps and innovation. So as each application is its own entity I’m going to review my favorites separately.

Google Maps

When I got the phone Google Maps was simply a map, with limited search capability and able to give directions. Since then however Google have added Street View, Navigation (US Only sadly), Buzz and much better searching. For something I used once a month I now use it almost daily.

ConnectBot

One of the reasons I went for a phone with a hardware keyboard was to make SSHing into my Linux machines easier. ConnectBot handles this perfectly. I cannot stress enough how useful this application is. Recently it has been improved to include support for SSH agents too which improved things even further.

My Tracks

As someone who enjoys hiking and walking having a GPS logger can be extremely useful. My Tracks basically turns your Android phone into a GPS logger and displays the data for you on a map. It also allows you to export the logs in popular formats or simply upload them to My Maps on Google. It can also graph your elevation, speed and display interesting statistics.

Conclusion

All up I still enjoy this phone, and still use it daily. I am looking at moving to either an N900 or the Google Nexus One next. I haven’t moved because the N900 has been having trouble with the USB connectors breaking off, and the Nexus One is too expensive to import into Australia. I doubt I’ll be moving to another phone any time soon and this phone doesn’t look like it will give out any time in the near future.

Random Thought: What is the cell phone market going to look like five years from now? And where the hell is my wristwatch phone?

Using Subversion over SSH

Subversion is an amazing tool that you can use to keep track of all the changes you make to a group of files. If you haven’t used it before, or have never heard of ‘version control’ then you should probably read the Subversion Book.

Few people don’t realise that subversion has the ability to connect to a remote repository via SSH. Its extremely simple and can give you all the advantages of storing your important files on a server while still having them readily accessible on your desktop. This means that for example you could have your files (and every old version of your files) stored on a RAID device on a server while working with them locally on your desktop.

To set this up its actually rather simple. First you create your repository and perform the initial import of the files. I usually make it in my home directory as follows:

mkdir -p /home/daniel/svn/newproject
svnadmin create /home/daniel/svn/newproject
mkdir -p /tmp/newrepo/{trunk,branches,tags}
svn import /tmp/newrepo file:///home/daniel/svn/newproject -m "Create Initial Structure"
rm -rf /tmp/newproject

These commands are basically what you’d use to create any subversion repository and people familiar with it require no explanation. Most people probably even have is scripted to make it just that much easier. Here comes the fun part though. Next we (on our local machine) check the files out. To checkout subversion repositories over ssh you simply use the following command:

svn checkout svn+ssh://username@servername/home/daniel/svn/newproject/trunk newproject

All going well you will now see a password prompt and upon successful authentication the files will be checked out. This is all that is required and from now on you can simply use the ordinary svn commands.

Random Thought: … and I says to the kernel developer, I says “git this!”

SSH Agent Forwarding

So you use keys to SSH between your hosts, and you either have separate keys for each machine you use, or worse you have the same key on each machine. Lets go over why each of those are bad, and lets see how SSH Agent forwarding will help with those issues and make things easier for you in general.

So the key part of why a SSH agent and SSH agent forwarding forwarding is so useful is due to the way keys can be attacked. If I wanted to get your SSH private key I could find some flaw in the system that would give me that /home/you/.ssh/id_rsa file you have. Of course a malicious user with root access to the system could just go in and grab it. You can prevent this kind of attack by setting a passphrase on the key. Of course the root user could replace SSH with a special version designed to get your passphrase, steal the key out of memory or setup a keylogger. This means effectively that your private key is not safe on any system where a person you don’t trust has root access, or has other users and exploitable vulnerabilities.

Single Private Key on Multiple Machines

In this example you’re trusting the security of every single machine you have your private key on. Should it get compromised then you have to revoke you public key from every host, and regenerate private keys to place on every host. Every time you put your private key on a machine you increase the chances that it could be compromised.

Multiple Private Keys On Multiple Machines

So we’re getting a little closer to a good solution. In this instance we don’t have to generate our key and roll it out to all hosts in event of a compromise. You can also have segregate groups, on set of keys for work, another for home and so on. Your keys can still be compromised easily though, and once compromised they can be used until you revoke them manually.

SSH Agent Forwarding

There is a way to keep your key safe from compromise. Now I’ll have to explain how SSH authenticates you using your key. When your authenticating with SSH keys your key isn’t sent, the server sends you some random data and challenges your client to encrypt it with your private key. It then verifies the encrypted data by decrypting it with the public key and checking if it matches the data originally sent. Now the way most people would SSH from the second host to another third host is to utilise a private key on the second host to connect to the third host. Unfortunately this method means that you have to store a key (that is open for compromise) on the second host. SSH agent forwarding tells the SSH client on the second server to send the challenge data through to the SSH client (or ssh agent) on the first host. The agent encrypts the data and sends it via the SSH session to the third client.

The beauty of this method is that the second host never sees a private key, and the challenge data is useless to try and connect to a different host. Even if the second host is compromised there isn’t a private key there to compromise. It should be noted that if the second host is compromised it can still request the agent identify for a different host, or the session to the third host can be taken over. Both these are temporary though and unless the malicious user installs their key (something easy to notice) they cannot get back in.

Diagram detailing how an SSH connection is authenticated using agent forwarding.

Diagram detailing how an SSH connection is authenticated using agent forwarding.

If you want to know more about how this works, there is a wonderful tech tip at http://unixwiz.net/techtips/ssh-agent-forwarding.html.

But how?

SSH agent forwarding is even easier than copying keys all over the place. The first step is to generate keys for all the machines you log on to directly. You need to be sure these machines are secure and that your keys will stay safe, though this is sometimes not possible. You then add the generated public key to the authorized hosts file of all the machines you will connect to from this one, including ones that take two or more steps to get to. Finally you edit your ~/.ssh/ssh_config file to tell SSH to forward your agent through those hosts. Include the intermediate hosts in this list, but not the endpoints. You could also use SSHmenu to add the arguments automatically to those SSH commands. The following disables forwarding to all hosts, and explicitly enables it to fred, and aaron.missgner.com.

Host fred
  ForwardAgent yes

Host aaron.missgner.com
  ForwardAgent yes

Host *
  ForwardAgent no

Random thought: Linux has Plug ‘n Pray too, you plug the device in and pray the drivers aren’t proprietary.