Hello everyone!
I’m currently working on configuring SSH connections to the targets. To connect to the destination server, I need to use a certificate in addition to the private key. I’ve noticed an option for client certificates when creating a new credential, but it doesn’t allow me to select the user. When I upload my certificate, it shows an error message ‘Erroneous Certificate.’ Is it possible to use OpenSSH certificates for this?
Thanks in advance.
Andrés
From the manual, certificate-based authentication should be possible for SSH connections to conduct an authenticated scan, inaddition to the username + ssh key method.
See Greenbone docs: Definition of the passphrase of the private SSH key.
OpenSSH primarily uses two certificate formats:
My guess is that only X.509 is currently supported because I have not seen reference to OpenSSH certificate format in the source code.
Yes, please use the “Username + SSH Key” credential type as described here: 10 Scanning a System — Greenbone Enterprise Appliance 22.04.14 documentation
The uploaded private key must be supplied either in PKCS#8 format or base64 encoded. I’m still investigating whether we support both X.509 and OpenSSH formats. We will update our manual accordingly with the results.
The “Client Certificate” credential type looks to be a leftover from old functionality. We will investigate here too to see whether we can deprecate it.
Hi Martin, Thank you for your prompt response. Unfortunately, I am required to provide the necessary certificate in order to establish a connection. As an example, when attempting to connect via SSH from my computer, I must import both the key and certificate. Without these components, a successful connection is not possible.
If you happen to know whether it’s possible to merge the certificate into the public key file, I would greatly appreciate your guidance on that matter.
Kind regards.
Andrés
Please specify, OpenSSH does support host key (public) and for authenticate private key for the user.
If you connect you get the public part of the host-key and with your private key you can login to the host where you placed your public-key from the user to the list of valid keys on the host.
There is no such thing as a certificate … GVM does accepted host-keys in general, so you only need to place the private part of your user key into GVM.
I think that @atarrio is referring to an SSH key bundle although I cannot find a reference to the use of that specific term here is a descriptions of the practice 1, 2.
Similar to certificate-based authentication on other types of remote connection such as mysql a certificate is required for both the client and the server
Aside from that I do not have experience with this form of SSH authentication, and my limited experience with Greenbone’s source code tells me that (1) Greenbone will not allow this type of SSH key/certificate bundle file to be verified if it is uploaded, and (2) Greenbone does not support authentication with this method.
As far as i know there is no X.509 CA support in OpenSSH only public / private key, so what i try to understand is the exact use case here.
That is unclear and not correct specified.
Only if you understand what he want´s to do we can tell him what is supported and what not.
Public / private is is supported for many years.
Here is the RFC for what @atarrio is describing: RFC 6187: X.509v3 Certificates for Secure Shell Authentication.
The status is “PROPOSED STANDARD”. The history shows it was last edited in 2015.
At this section the public key authentication methods are listed and include a mention that:
Pretty Good Privacy (PGP) has its own method for binding a public key to a digital identity
Which is what it seems the OP is trying to accomplish by using X.509 certificates. By “binding a public key to a digital identity” you can validate the server’s public key upon a first connection (and subsequent ones). Typically, the first connection from a client to an SSH server represents the highest risk because the client is not aware of the server’s public key yet, which could be spoofed for a MiTM attack.
The SSH client connecting will receive the server’s public key and check if it already has this key stored (usually in ~/.ssh/known_hosts ). If it doesn’t have the key, it will display a warning message. Something like:
The authenticity of host 'hostname (IP address)' can't be established.
ECDSA key fingerprint is SHA256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.
Are you sure you want to continue connecting (yes/no)?
I guess that by using X.509 certificates, the client can connect to any SSH server and forgo the reliance on the server’s public key to verify its identify and instead rely on the certificate to identify the server.
But non of them is either a standard or implemented with OpenSSH 
So i really doubt that many tools did support this. Or any time soon there will be support from Greenbone for that exotic method. If you pin the host-certificate that is IMHO the most safest way to ensure both identities.
While I haven’t used this authentication service, I thought that the link I posted above to the Red Hat documentation indicated that it was fairly common authentication method for enterprise. I also assume support is widespread because it says it is a part of OpenSSH:
Using public key cryptography for authentication requires copying the public key from every client to every server that the client intends to log into. This system does not scale well and can be an administrative burden. Using a public key from a certificate authority (CA) to authenticate client certificates removes the need to copy keys between multiple systems. While the X.509 Public Key Infrastructure Certificate system provides a solution to this issue, there is a submission and validation process, with associated fees, to go through in order to get a certificate signed. As an alternative, OpenSSH supports the creation of simple certificates and associated CA infrastructure.
There is a inonofficial patch to do that, but officially OpenSSH does not support this and this fork is not security audited or part of any distribution.
Even RHEL 8.0 does not support this patch, unfortunatly i don´t have a RHEL 9.0.
While you are correct that OpenSSH does not natively support X.509, the Red Hat docs are rather specifying the use of OpenSSH’s own certificate format of cert-enhanced authentication.
X.509 was not the requirement specified by the OP, so I misspoke by referencing the RFC 6187 anyway:
No mention of X.509. So, plausibly he is talking about certificate-enhanced authentication that is supported by natively by OpenSSH. Either way, Greenbone does not support it.