Key server on Android

[459below]

I plan to run a key server on Android using dropbear or SSHDroid. At the moment it seems very attractive to me, since one tends to be very attentive with their smartphone and it may be encrypted. It certainly would solve the "Internet is down and the system won't unlock automatically"-issue.

[fetzerms]

This seems like a good idea. Do you know if it is actually possible to use "command" in SSHDroid's authorized_keys file?

[459below]

Thanks. No, I don't know if that's possible. I'm short on time at the moment, so I haven't looked into the specifics of this yet. I am using the shipped dropbear of LineageOS for file synchronization and I am using GNURoot to run a web application in a chrooted Debian. Both of these run without issues, so I'm confident, that one way or another a key server should run on Android. I'm going to look into SSHDroid first, since that would be a more universal solution. Unfortunately GNURoot and Root is not always available.

[fetzerms]

I think we dont require much on the keyserver side. Forcing a specific key to just execute a single command (and not allow it to do anything else). If those requirements are met, we probably just need special install instructions for the keyserver on android.

[459below]

So I've done a little legwork. At the moment I'm looking into running using SSHelper and AutoStart - no root to keep it running at all times.

[459below]

So an issue could be the absence of a BASH shell at least on SSHelper. Maybe the keyserver script could be converted to a SH script.

[fetzerms]

I think this might be possible :+1:

[fetzerms]

I just checked: There shouldnt be much to do, in order to get the server script posix sh compatible. I think the hash comparison (= instead of ==) is one of the main things. Aside from changing the shebang.

[459below]

That's great to hear. The shebang maybe needs a bit of consideration, since we probably won't find the bin folders in the usual place on Android devices. In fact, I couldn't find a sh in /system/bin /vendor/bin or /vendor/xbin on my Pixel. (It's /system/bin/sh) Though I didn't look too much, I still think we would deal with a lot of variance. At this moment I'm calling cat directly from the get_key-script.

I have made a few unlocking attempts, which did connect to the phone, but failed to transmit the proper key. I'm having a few concerns about how this particular SSH-Server, SSHelper, responds.

hackili-wifi:~ tmasar$ ssh -p 2222 rex "echo test" SSHelper Version 10.5 Copyright 2017, P. Lutus test

I have already tried to surpress the banner by touching .hushlogin and tailing and grepping, but that yielded no better outcome. I suspect this banner could be parsed as part of the key and thus obviously breaking the unlocking process.

I'll probably look into other SSH-Servers for unrooted phones, since I don't want to overcomplicate the get_key-script.

[459below]

SimpleSSHD could be better.

[fetzerms]

For now, we're using "command=" which forces a specific command. This ensures that the ssh-keys for retrieving the keyfiles cannot open a interactive session (and therefore retrieve more than just the own key).

This is an important requirement. It would be bad if any key can login and have an interactive shell. So we either need to find a way to work around this (different shell users per keyfile?) or we need a ssh server that supports forcing of commands.

[459below]

I think the command is being honoured.

I'm starting my tests on SimpleSSHD. I'm very confident, that this should proof to be very compatible, since it's a ported Dropbear.

[459below]

Regarding the retrieval script I'm getting: haxter:Desktop tmasar$ ssh -p 2222 rex "sh crypt-scripts/retrieve_manus.459below.lan_key" crypt-scripts/retrieve_manus.459below.lan_key[2]: ${SSH_ORIGINAL_COMMAND^^}: bad substitution I'm setting the command directive to be catting the file directly for now.

[fetzerms]

The ${SSH_ORIGINAL_COMMAND^^} ensures, that the mac address is in all uppercases. Tho this only works in bash. We could replace this with tr or awk.

tr '[:lower:]' '[:upper:]'
tr 'a-z' 'A-Z'

Might work, if we have tr available. If not, we need to find another way.

[459below]

awk is also unavailable, but tr is!

[459below]

Eureka! So I just successfully unlocked using Dropbear on my unrooted Pixel.

[459below]

I think in order to maintain compatibility the shebang on the key-server scripts should look something like this:

#!/usr/bin/env sh

[459below]

Well, no. That doesn't work either.

127|sailfish:/data/data/org.galexander.sshd/files $ which env                  
/system/bin/env

I'm going to work with command= sh ./crypt-scripts/.... I don't have a better idea ATM.

[459below]

OK. awk '{ print $1 }' can be replaced with | cut -c -40