Jenkins SSH Cache

Hi,

What have folk done to resolve the issue with Jenkins ssh keys where the
first clone hangs because you need to accept the key (ie type yes)?
Currently I just log into the machine and clone a repo, accept the key, and
then it’s all fine.

Any way to automate this or configure around it?

-aob

On Sat, Oct 19, 2013 at 6:01 AM, Angus Buchanan
angus.o.buchanan@gmail.com wrote:

Hi,

What have folk done to resolve the issue with Jenkins ssh keys where the
first clone hangs because you need to accept the key (ie type yes)?
Currently I just log into the machine and clone a repo, accept the key, and
then it's all fine.

Any way to automate this or configure around it?

Here's how to sort that:

--
Andy Gale

http://twitter.com/andygale

Great - thanks! I'll try that!

-aob

On Sat, Oct 19, 2013 at 10:39 AM, Andy Gale andy@salgo.net wrote:

On Sat, Oct 19, 2013 at 6:01 AM, Angus Buchanan
angus.o.buchanan@gmail.com wrote:

Hi,

What have folk done to resolve the issue with Jenkins ssh keys where the
first clone hangs because you need to accept the key (ie type yes)?
Currently I just log into the machine and clone a repo, accept the key,
and
then it's all fine.

Any way to automate this or configure around it?

Here's how to sort that:

Git clone with custom SSH using GIT_SSH error - Stack Overflow

--
Andy Gale
http://andy-gale.com
http://twitter.com/andygale

Ohai,

On 19 October 2013 06:01, Angus Buchanan angus.o.buchanan@gmail.com wrote:

Hi,

What have folk done to resolve the issue with Jenkins ssh keys where the
first clone hangs because you need to accept the key (ie type yes)?
Currently I just log into the machine and clone a repo, accept the key, and
then it's all fine.

Any way to automate this or configure around it?

I use a Git config stanza like this:

Host github.com
HostName github.com
IdentityFile /var/lib/jenkins/.ssh/github
StrictHostKeyChecking no
User git

From the ssh_config manual:

StrictHostKeyChecking

If this flag is set to “yes”, ssh(1) will never automatically add host keys
to the ~/.ssh/known_hosts file, and refuses to connect to hosts whose host
key has changed. This provides maximum protection against trojan horse
attacks, though it can be annoying when the /etc/ssh/ssh_known_hosts file
is poorly maintained or when connections to new hosts are frequently made.
This option forces the user to manually add all new hosts. If this flag is
set to “no”, ssh will automatically add new host keys to the user known
hosts files. If this flag is set to “ask”, new host keys will be added to
the user known host files only after the user has confirmed that is what
they really want to do, and ssh will refuse to connect to hosts whose host
key has changed. The host keys of known hosts will be verified
automatically in all cases. The argument must be “yes”, “no”, or “ask”.
The default is “ask”.

So that lives in /var/lib/jenkins/.ssh/config.

Obviously you can render that with a template accounting for how you have
your Jenkins set up, but that's the essence of the solution.

S.

Alternatively,

I set the KnownHosts file from the configuration stanza and use chef to place what I expect the host key to be. This lets Chef do what it needs to do, while at the same time maintains the full security of host key checking.

Graham

--
Graham Christensen
Sent with Sparrow (http://www.sparrowmailapp.com/?sig)

On Saturday, October 19, 2013 at 5:15 AM, Stephen Nelson-Smith wrote:

Ohai,

On 19 October 2013 06:01, Angus Buchanan <angus.o.buchanan@gmail.com (mailto:angus.o.buchanan@gmail.com)> wrote:

Hi,

What have folk done to resolve the issue with Jenkins ssh keys where the first clone hangs because you need to accept the key (ie type yes)? Currently I just log into the machine and clone a repo, accept the key, and then it's all fine.

Any way to automate this or configure around it?

I use a Git config stanza like this:

Host github.com (http://github.com)
HostName github.com (http://github.com)
IdentityFile /var/lib/jenkins/.ssh/github
StrictHostKeyChecking no
User git

From the ssh_config manual:

StrictHostKeyChecking

If this flag is set to “yes”, ssh(1) will never automatically add host keys to the ~/.ssh/known_hosts file, and refuses to connect to hosts whose host key has changed. This provides maximum protection against trojan horse attacks, though it can be annoying when the /etc/ssh/ssh_known_hosts file is poorly maintained or when connections to new hosts are frequently made. This option forces the user to manually add all new hosts. If this flag is set to “no”, ssh will automatically add new host keys to the user known hosts files. If this flag is set to “ask”, new host keys will be added to the user known host files only after the user has confirmed that is what they really want to do, and ssh will refuse to connect to hosts whose host key has changed. The host keys of known hosts will be verified automatically in all cases. The argument must be “yes”, “no”, or “ask”. The default is “ask”.

So that lives in /var/lib/jenkins/.ssh/config.

Obviously you can render that with a template accounting for how you have your Jenkins set up, but that's the essence of the solution.

S.