1

We are using CloudBees Jenkins to run a Maven job and the build is failing when it tries to deploy Javadoc to our private Javadoc server. This is the error in the logs:

The authenticity of host 'javadoc.foo.com' can't be established.
RSA key fingerprint is 3e:69:41:8a:ec:d1:4c:d9:75:ef:7d:71:b7:7d:51:d0.
Are you sure you want to continue connecting? (yes/no):
The authenticity of host 'javadoc.foo.com' can't be established.

I would like to modify the known_hosts file on the m1.large and m1.small nodes but i don't know how.

Just thinking out loud, should I have a pre-build step that modifies the known_hosts file on the fly? Or perhaps copy a pre-built known_hosts file in the /private directory?

Sorry if this is a newbie question, but I am new to this whole "dynamically created build machines"...

carlspring
  • 31,231
  • 29
  • 115
  • 197
grayaii
  • 2,241
  • 7
  • 31
  • 47
  • Please correct me, If I'm wrong, I understand that the connection to your private server is the HTTPS by using self sign certificate. You may consider to inject the server certificate to the Jenkins/Java cacerts. – Charlee Chitsuk Mar 07 '13 at 03:57
  • @CharleeChitsuk: The connection from the slave machine to the private javadoc server is via scp. Here is the snippet from the pom.xml:` site-host scp://javadoc.foo.com/var/www/javadoc/${project.artifactId}/${project.version} ` – grayaii Mar 07 '13 at 15:32

2 Answers2

2

The most secure way is to preconfigure known hosts with the values you are expecting - appending the appropriate line for the server you're connecting to.

# Run this manually:
ssh -o UserKnownHostsFile=foo javadoc.foo.com

# Take that file and put it in your private DAV share, and then
ssh -o UserKnownHostsFile=/private/<account>/known_hosts javadoc.foo.com
Ben Walding
  • 4,006
  • 2
  • 30
  • 28
  • I can't run it manually. In cloudbees, the slave/build machines get created on-the-fly, and I don't think I can modify the "base" image of the build machine (I could be wrong on this...). – grayaii Mar 07 '13 at 15:37
  • doh, you are right. I read your response too quickly. That is essentially the right way to do it. I ended up saving it the /private/foo/ directory (which all slaves can access), and then when it's time, I use it, just like you mentioned. Thanks! – grayaii Mar 07 '13 at 21:28
0

Ben W's answer is quite good. Alternatively, I would make sure I can login via the console from that machine to wherever so that the ssh client would store the settings by itself.

carlspring
  • 31,231
  • 29
  • 115
  • 197
  • I cannot login via the console. The machine gets created when the job starts and gets destroyed when the job finishes. So even if I did manage to modify the known_hosts file on the build machine, it will just get blown away after the jenkins job is done. State is not preserved. Right now, I suspect I have to save a "golden" known_hosts file somewhere, and when the build starts use that "golden" file instead of the one in ~/.ssh/. – grayaii Mar 07 '13 at 16:45
  • 1
    Yep - the home directory is erased on each build - and the "golden file is quite handy as it ensures the trust relationship - better than just saying "YES" to the remote host check. Sort of like SSL without all the pain of CAs. – Ben Walding Mar 08 '13 at 00:26