Hi, a new user trying out git-annex 3.20130124 here. So far looks really promising, thanks.
I setup a local annex using the assistant webapp. I then created a rsync cloud repo over ssh to my shell box in a nearby data center for it. Works ok. I already have ssh key setup inclding ssh-agent for quick logins to the server. It would be great if you could configure the assistant to use these existing keys instead of creating a new set of keys. Maybe keep the defaults as is, but provide the config for this hidden behind "trust me, I know what I'm doing" check box or something.
Thanks again, I keep researching.
I also found the key setup confusing. I have many identity files for several server / service combinations, so the webapp key setup for an ssh+rsync cloud server always failed with too many identification attempts before I had the sense to move my keys temporarily away from ~/.ssh
It would be really nice if the webapp would allow one either to pick an existing identity, or to create a new one with the aid of a couple of password logins.
Also, having the created key to be restricted to only running rsync in the server would improve the chances of 'Share with a friend' use case being used. I don't think many people will want to give out full shell access to their servers in order to share some files.
When pairing with a local computer, both systems set up locked down ssh keys that only allow the pair to run git-annex on the repository being paired with. This does not involve full shell access.
The "remote server" necessarily involves you already having shell access to the remote server. However, the ssh key that the assistant generates is again locked down to only being able to run git-annex on a single repository on the remote server.
Is there an argument against the original request of being able to use an existing non-default ssh key when setting up a remote ssh repo with the webapp?
As suggested above, one could reasonably have different identities, not all of which should have access to the git-annex repo. AFAIU, the way things are one has to either use their default identity with a remote ssh repo OR temporarily enable password authentication on the server so that the webapp will generate and install its own key, then turn it off. That is a tall order and might not even be possible if the server is not under the user's control. Am I missing something?