ssh and passwords

[Jason Harris]

On Mar 27, 2011, at 4:20 AM, Kevin Bullock wrote:

> On 25 Mar 2011, at 6:31 PM, Jason Harris wrote:
> 
>> On Mar 26, 2011, at 12:14 AM, Benoit Boissinot wrote:
>> 
>>> On Fri, Mar 25, 2011 at 11:11 PM, Jason Harris <jason at jasonfharris.com> wrote:
>>>> Actually,
>>>> 
>>>> I have a rough understanding of this and the fact that ssh is asking for these things outside the normal stdin, stdout, stderr. Would there be interest in fixing this by using eg http://www.lag.net/paramiko/ or something similar. Or is there a better way to fix this?
>>> 
>>> That is not something we want to "fix". Passwords in url for ssh are a
>>> *really* bad idea, please use ssh keys if you need interactive mode.
>> 
>> First: Ok... But then why are passwords in URL's allowed for https?
> 
> They are allowed but hidden on output, and since HTTP communication is *not* done by shelling out to an external program, there's no risk of the password showing up in `ps` (unless a user explicitly passes a URL containing a password _to hg_).

From what I can tell I don't think thats the reason. Internally the communication that launches https doesn't actually use the password in the URL. (see eg httprepo.py  and specifically the line self._url, authinfo = url.getauthinfo(path)) Thus since in general it looks like the lower levels of Mercurial and its interface through to urllib2 don't use passwords in URL's...  Then the only reason to allow passwords in the URL is so people can call mercurial with a URL... and well pass a password.

> By the same reasoning, of course, tools that invoke `hg` should avoid passing HTTP URLs to it that contain passwords.

But thats the only reason for actually allowing passwords in https URL's in the first place (ie to pass a password)...

If this is deemed to be an incredible security risk then there are other inconvenient alternatives. Eg
(i) force the storage of a password in a file and pass the file name through as some parameter.
(ii) Or force mercurial to use some python / system keychain sort of thing.
(iii) have some variable like git's core.askpass variable.

But these things are optional... If the user wants these levels of security (to ensure that someone can't password snoop on their own box through `ps` then they can use eg (i) through [auth] section in the hgrc, (ii) through the keyring extension...

However, probably most of the time people will be the only user on their own boxes so jumping through the above hoops would be just a nuisance. (Also if you want hardened security then ssh is already working and suffers from none of these concerns.)

Anyway, likely in the end I think the main reason its allowed for https and not for ssh, is that its hard to do it for ssh and its easy to do it for https... But this of course means the user facing interface appears to be inconsistent between https and ssh (or at the very least different).

Cheers,
  Jas