On Fri, 16 Sep 2011 15:31:55 +0200, John Arbash Meinel <j...@arbash-meinel.com> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > I don't know if this is relevant or not, but bzr follows the > recommended protocol and tries to "auth_none" to get the list of > supported protocols, and then do the real authentication. We did this > in order to allow 'bzr push lp:...' to not prompt the user for a > password that Launchpad won't support anyway.
Funnily enough, this is related to how I ended up implementing this. I wanted to know if it was possible to offer different authentication strategies to different usernames, and then I found that most clients start with auth_none (which includes a username), so you can support anonymous access by just allowing auth_none to succeed for a particular username... > I could be wrong about what 'auth_none' is versus your anonymous > authentication. It also looks like we try to do RSA and then DSA > authentication before we do auth_none. So maybe it wouldn't change > anything. Ah yeah, I see what you mean looking at the code. My code accepts any authentication at all for the anonymous username though, so if bzr finds a key and offers it, it will be accepted (without looking at the key at all). I guess this means that the user might get prompted to decrypt their key and that could be a bit confusing. All the above only applies if you're using paramiko for ssh of course, openssh starts out with an auth_none request. I guess bzr tries key-based first as an effort to save a roundtrip? Cheers, mwh > John > =:-> > > On 9/16/2011 5:49 AM, Michael Hudson-Doyle wrote: > > On Fri, 16 Sep 2011 13:02:56 +1000, Martin Pool <m...@canonical.com> > > wrote: > >> On 16 September 2011 12:51, Michael Hudson-Doyle > >> <michael.hud...@linaro.org> wrote: > >>> Hi all, > >>> > >>> While thinking about something else, I mostly accidentally > >>> implemented a potentially interesting feature for Launchpad, > >>> anonymous read-only ssh access to Launchpad: > >>> > >>> https://code.launchpad.net/~mwhudson/launchpad/anon-ssh-hack/+merge/75442 > >> > >> > >>> > That's awesome, and an impressively small patch. Thanks for jfdi. > > > > Glad you like it :) > > > >> A few thoughts: * this would be (I think 'should') be behind a > >> feature flag - it is a perfect example of something we might want > >> to deploy and then later turn off > > > > Ah yes. The fun here is that the ssh server does not connect to > > the database currently (is this still right?) so we'd need to add > > some private xml-rpc method to query the flag. As wgrant points > > out, getting the scopes right for a general such method might be a > > bit tricky but for this particular use case it's trivial. The > > premature optimizer in me wants to avoid making another XML-RPC > > call per log in too, but we can ignore him I think. > > > > A somewhat scope aware feature flag method would also be useful for > > the forking server codehosting stuff I guess, so maybe I'll poke at > > that when I next get a free evening. > > > >> * also, I think logging when people connect so that we can count > >> it would be well worth while (or perhaps it's handled at a > >> different level) > > > > This is already there, due to other machinery: > > > > $ tail -n5 /var/tmp/bazaar.launchpad.dev/codehosting-access.log > > 2011-09-15 10:58:34,020 INFO [91675392] IPv4Address(TCP, > > '127.0.0.1', 52354) connected. 2011-09-15 10:58:34,078 INFO > > [91675392] +launchpad-anonymous logged in. 2011-09-15 10:58:34,087 > > INFO [91675392] +launchpad-anonymous disconnected. 2011-09-15 > > 10:58:34,087 INFO [91675392] disconnected. 2011-09-15 12:07:31,512 > > INFO ---- Server stopped ---- > > > >> Those should both be a matter of just a few lines. > >> > >> Much as the web is moving towards "ssl everywhere" I think doing > >> everything over SSH has some substantial advantages: mitm > >> protection, and probably more often important protection against > >> non-malicious but clueless intervention by http proxies or other > >> firewalls, and also an integrity check against packet corruption. > >> (Though, if any of those things do happen, it can be confusing > >> for the user, but that's out of scope.) So I would be happy with > >> this rather than bzr+http or bzr+tcp. > > > > Cool. > > > >> There is also a bit of a thing that people can now anonymously > >> make us spend a fair amount of cpu effort, and in the event there > >> is an exploitable attack in the smart server, they can get at it > >> without creating an account. Obviously creating an account is > >> pretty easy, so perhaps it doesn't matter. > > > > There is a difference between "pretty easy" and "trivial" when it > > comes to DoS I guess. Less so for the exploit thing (more reasons > > for the feature flag). > > > >> This also needs some ux consideration about when/how people use > >> this, or configure bzr to use it. > > > > Yeah. If successful, we could even get bzr to use it for lp:/// > > urls when no username is configured (and thus not have lp: name > > resolution roundtrip to launchpad ever, which would be nice). > > > >> But, I don't think that needs to block this. I can imagine this > >> would be useful even just for cases where people very > >> specifically configure it, like for a CI server. > > > > Yes indeed. > > > > Cheers, mwh > > > > _______________________________________________ Mailing list: > > https://launchpad.net/~launchpad-dev Post to : > > launchpad-dev@lists.launchpad.net Unsubscribe : > > https://launchpad.net/~launchpad-dev More help : > > https://help.launchpad.net/ListHelp > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (Cygwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAk5zT8sACgkQJdeBCYSNAAPacACcC6/XbCgZWNQiUiKvcmln2PHD > 5jwAn1cTowPaAzRAoH8nIuJRdBtSAYk4 > =q6xS > -----END PGP SIGNATURE----- _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
