There are a number of apps on the Android market but most of them are utterly useless with one exception: SSHDroid.
If you are likely to use SSH once in a while then it may be easier for you to just install SSHDroid on your device and start it when needed, and I have been happy with it for a while.
- It's an ugly app that sits in your notification tray once it has been started and uses up RAM and CPU. I want a background app.
- SSHDroid refuses to run if it cannot access adverts unless you pay for it. I block all adverts because they get on my nerves.
- All it does is drop a copy of Dropbear anyway, so you may as well do that yourself.
- Dropbear will happily run in the background and uses tiny amounts of CPU when active, so you can imagine how little it does when idle.
- If you can compile Dropbear yourself you can choose the options that you want.
As I'm sure you are aware there is no package delivery system for this kind of application in Android, but Android runs on a modified Linux kernel - this makes things so much easier! The result being that the following process is ridiculously easy assuming that your OS has:
- su or sudo (root)
- init.d support (or another way to run scripts at startup)
The only problem, really, is that the filesystem and methods used in Android aren't exactly standard compared to other *nix systems, but its not massively different. The result being that there are a number of ways that you can get things to work, so I'll simply show you what I have done. If I was doing this to a number of devices or in a corporate environment then I would use a bit more planning.
Let us first think a little bit about security.
Are there any security problems related to your Android kernel, or Dropbear version, or any other software you're running that would be exacerbated by running an SSH server? Unless you're running a number of devices in a corporate environment there probably isn't going to be a massive amount that concerns you, but it should. Make sure you understand what the bugs are. A search will very quickly tell you as the FUDders love ripping FOSS apart, despite the fact they rarely know what they're talking about. You should focus on the facts published by security experts. The websites hosting the software nearly always list the bugs themselves. Start there.
Step 1 - Compiling Dropbear
Alternatively you could always grab a static binary for your architecture (armel in my case) from any Linux distro website. Make sure you trust the source. Don't download something from a file sharing website!
Step 2 - Drop Dropbear
You have Dropbear and any supporting applications? Good. Drop it onto your device.
I have an ext4 partition on my SD card mounted under sd-ext (see S2E) so I just dropped it under /sd-ext/dropbear/. Make sure to set the correct permissions (binaries should be +x executable).
Note that the vfat partition on your SD card (/mnt/sdcard normally) will be mounted with noexec. You probably don't want to change this. If you do not have, or want, another partition on your SD card and have plenty of internal storage, then just drop it in internal storage somewhere. I'll let you decide where!
Step 3 - Set up your environment
You'll want to edit your ~/.profile and possibly ~/.bash_rc files (see also /etc/bash/) to get the terminal you want when you log in via SSH. Not that Dropbear uses the -H switch to know where to look for ~.
You probably want to use dropbearkey to create keys too. I really would not recommend using no security on an SSH server. Ever. Remember that unless you play about with the settings on your device that your SSH server will be public facing whenever you're not on your own network: public Wi-Fi for example. Make sure you use strong keys, passwords or both.
You can, of course, set stronger security if you wish. You probably should. I'm way too lazy.
Step 4 - Test it
There's no point going any further if you cannot access your server. You'll need to know what switches to use with Dropbear anyway so hopefully you have figured that out by now. Can you connect? Good!
Step 5 - Add a startup script
Strictly speaking it would probably be best to write a script that checks a number of things, retries, and sets up the server once everything has checked out. These scripts are "normally" stored in /data/local/userinit.d/ but I wasn't comfortable with dropping mine there as that's where S2E also drops its script, and seen as I've put Dropbear on /sd-ext/ there's a danger it will fail (unless I use a more robust script). I've already established that I'm lazy. I dropped mine in /etc/init.d/ (symlink to /system/etc/init.d/) to run with priority 99 - I have no real need for the server to start early.
Note that you'll need to temporarily enable rw on /system to add the script.
I used a simple script.
$DROPBEARPATH/dropbear -p 29022 -r $DROPBEARPATH/dropbear.key.rsa -d $DROPBEARPATH/dropbear.key.dss -H $DROPBEARPATH -E -b $DROPBEARPATH/dropbear.banner
I'm fully aware that I could add a "cd" to make this even smaller, but I don't care.
Note that I used port 29022 rather than 22. This is because scripts kiddies will always check port 22 so that basically thwarts their lame attempts straight away.
Step 6 - Test again
Run the script. Can you connect? Good!
Reboot the device and see if you can connect once boot has completed. Can you connect? Good!
If anything has failed at this point then check your scripts and your permissions carefully. This process is incredibly simple so there's not a great deal that can go wrong.
Step 7 - Mess about
If you're anal like me you want all your terminals to behave the same way. You'll probably want to mess around with your terminal settings until you get it just right.
It will also save time if you arm the private systems you'll be accessing the device from with keys so that you don't have to mess about entering passwords all the time. Makes sense to me.
Here I'm connected via PuTTY and WinSCP on Windows 7, and for that I apologise. I mainly use Ubuntu Linux which, of course, also works like a gem. (In fact sshfs is much nicer on Linux).
So there you go. If you know what you're doing then you will already have ideas on preferences and how you would like to do things. Hopefully I have shown you that it can be done, and now the rest is up to you.
If you're new to Linux you're probably going to struggle. Ask for help.
If you're an Apple user then you're not interested in technology anyway, so don't worry about it.