On Wed, 11 Sep 2013 05:03:27 -0700 (PDT)
berd <bersc...@googlemail.com> wrote:

> Now to testing we created new ssh key, but to working, we use other
> ssh key.
> For me is the question, how can I tell git-bash to take the new ssh
> key?

Do you have to keep the test key or you just want to *replace* it with
the production key?  If replacement is needed, then just overwrite the
id_rsa and id_rsa.pub files in your %HOME%\.ssh folder with the new
ones (they might also be named id_dsa[.pub], and the .pub file (the
public part of the key) is not strictly needed -- it can always be
regenerated from the private key, and it does not participarte in

If you want to have both keys, continue reading.

> http://superuser.com/questions/232373/tell-git-which-private-key-to-use
>  but both do not work quite.

The solution at the quoted link is the correct one for your case.
How exactly did it not work out?

Did you try to log in via plain SSH client and not make Git call it for
you? -- this is the first thing to try when debugging.

Open Git bash and run something like

ssh -T user@host git --version

there and see if it a) succeeds, and b) prints of the version of Git
running on the remote system.

If it fails to log in, try to pass one or more "-v" options to ssh --
the more you pass the more chattier it becomes, -- so try

ssh -T -vvv user@host git --version

Does this printout mention SSH reading the correct key file?  Does it
tell anything about failure to locate or read or parse it?

Yet another approach to the problem is to switch to using the so-called
SSH key agent -- this is a program which sits in memory permanently,
and maintains decrypted private keys, which you submit to it exactly
once, and when an SSH client tries to authenticate to the server using
a private key it first tries to find and contact the key agent, and if
it succeeds, asks the agent for the keys it has, and tries to use them.

Stock Git for Windows includes a port of OpenSSH client, and so it
includes the ssh-agent.exe binary.  You can use it like this:

1) Start Git bash.

2) Run

   eval $(ssh-agent -s)

   which would a) place the agent into memory, and b) equip *this
   session* of Git bash with the necessary knowledge about how to reach
   the agent.

3) Run

   ssh-add /path/to/your/private/key/file

   several times for each of your keys, entering the passphrase for

4) Next time you run ssh it will try to contact the agent and get keys
   from it.

5) Before closing Git bash, run

   kill $SSH_AGENT_PID

   to shut down the running agent.
   If you won't do this and will just close the Git bash, the agent will
   remain in memory, and the next Git bash shell *won't* reuse it.
   On the other hand, having it in memory won't hurt other than
   occupying it -- you could kill it any time using Task Manager.

You might customize this sort of setup by tweaking various per-user
bash configuration files -- it could achieve running the agent at
opening Git bash and killing it when Git bash closes.  Personally,
I don't have a ready to offer knowledge of how to do this, but it's

Another approach with the key agent is to switch to using PuTTY [1]
instead of using the OpenSSH agent shipped with Git for Windows.
PuTTY's advantage is that it's better integrated into the system, and
its key manager (pageant.exe) comes in a form of a GUI app which sits
in the system notification area ("the tray").

To use putty, you'll have to permanentry set the environment variable
"GIT_SSH" (on a system or user level) to something like
%ProgramFiles%\PuTTY \plink.exe

Note that TortoiseSVN and TortoiseGit come with their own patched
version of plink.exe which is able to ask mandatory quesions using a
GUI dialog.  So if you have one/want to use it, you could set your
GIT_SSH to something like
Note though that TortoiseFoos do not include the full stack of PuTTY
utilities, so you have to install it anyway to use its key agent.

A complete step-by-step guide (with pictures galore) on how to set up
Git for Windows to work with PuTTY including using the key agent is [2].

1. http://www.chiark.greenend.org.uk/~sgtatham/putty/
2. http://nathanj.github.io/gitguide/index.html

For the future, please note that it's futile to ask for help while
provifing zero information about how the faulty program actually fails
-- "did not quite work" is not the statement of a problem.

You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to