Add Support for SSH Keys

[whoisj]

SSH is popular, it doesn't get much love on Windows - we need to give it love because it is awesome.

[simon-p-r]

👍

[dscho]

When it comes to OpenSSH, maybe imitate ssh-agent's protocol?

[simon-p-r]

Yes I was hoping for something like ssh-agent

[dscho]

So @simon-p-r... here's your chance, it's all Open Source now ;-)

[simon-p-r]

Sure @dscho however I am not a c# programmer I am afraid 😞 so can't help not won't help! I can always write documentation once I know how it works. In the past I have tried various hacks and scripts to get ssh-agent working on Windows but none I would safely want to use!

[boxfoot]

+1

[etruong42]

I currently use pageant to manage my SSH keys on Windows. I wouldn't mind a more powerful option that could keep the passphrase stored on disk (encrypted, of course) so that I don't have to enter it each time I log in to my Windows account.

[bgstcola]

+1

[silentsilas]

+1

[whoisj]

/cc @jeremyepling

[dac514]

+1

[dscho]

+1

While I appreciate the enthusiasm to put on record your desire to see this issue resolved, I cannot help but notice that the information that might help implement the feature is drowned out by those "me, too" messages... Probably unintended?

[whoisj]

I cannot help but notice that the information that might help implement the feature is drowned out by those "me, too" messages

A very fair concern @dscho, but the "me too" votes will get translated into priority so that I get time to work on adding the feature. 😉

[talha131]

+1

[kjeremy]

👍

[thomasdarimont]

+1

[matsprea]

As for Why am I not seeing my SSH keys being saved?.
Please Support SSH.

[MichaelPolla]

+1 :-) and thanks for the already awesome work !

[ghost]

+1

[emmagarland]

+1

[xJom]

+1

[stefanodriussi]

+1

[ncthbrt]

+1
This has been a major pain point for me. Not having credential caching makes the use of many awesome git tooling near impossible.

[acromm]

+1

[ctipper]

Not sure that this is the right issue I can't get credential store to work for ssh:// protocol with a local dev server. Now it happens that this tunnels over SSH but I don't see how managing keys would help all I want is for it to store my credentials in Windows Credential Cache, which somehow is not happening on my dev machine. which git-credential-manager returns %HOME%\bin somehow it never gets invoked. It's almost useless for my purposes, surely somebody runs basic tests before releases?

[whoisj]

I can't get credential store to work for git:// protocol

The GCM only supports HTTPS currently. I'm not even sure what supporting the git:// protocol would entail as it's is nearly always used of SSH in my experience.

surely somebody runs basic tests before releases?

Of course we do, but your use-case isn't supported at the moment.

[ctipper]

So I apologise winstore never had this functionality so please consider this a feature request. I know it is possible to set up ssh keys in such a way as not to require a password, but it seems such a obvious use case to just store a password. It is some time since I have used Windows for this purpose, my main machine is a Mac.

I ought to clarify that I am actually talking about the ssh protocol git clone user@server:project.git I don't think the git protocol is quite the same thing, my mistake.

[dscho]

I can't get credential store to work for git:// protocol

git:// is not authenticated. At all. Which credentials should we store, then?

[ctipper]

I corrected my mistake, see above. But surely ssh is an encrypted version of the git protocol?

[whoisj]

But surely ssh is an encrypted version of the git protocol?

Kind of. SSH provides a secure tunneling layer, through which you can perform encrypted operations safely (tm).

[dscho]

But surely ssh is an encrypted version of the git protocol?

No, it is not an encrypted version of the git:// protocol. The git:// protocol is an independent protocol altogether, ssh is a mechanism to run executables on a remote machine (sporting its very own, encrypted protocol that has nothing to do with Git whatsoever).

When Git uses ssh to talk to remote repositories, the process is actually closer to talking to local repositories than to using the git:// protocol. Both when using the git:// protocol and when using ssh, Git is not concerned with authentication at all. When using ssh, that responsibility is left entirely to ssh.

So let's stop talking about this right here and right now:

• the desired feature has nothing to do with this here ticket (and therefore the discussion messes this ticket up rather well),
• the desired feature does not even have anything to do with the Git Credential Manager, but with the git daemon (which is part of core Git),
• and even if taking this feature request upstream it is quite unlikely to be implemented, for several reasons:
  • the git:// was not designed to be authenticated/encrypted, ever, and
  • it would be a ton of work to implement it, which means that simply dropping a feature request and expecting others to spend time for your pleasure is not really going to work.

[ctipper]

I am sorry for messing up your ticket I have solved my issue by the key exchange I mentioned and will not waste any of your precious time in future. And by the way because I know English is not your first language I will point out again that I was NOT talking about the git protocol. I don't care and with your attitude I am not sure I care about this project now.

[dscho]

You are a very rude German.

That is not possible:

😃

Anyway, I really tried to help you understand why there is no connection between your feature request and this ticket, and I really, really tried to give you enough information and pointers to be helpful. So maybe my language can be forgiven?

[MatthiasF999]

+1

[dscho]

@MatthiasF999 please use "reactions" instead of extraneous comments. They are much more visible for what you intended to do.

[RaeesBhatti]

Any updates on this?

[dscho]

SSH functionality is not provided by Git itself, but by an external program. By default, this external program is OpenSSH, and if the user already has saved PuTTY connections, Git for Windows' installer also offers to configure PuTTY to do the job. Additionally, Git lets the user override this configuration to use yet other SSH programs for the job, via the environment variable GIT_SSH (or GIT_SSH_COMMAND).

All of these SSH implementations need to stay independent of Git. Their primary purpose is not to support Git, but to support SSH connections. Seeing as the Git Credential Manager is a very Git-centric component, it would be improper to change those SSH implementations to rely on the Credential Manager all of a sudden.

Having said that, it is possible to modify, say, OpenSSH to interact optionally either with the Git Credential Manager or directly with the credential store, compatible with the Credential Manager.

That would definitely be outside the purview of the Git Credential Manager project.

I would therefore recommend to close this ticket.

Having said that, as all of the involved components are Open Source, there is nothing to stop any developer who wants this badly enough.

So let's have a closer look at OpenSSH. Normally one would store private keys in %HOME%\.ssh (that location shows OpenSSH's Unix heritage). But there are two more ways to specify private keys: ssh-agent and something called PKCS11Provider.

Now, ssh-agent is a well-known solution to avoid having to type in the passphrase multiple times. But ssh-agent is also an external program that speaks to OpenSSH via a Unix sockets (in Git for Windows' case emulated via TCP sockets or MSYS2 via named pipes). From a cursory look, the protocol looks simple enough: http://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/src/usr.bin/ssh/PROTOCOL.agent?rev=1.8&content-type=text/plain

So: a developer who really wants to store SSH keys in their credential store could implement a custom ssh-agent that talks to the credential store (or to the Git Credential Manager). This would need to be an MSYS2 program if it wants to speak to the OpenSSH shipped with Git for Windows.

And there is also PKCS11Provider (see http://man.openbsd.org/OpenBSD-current/man5/ssh_config.5 how to configure OpenSSH to use such a provider). And this is where things get interesting: typically known as "that smartcard thing", PKCS#11 is actually a real API specification: https://www.emc.com/emc-plus/rsa-labs/standards-initiatives/pkcs-11-cryptographic-token-interface-standard.htm. All it needs is a PKCS#11 compliant .dll that talks to the Git Credential Manager (and that .dll does not need to be an MSYS2 one, heck, it does not even need to be written in C!). The full PKCS#11 specs are available here: ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-11/v2-30/pkcs-11v2-30b-d6.pdf. It looks as if it is quite a bit convoluted, even if we would probably only implement the key-related functions. Definitely not an afternoon project, unfortunately.

On the other hand, if you only want to store the passphrase in the credential store, you may want to use https://github.com/lukesampson/askpass in combination with SSH_ASKPASS.

In any case, as I said, from my point of view this ticket should be closed because

1. it is outside of Git Credential Manager's purview, and
2. anybody who wants to store SSH keys in their credential store has enough information to go and get started with implementing it.

[ncthbrt]

@JohannesSchlindelin Thanks for the great reply.
On 12 Apr 2016 10:42, "Johannes Schindelin" notifications@github.com
wrote:

SSH functionality is not provided by Git itself, but by an external
program. By default, this external program is OpenSSH, and if the user
already has saved PuTTY connections, Git for Windows' installer also offers
to configure PuTTY to do the job. Additionally, Git lets the user override
this configuration to use yet other SSH programs for the job, via the
environment variable GIT_SSH (or GIT_SSH_COMMAND).

All of these SSH implementations need to stay independent of Git. Their
primary purpose is not to support Git, but to support SSH connections.
Seeing as the Git Credential Manager is a very Git-centric component, it
would be improper to change those SSH implementations to rely on the
Credential Manager all of a sudden.

Having said that, it is possible to modify, say, OpenSSH to interact
optionally either with the Git Credential Manager or directly with the
credential store, compatible with the Credential Manager.

That would definitely be outside the purview of the Git Credential Manager
project.

I would therefore recommend to close this ticket.

Having said that, as all of the involved components are Open Source, there
is nothing to stop any developer who wants this badly enough.

So let's have a closer look at OpenSSH. Normally one would store private
keys in %HOME%.ssh (that location shows OpenSSH's Unix heritage). But
there are two more ways to specify private keys: ssh-agent and something
called PKCS11Provider.

Now, ssh-agent is a well-known solution to avoid having to type in the
passphrase multiple times. But ssh-agent is also an external program that
speaks to OpenSSH via a Unix sockets (in Git for Windows' case emulated via
TCP sockets or MSYS2 https://msys2.github.io via named pipes). From a
cursory look, the protocol looks simple enough:
http://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/src/usr.bin/ssh/PROTOCOL.agent?rev=1.8&content-type=text/plain

So: a developer who really wants to store SSH keys in their credential
store could implement a custom ssh-agent that talks to the credential
store (or to the Git Credential Manager). This would need to be an MSYS2
program if it wants to speak to the OpenSSH shipped with Git for Windows.

And there is also PKCS11Provider (see
http://man.openbsd.org/OpenBSD-current/man5/ssh_config.5 how to configure
OpenSSH to use such a provider). And this is where things get interesting:
typically known as "that smartcard thing", PKCS#11 is actually a real API
specification:
https://www.emc.com/emc-plus/rsa-labs/standards-initiatives/pkcs-11-cryptographic-token-interface-standard.htm.
All it needs is a PKCS#11 compliant .dll that talks to the Git Credential
Manager (and that .dll does not need to be an MSYS2 one, heck, it does
not even need to be written in C!). The full PKCS#11 specs are available
here:
ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-11/v2-30/pkcs-11v2-30b-d6.pdf. It
looks as if it is quite a bit convoluted, even if we would probably only
implem ent the key-related functions. Definitely not an afternoon project,
unfortunately.

On the other hand, if you only want to store the passphrase in the
credential store, you may want to use
https://github.com/lukesampson/askpass in combination with SSH_ASKPASS.

In any case, as I said, from my point of view this ticket should be closed
because

1. it is outside of Git Credential Manager's purview, and
2. anybody who wants to store SSH keys in their credential store has
   enough information to go and get started with implementing it.

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#25 (comment)

[whoisj]

I'm going to have to agree with @dscho here and close the ticket.

That does not mean we'll never come back to this issue and attempt a solution, it just means that for now I'd rather not get everyone's hopes up before we have an idea on how I could deliver a solution.

[RaeesBhatti]

Hey everyone, I've recently created a helper utility that configures your Windows environment to let you use ssh from Command Prompt, PowerShell, Bash or any other terminal. It basically runs ssh-agent and publishes its variables as User's environment variables.
You can then run ssh-add to add keys to the agent (or configure the tool to add them at startup) and just access your server with ssh or do git push/pull.

Try it out!
https://github.com/elsteelbrain/ssh-agent-helper