mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
git-annex/doc/design/assistant/sshpassword.mdwn

66 lines
2.8 KiB
Text
Raw Normal View History

roadmap for next year's work
2013-07-23 22:46:09 +00:00
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.
design
2014-04-25 20:28:58 +00:00
## ssh-askpass approach
update
2014-04-26 22:58:06 +00:00
* If ssh-askpass is in PATH, or `SSH_ASKPASS` is set, do nothing.
webapp: Better ssh password prompting. When setting up a remote on a ssh server, prompt for a password inside the webapp, rather than relying on ssh's own password prompting in the terminal the webapp was started from, or ssh-askpass. Avoids double prompting for the ssh password (and triple-prompting on windows for rsync.net), since the entered password is cached for 10 minutes and this cached password is reused when setting up the repository, after the initial probe. When the user has an existing ssh key set up, they can choose to use it, rather than entering a password. The webapp used to probe for this case automatically, so this is a little harder, but it's an advanced user thing. Note that this commit is known to break enabling existing rsync repositories. It hs not been tested with gcrypt repositories. It's not been successfully tested yet on Windows. This commit was sponsored by Ralph Mayer.
2014-05-14 19:02:18 +00:00
(Unless webapp is run remotely.)
XXX not currently done; the UI would need to omit the password entry
fields in this case.
design
2014-04-25 20:28:58 +00:00
* 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
webapp: Better ssh password prompting. When setting up a remote on a ssh server, prompt for a password inside the webapp, rather than relying on ssh's own password prompting in the terminal the webapp was started from, or ssh-askpass. Avoids double prompting for the ssh password (and triple-prompting on windows for rsync.net), since the entered password is cached for 10 minutes and this cached password is reused when setting up the repository, after the initial probe. When the user has an existing ssh key set up, they can choose to use it, rather than entering a password. The webapp used to probe for this case automatically, so this is a little harder, but it's an advanced user thing. Note that this commit is known to break enabling existing rsync repositories. It hs not been tested with gcrypt repositories. It's not been successfully tested yet on Windows. This commit was sponsored by Ralph Mayer.
2014-05-14 19:02:18 +00:00
DISPLAY to ensure that ssh runs the program. **done**
design
2014-04-25 20:28:58 +00:00
deal with ssh key expiry Not a perfect solution, but good enough, few users will wait 10 minutes in the middle and see it expire, I hope.
2014-05-15 19:15:19 +00:00
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!)
design
2014-04-25 20:28:58 +00:00
### 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
devblog
2014-04-25 20:34:33 +00:00
is being accessed remotely, absolutely: require https.
design
2014-04-25 20:28:58 +00:00
* Use hs-securemem to store password.
* Avoid storing password for long. Erase it after webapp setup of remote
deal with ssh key expiry Not a perfect solution, but good enough, few users will wait 10 minutes in the middle and see it expire, I hope.
2014-05-15 19:15:19 +00:00
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**
devblog
2014-04-25 20:34:33 +00:00
* Prompt using a html field name that does not trigger web browser password
saving if possible.
design
2014-04-25 20:28:58 +00:00
### ssh-askpass shim, and password forwarding
`SSH_ASKPASS` needs to be set to a program (probably git-annex)
webapp: Better ssh password prompting. When setting up a remote on a ssh server, prompt for a password inside the webapp, rather than relying on ssh's own password prompting in the terminal the webapp was started from, or ssh-askpass. Avoids double prompting for the ssh password (and triple-prompting on windows for rsync.net), since the entered password is cached for 10 minutes and this cached password is reused when setting up the repository, after the initial probe. When the user has an existing ssh key set up, they can choose to use it, rather than entering a password. The webapp used to probe for this case automatically, so this is a little harder, but it's an advanced user thing. Note that this commit is known to break enabling existing rsync repositories. It hs not been tested with gcrypt repositories. It's not been successfully tested yet on Windows. This commit was sponsored by Ralph Mayer.
2014-05-14 19:02:18 +00:00
which gets the password from the webapp, and outputs it to stdout. **done**
design
2014-04-25 20:28:58 +00:00
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).
support being run by ssh as ssh-askpass replacement To use, set GIT_ANNEX_SSHASKPASS to point to a fifo or regular file (FIFO is better, avoids touching disk or multiple readers) that contains the password. Then set SSH_ASKPASS=git-annex, and when ssh runs it, it will tell ssh the password. This is not yet used..
2014-04-29 22:08:10 +00:00
Local socket probably won't work on Windows. Could just use a temp file.
design
2014-04-25 20:28:58 +00:00
webapp: Better ssh password prompting. When setting up a remote on a ssh server, prompt for a password inside the webapp, rather than relying on ssh's own password prompting in the terminal the webapp was started from, or ssh-askpass. Avoids double prompting for the ssh password (and triple-prompting on windows for rsync.net), since the entered password is cached for 10 minutes and this cached password is reused when setting up the repository, after the initial probe. When the user has an existing ssh key set up, they can choose to use it, rather than entering a password. The webapp used to probe for this case automatically, so this is a little harder, but it's an advanced user thing. Note that this commit is known to break enabling existing rsync repositories. It hs not been tested with gcrypt repositories. It's not been successfully tested yet on Windows. This commit was sponsored by Ralph Mayer.
2014-05-14 19:02:18 +00:00
(Currently uses a temp file with locked down perms that it's careful
to clean up after use.)
design
2014-04-25 20:28:58 +00:00
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.
webapp: Better ssh password prompting. When setting up a remote on a ssh server, prompt for a password inside the webapp, rather than relying on ssh's own password prompting in the terminal the webapp was started from, or ssh-askpass. Avoids double prompting for the ssh password (and triple-prompting on windows for rsync.net), since the entered password is cached for 10 minutes and this cached password is reused when setting up the repository, after the initial probe. When the user has an existing ssh key set up, they can choose to use it, rather than entering a password. The webapp used to probe for this case automatically, so this is a little harder, but it's an advanced user thing. Note that this commit is known to break enabling existing rsync repositories. It hs not been tested with gcrypt repositories. It's not been successfully tested yet on Windows. This commit was sponsored by Ralph Mayer.
2014-05-14 19:02:18 +00:00
(This complexity not needed with the temp file approach..)
avoid clobbering existing env This is necessary on windows, ssh couldn't resolve hostnames without env for whatever reason.
2014-05-14 20:17:30 +00:00
### TODO
* test on OSX
* test on Android
update some comments re ssh password entry on Android
2014-05-15 19:20:24 +00:00
* remove the vestigial terminal on Windows and Android, since this was the
last thing actually using it (not easy!)
Reference in a new issue Copy permalink