Skip to main content

ssh fingerprint authenticity prompt

The authenticity of host can't be established

I faced a weird problem today:

  • A Jenkins post-build job is configured to deploy via scp to a target server
  • Jenkins runs as "integration" user
  • As "integration"  user, I already made sure the server is in "known_hosts", by manually SSH connected to it (when SSH-ing to it, I'm not prompted about the target server's identity anymore)
  • The Jenkins job is still prompted about the target server's identity
What was really weird:
  • From the Jenkins job, the target server's fingerprint is RSA based and is d9:fa:90:e6:2b:d2:f7:92:8b:28:3f:94:1e:bf:1b:fa.
  • From an SSH session, the target server's fingerprint is ECDSA based and is 0d:2a:c3:3b:8f:f1:e9:bc:1f:5d:68:d3:84:6d:71:a8.

This is because

  • The Jenkins SSH plugin I use is not up to date and still use weak and old fashioned algorithms: the negiciation stops at a weak one, DSA.
  • The SSH client (in SSH session) negociation ends up a stronger algorithm, ECDSA.

This is proven by these commands.

To force RSA algorithm:
ssh -o HostKeyAlgorithms=ssh-rsa-cert-v01@openssh.com,\
                         ssh-dss-cert-v01@openssh.com,\
                         ssh-rsa-cert-v00@openssh.com,\
                         ssh-dss-cert-v00@openssh.com,\
                         ssh-rsa,ssh-dss  integration@target-host.rktmb.org

The prompt is:

The authenticity of host 'target-host.rktmb.org (192.168.15.12)' can't be established.
RSA key fingerprint is d9:fa:90:e6:2b:d2:f7:92:8b:28:3f:94:1e:bf:1b:fa.

To let the negociation go on and end up with ECDSA:

ssh integration@target-host.rktmb.org

The prompt is:

The authenticity of host 'target-host.rktmb.org (192.168.15.12)' can't be established.
ECDSA key fingerprint is 0d:2a:c3:3b:8f:f1:e9:bc:1f:5d:68:d3:84:6d:71:a8.



So, in order to add the target host to the "known_hosts", I had to use the command forcing RSA to be used:

ssh -o HostKeyAlgorithms=ssh-rsa-cert-v01@openssh.com,\
                         ssh-dss-cert-v01@openssh.com,\
                         ssh-rsa-cert-v00@openssh.com,\
                         ssh-dss-cert-v00@openssh.com,\
                         ssh-rsa,ssh-dss  integration@target-host.rktmb.org

And then issue the "yes" confirmation.

This way the Jenkins job can smoothly SSH-connect to the target host in order to deploy.

Thanks to http://askubuntu.com/a/217066 and https://blog.cloudflare.com/ecdsa-the-digital-signature-algorithm-of-a-better-internet/

Comments

Popular posts from this blog

vmware libz libfontconfig libexpat

Archlinux - Kernel 4.11 - VMWare workstation 12.5.7 With this combination, when I launch "vmware", despite the fact I already "export VMWARE_USE_SHIPPED_LIBS=force", I get those lines:

Unable to load libfontconfig.so.1. /usr/lib/vmware/lib/libz.so.1/libz.so.1: version `ZLIB_1.2.9' not found (required by /usr/lib/libpng16.so.16) Unable to load libfontconfig.so.1 from /usr/lib/vmware/lib/libfontconfig.so.1/libfontconfig.so.1: libexpat.so.0: cannot open shared object file: No such file or directory Unable to load dependencies for /usr/lib/vmware/lib/libvmware-modconfig.so/libvmware-modconfig.so
In order to workaround, I decided to get the things to the maximum: Add all shipped libraries in the LD_LIBRARY_PATH.

So I created my custom launcher of "vmware" and this is the content:

#!/bin/bash
export VMWARE_USE_SHIPPED_LIBS=force
LD_LIBRARY_PATH=""
LD_LIBRARY_PATH=$( find /usr/lib/vmware/lib/ -maxdepth 1 -mindepth 1 -type d | awk 'BEGIN{p=&quo…

vmware net_device trans_start

VMWare Workstation 12 and Kernel 4.7 When recompiling vmware kernel modules on a kernel 4.7, I get this error:

/tmp/modconfig-xrrZGZ/vmnet-only/netif.c:468:7: error: ‘struct net_device’ has no member named ‘trans_start’; did you mean ‘mem_start’?     dev->trans_start = jiffies;
This seems to be an already encountered problem: http://rglinuxtech.com/?p=1746http://ferenc.homelinux.com/?p=356 I choosed to replace the line, instead of deleting it.

- dev->trans_start = jiffies; + netif_trans_update(dev); I also noted that I had to re-tar the modified sources instead of leaving them untared, because the compilation process only takes the archives. 
On precedent editions of these files, I just left the modified folders "vmnet-only/" and "vmmon-only/" expanded without the need to re-tar them.


Jira workflow for new projects

Associated workflow creation I'm a Jira Cloud user and begining from some version 6, I noticed that when I create a project, it automatically creates a Workflow and Issue Scheme that is prepended by the project key and which is a copy of the default scheme.
I always had to make a cleanup after creating a project. Default workflow for new projects I also miss a feature that would allow me to make a custom workflow (and globally custom project setting) the default for new projects I create.
Solution: Create with shared configuration While searching, I noticed that with Jira Cloud which is version 7.1.0 at the time I write, there is a link at the bottom of the "Create project" wizard:
"Create with shared configuration" will allow me to select the project I want the new one to share configuration with.

The new created project will use the same configuration as the project I selectThere will be no creation of Workflow and Issue Scheme that I need to cleanup

This fea…