Currently the assistant sets up dedicated ssh keys, that can just use git-annex. This is ok. The problem is that the initial 2 connections to the ssh server when setting up these keys involve a password prompt, which is done at the console unless the system happens to have a working ssh agent that can pop up a dialog. That can be confusing.
It would be nice to have the webapp prompt for the password. Can it be done securely?
This might come down to a simple change to the webapp to prompt for the password, and then rather a lot of pain to make the webapp use HTTPS so we can be pretty sure noone is sniffing the (localhost) connection.
- If ssh-askpass is in PATH, or
SSH_ASKPASSis set, do nothing. (Unless webapp is run remotely.)
XXX not currently done; the UI would need to omit the password entry fields in this case.
- Otherwise, have the assistant set
SSH_ASKPASSto a command that will cause the webapp to read the password and forward it on. Also, set DISPLAY to ensure that ssh runs the program. done
Looking at ssh.exe, I think this will even work on Windows; it contains the code to run ssh-askpass. (It does work on Windows!)
securely handling the password
- Maybe force upgrade webapp to https? Locally, the risk would be that root could tcpdump and read password, so not large risk. If webapp is being accessed remotely, absolutely: require https.
- Use hs-securemem to store password.
- Avoid storing password for long. Erase it after webapp setup of remote is complete. Time out after 10 minutes and erase it. done
- If the user is slow, the cached ssh key can exire before they finish. This results in ssh being given no password, and failing. The UI now detects this and suggests the user retry. done
- Prompt using a html field name that does not trigger web browser password saving if possible.
ssh-askpass shim, and password forwarding
SSH_ASKPASS needs to be set to a program (probably git-annex)
which gets the password from the webapp, and outputs it to stdout. done
Seems to call for the webapp and program to communicate over a local socket (locked down so only user can access) or environment. Environment is not as secure (easily snooped by root). Local socket probably won't work on Windows. Could just use a temp file.
(Currently uses a temp file with locked down perms that it's careful to clean up after use.)
Note that the webapp can probe to see if ssh needs a password, and can prompt the user for it before running ssh and the ssh-askpass shim. This avoids some complexity, and perhaps some attack vectors, if the shim cannot requst an arbitrary password prompt. (This complexity not needed with the temp file approach..)
- test on OSX
- test on Android
- remove the vestigial terminal on Windows and Android, since this was the last thing actually using it (not easy!)