ssh and passwords

Martin Geisler mg at
Fri Mar 25 18:06:10 CDT 2011

Jason Harris <jason at> writes:

> I have had a glance over the code in and looking at it one
> can see that we currently have bugs like:
>   hg identify --noninteractive ssh://jason@
> and running this command prompts me interactively for my password
> (when I of course explicitly asked for non-interactive.)

There is a long tradition of delegating the setup of the SSH tunnel
itself to the system's ssh program. In this sense Mercurial behaves
like, say, rsync.

The advantage of this is that everything is "normal": I can do

  $ hg clone ssh://bb/mg/foo

after I've configured my SSH to expand "bb" to hg at I can
expect Mercurial to use the SSH keys I've loaded into my agent, and
things like agent forwarding just works. In other words: it's very, very
nice that Mercurial behaves like expected, when you know what to expect.

> I just became aware of this since previously all of my ssh connections
> were passwordless, and I had access to all my servers as one normally
> would so I was a bit surprised to find that ssh protocol didn't handle
> passwords in its URL... See

It's terribly insecure to accept passwords in command line arguments.
Everybody can see them by running 'ps'... that is why a secure SSH
implementation wont let you do it.

> 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 or
> something similar. Or is there a better way to fix this?

Mercurial has a policy of only depending on the Python standard library.
So we should bundle paramiko if we want to depend on it.

Martin Geisler

Mercurial links:
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <>

More information about the Mercurial-devel mailing list