Back to Silas S. Brown's home page

Desktop SSH via Android devices

Some Android devices have "USB tether" functions that don't work. The following alternative method has two prerequisites:
  1. You must have a working adb command (for example if you've installed the Android Developer Tools bundle)
  2. The shell that adb -d shell gives you must contain an ssh command
    • Works on Android 4.4 but not on Android 4.1. If your device lacks one and you can't install it, you might need to use an SSH app with port forwarding (such as ConnectBot or the paid version of JuiceSSH) although you might still be able to adapt some of the script below.
Using the SSH command over ADB has the following advantages: There are however some hurdles to be overcome:
  1. The ssh command bundled with Android ignores the setting of HOME and is compiled to try and put its files in a /data directory which you can't access on a non-rooted device
  2. Although you can set SSH options to use files in (for example) /storage/emulated/legacy, those files are readable by all apps, some of which might be running in the background with "spy" functions. Exposing the known_hosts file to them is relatively benign, but if you start putting identity files in that directory (even for a short time) you are taking a risk.
  3. Although adb -d shell can take a command as a parameter, supplying one will cause the shell to become non-interactive. So if you want to actually type into that SSH session, you have to run a shell without a default command, and type in all the settings each time.
  4. adb's limited terminal emulation might be a let-down when you want to run full-screen terminal applications
The above problems can be worked around by using expect and port forwarding.

expect script

This ssh-android expect script works around the above by doing the following:
  1. Connects to an Android shell over ADB and issues an SSH command with the user and host you specify (user defaults to your login name) and password authentication. This command is also set to start a SOCKS proxy.
  2. Uses adb to extend this SOCKS tunnel over the USB connection onto a port on the local machine
  3. Issues a second SSH command outside the adb shell, and sets it to go over the SOCKS connection. The password you entered the first time is repeated by the script.
  4. You may now interact with this second session using the full capabilities of your terminal (since it's not inside adb), and/or tell other applications to connect through the SOCKS proxy
  5. When this second SSH session finishes, the script shuts down the first
The script assumes that the host key is already in your ~/.ssh/known_hosts file, but can be adapted if it isn't.

Install it by saving it somewhere on your PATH, edit as necessary to set the path to adb and use chmod +x on it. You'll need adb and expect on the system (many Macs have expect already, and there are Linux packages in most distributions).

Other use of the SOCKS proxy

Rather than using everything over SSH, you might wish to allow selected local programs to connect over the proxy while still not opening it to everything.

HTTP proxy

In many cases it's easier to use an HTTP proxy than a SOCKS proxy, so I suggest installing Privoxy and setting its config to forward-socks5 / . (you might also want to delete the in listen-address to make it available to other machines on your local network, and if one of them sends too many requests you might then want debug 1 so you can check /var/log/privoxy/logfile.log and add appropriate block patterns). After restarting Privoxy, you can tell selected applications about it, e.g.

Other SOCKS forwarding

For other machines on the local network to access SOCKS directly (rather than via an HTTP proxy), you'll need an additional port-forward because adb listens only to localhost. For example (from the other machine) ssh -L 10080:localhost:10080

Redirecting all traffic

Setting up a gateway machine to redirect all traffic would lose the advantage of not having the connection automatically visible to every program on your network (you might need to add blocking rules), and arguably will constitute "tethering", unless perhaps you're providing WiFi to only another phone or tablet that you could have put your SIM into.

Perhaps the easiest way to set things up on the gateway machine (Raspberry Pi or whatever) is to use transocks_ev with iptables and pdnsd.

All material © Silas S. Brown unless otherwise stated.
Android is a trademark of Google LLC.
Bluetooth is a registered trademark held by the Bluetooth Special Interest Group.
Linux is the registered trademark of Linus Torvalds in the U.S. and other countries.
Mac is a trademark of Apple Inc.
Raspberry Pi is a trademark of the Raspberry Pi Foundation.
Wi-Fi is a trademark of the Wi-Fi Alliance.
Any other trademarks I mentioned without realising are trademarks of their respective holders.