1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
|
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.
## ssh-askpass approach
* If ssh-askpass is in PATH, or `SSH_ASKPASS` is 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_ASKPASS` to 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.
### 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.
* 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..)
### TODO
* test on OSX
* test on Android
* If the user is slow, the cached ssh key can exire before they finish.
Currently this results in ssh being given no password, and failing.
Either avoid time-based expiry (manually expiring when done, and how
to detect if they gave up?) or notice this and give a sensible error.
|
