ssh and passwords

[Steve Borho]

On Fri, Mar 25, 2011 at 7:26 PM, Jason Harris <jason at jasonfharris.com> wrote:
>
> On Mar 26, 2011, at 1:06 AM, Mads Kiilerich wrote:
>
>> Jason Harris wrote, On 03/26/2011 12:31 AM:
>>> First: Ok... But then why are passwords in URL's allowed for https?
>>
>> That is a Python standard library feature. Mercurial doesn't do anything to support it. (Except hiding the password before we show URLs.) There is also a tradition for putting passwords in http urls.
>
> Exactly.
>
>> ssh doesn't have urls and fortunately doesn't have that tradition.
>
> Also true.
>
> So I understand the root of the cause of why passwords are allowed in URL's for https but not for ssh, but the implementation details of the lower levels should not always drive the design of the upper level Mercurial interface. (Of course if its insanely difficult to make https and ssh have the same sort of overall interface / handling / configuration, etc then well thats a different matter.) But consistency in handling of https and ssh would seem to me to be a good thing...
>
> Also, I just thought this might be a sort of solved problem since it seems many others want to be able to do this sort of thing. Certainly googling for ssh and python brought up a lot of hits...
>
>
>>> (Also you don't want to fix allowing the users to set username and password in the [auth] section for ssh connections either I take? (But you still want to allow these for https?)
>>
>> I think it would be nice to have an option for using paramiko for  ssh - especially on windows. So far nobody has implemented that.
>>
>> I'm sure Mercurial would have better support for configuring ssh if it had been possible. Let's see what happens if it becomes possible.
>>
>> FWIW, there is anecdotal evidence that paramiko is sufficiently slower than "real" ssh. That might be true or not.
>
> Yeah I worried about any slow downs with using paramiko...

I posted a patch to hg-dev about a year ago that made hg use paramiko
to open ssh connections.  I never finished it because paramiko wasn't
any faster than the most recent Plink tools.

> I am still worried about what the best way to present this to users in a seamless GUI interface is... Can the TortiseHg guys comment on what they do here?

We ship TortoisePlink, ruthlessly borrowed from TortoiseSVN, and the
Pageant key agent.  It's notoriously slow and doesn't appear to use
compression in many cases where it should.  I have an open enhancement
request to evaluate the TortoisePlink shipped by TortoiseCVS; as it
appears to be a newer fork of Plink and so it has more bug fixes.

> Right now I am about to just hide (via a roll up) the password field once the base connection scheme is ssh... Users will clearly see the intent but most likely they will react by "Hey! I can't enter a password if I am using ssh... What's up with that?!?"

For https we hide all passwords by default, don't have any mechanism
for the user to add them to URLs, and strip usernames and passwords
from URLs when they are saved; unless the user opts to keep them.
Instead, we puah users towards [auth] and the mercurial_keyring
extension.

For ssh, TortoisePlink handles all the password prompting and will use
Pageant if it is running.

> Thus, MacHg can easily communicate to Mercurial what password the user wants to send if they are ever questioned, but right now I see no easy way to change Mercurial in such a way that it actually sends that password through if any ssh ever prompts for the password...

Mercurial never sees password prompts from ssh.  They go directly
between ssh and the user.

-- 
Steve Borho