[ssh_x509] x509v3-ssh-rsa hostkey algorithm on Cisco IOS XE

ssh_x509 at roumenpetrov.info ssh_x509 at roumenpetrov.info
Fri Feb 21 19:34:48 EET 2020


Hi Roumen,

>> Thanks for that reference, I've gone through it already and it does
specify
>> how to use @cert-authority for ssh-rsa hostkey algorithm, but not for
>> x509v3-ssh-rsa.
>I'm not sure what you mean by CA.

CA is for regular Certificate Authority. For sake of an example, here's
reference of the SSH CA implementation -
https://smallstep.com/blog/use-ssh-certificates/, I do run SSH CA for
GNU/Linux systems and have a single line in known_hosts on the SSH client
to trust all the systems in a certain domain (this is ssh-rsa-cert-v01
hostkey algorithm):
    @cert-authority *.lab.local ssh-rsa <public key of the SSH CA in
ssh-rsa format>

My idea was to to the same, but for Cisco IOS, so I've spun up a simple CA
using OpenSSL, on that CA I've issued a cert that I put on my SSH server
(Cisco IOS XE) that uses x509v3-ssh-rsa hostkey algorithm. The SSH server
is configured as per
https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/sec_usr_ssh/configuration/xe-3s/sec-usr-ssh-xe-3s-book/sec-secure-shell-auth-digi-certificate.html
- it has a certificate and private key for it, certificate of the CA that
issued that cert (from my OpenSSL lab setup) and is configured to do SSH
with x509v3-ssh-rsa hostkey algorithm.
The only thing I'm missing here is an SSH client, capable of trusting Cisco
IOS XE SSH server's X509 certificates in a manner similar to one I
described above for ssh-rsa-cert-v01 hostkey algorithm - "@cert-authority
..." entry in known_hosts or any other form of syntax that will work and
provide the same functionality in PKIX-SSH :)

> Let me quote lines from my "known host" that match host-keys generated
> in regression tests:
> xxxx x509v3-ecdsa-sha2-nistp256 Subject:C=XX,ST=World,O=SSH Test Team
> ...
> xxxx x509v3-ecdsa-sha2-nistp384 Subject:C=XX,ST=World,O=SSH Test Team
> ...
> xxxx x509v3-ecdsa-sha2-nistp521 Subject:C=XX,ST=World,O=SSH Test Team
> ...
> xxxx x509v3-sign-rsa Subject:C=XX,ST=World,O=SSH Test Team
> ...
> local10022 x509v3-sign-dss Subject:C=XX,ST=World,O=SSH Test Team
> ...

As I wrote earlier, these are 1:1 mappings between an SSH server and its
identity (DN, key, etc) in known_hosts and I want to have a single entry
for CA to have hierarchical trust.
To be honest, this hierarchical trust, is the very single reason to switch
from ssh-rsa to x509v3-ssh-rsa hostkey algo.
And to be clear - these 1:1 mappings in known_hosts do work in my lab
environment, they are just not any more scalable compared to ssh-rsa 1:1
mappings.


>>> This is due to inherited functionality from ssh.com, then openssh and
>>> then pkis-ssh: pub-format or DN (new). DER or PEM encoded X.509
>>> certificate is not supported directly yet.
>> Yeah, noted that. Do you have any plans to integrate such functionality
>> into PKIX-SSH?
>Low priority.  Note the word directly!

Ok, good to know :) To be clear here, I have no objection to use pubkey to
identify CA - for ssh-rsa-cert-v01 hostkey algorithm does exactly this and
it's just fine. The only thing I'm concerned with is to make it to work.

> Actually know host and authorized keys support  3 formats:
> 1) X.509 certificate blob
> ... x509v3-sign-dss MIIIMDCCB5mgAwIBAgIJIAQCFgkGAAARMA0.......

Can you provide more info on that? Earlier you wrote "DER or PEM encoded
X.509 certificate is not supported directly yet."

> The X.509 certificate store is setup by options CACertificateFile,
> CACertificatePath and on client side
> in addition UserCACertificateFile and UserCACertificatePath.

I presume PKIX-SSH should pick an entry from known_hosts that identifies
the CA first (like one starting with "@cert-authority" in the very first
example in this mail for ssh-rsa-cert-v01 hostkey algorithm) and only then
should consult local CA store if necessary. Or process of known_hosts and
CA store evaluation is totally different for x509v3-ssh-rsa and
ssh-rsa-cert-v01 hostkey algorithm (but I suppose it shouldn't be
different).

>> x509v3-ssh-rsa that is the only one implemented in Cisco IOS it doesn't
>> work as a scale, as current trust on a per-host (per SSH server) isn't
any
>> more scalable compared to per-host trust with ssh-rsa.
>Not clear. I cannot  see difference.

That's a maaaaassive difference :) Just consider you run an infrastructure
with a 1000 of devices (servers, routers, etc), your team is 20 people in
different timezones and you typically introduce and decommission about 50
devices per month. Now to the differences:
   - With per-host trust you need to have a centralized repo of
"known_hosts" files that everyone pushes updates to and pulls data from
every day when they add/delete devices as otherwise SSH trust is
compromised and people will need to blindly trust SSH keys and will have a
myriad of stale entries in known_hosts;
   - With hierarchical trust all you need is a single entry in
"known_hosts" (re: ssh-rsa-cert-v01 hostkey algorithm example in very top
of my today's mail).

---
Sergei Fomin


On Thu, Feb 20, 2020 at 9:16 PM <ssh_x509 at roumenpetrov.info> wrote:

> Hello,
>
> ssh_x509 at roumenpetrov.info wrote:
> > Hi Roumen,
> >
> > Thanks for quick feedback on that!
> > [SNIP]
> >
> > Thanks for that reference, I've gone through it already and it does
> specify
> > how to use @cert-authority for ssh-rsa hostkey algorithm, but not for
> > x509v3-ssh-rsa.
> I'm not sure what you mean by CA.
>
> >   I've tried couple options in known_hosts to make it to
> > work, but no luck:
> >
> >      @cert-authority *.lab.local x509v3-sign-rsa
> > Issuer:C=AU,ST=Some-State,O=Internet Widgits Pty Ltd
> >      @cert-authority *.lab.local x509v3-sign-rsa <Public Key of the CA
> that
> > signed cert for SSH server in ssh-rsa format>
> Let me quote lines from my "known host" that match host-keys generated
> in regression tests:
> xxxx x509v3-ecdsa-sha2-nistp256 Subject:C=XX,ST=World,O=SSH Test Team
> cyrillic-АБВ-Яабв-я greek-ΑΒΓ-Ωαβγ-ω,OU=SSH Testers cyrillic-АБВ-Яабв-я
> greek-ΑΒΓ-Ωαβγ-ω-2,OU=SSH Testers cyrillic-АБВ-Яабв-я
> greek-ΑΒΓ-Ωαβγ-ω-1,OU=SSH Testers cyrillic-АБВ-Яабв-я
> greek-ΑΒΓ-Ωαβγ-ω-3,CN=localhost ECDSA(nistp256)(rsa_sha1)
> xxxx x509v3-ecdsa-sha2-nistp384 Subject:C=XX,ST=World,O=SSH Test Team
> cyrillic-АБВ-Яабв-я greek-ΑΒΓ-Ωαβγ-ω,OU=SSH Testers cyrillic-АБВ-Яабв-я
> greek-ΑΒΓ-Ωαβγ-ω-2,OU=SSH Testers cyrillic-АБВ-Яабв-я
> greek-ΑΒΓ-Ωαβγ-ω-1,OU=SSH Testers cyrillic-АБВ-Яабв-я
> greek-ΑΒΓ-Ωαβγ-ω-3,CN=localhost ECDSA(nistp384)(rsa_sha1)
> xxxx x509v3-ecdsa-sha2-nistp521 Subject:C=XX,ST=World,O=SSH Test Team
> cyrillic-АБВ-Яабв-я greek-ΑΒΓ-Ωαβγ-ω,OU=SSH Testers cyrillic-АБВ-Яабв-я
> greek-ΑΒΓ-Ωαβγ-ω-2,OU=SSH Testers cyrillic-АБВ-Яабв-я
> greek-ΑΒΓ-Ωαβγ-ω-1,OU=SSH Testers cyrillic-АБВ-Яабв-я
> greek-ΑΒΓ-Ωαβγ-ω-3,CN=localhost ECDSA(nistp521)(rsa_sha1)
> xxxx x509v3-sign-rsa Subject:C=XX,ST=World,O=SSH Test Team
> cyrillic-АБВ-Яабв-я greek-ΑΒΓ-Ωαβγ-ω,OU=SSH Testers cyrillic-АБВ-Яабв-я
> greek-ΑΒΓ-Ωαβγ-ω-2,OU=SSH Testers cyrillic-АБВ-Яабв-я
> greek-ΑΒΓ-Ωαβγ-ω-1,OU=SSH Testers cyrillic-АБВ-Яабв-я
> greek-ΑΒΓ-Ωαβγ-ω-3,CN=localhost RSA(rsa_sha1)
> local10022 x509v3-sign-dss Subject:C=XX,ST=World,O=SSH Test Team
> cyrillic-АБВ-Яабв-я greek-ΑΒΓ-Ωαβγ-ω,OU=SSH Testers cyrillic-АБВ-Яабв-я
> greek-ΑΒΓ-Ωαβγ-ω-2,OU=SSH Testers cyrillic-АБВ-Яабв-я
> greek-ΑΒΓ-Ωαβγ-ω-1,OU=SSH Testers cyrillic-АБВ-Яабв-я
> greek-ΑΒΓ-Ωαβγ-ω-3,CN=localhost DSA(rsa_sha1)
>
> and part from ~/.ssh/config
> Host xxxx
>      #StrictHostKeyChecking no
>      HostName ....
>      Port ....
>      HostKeyAlias xxxx
>      CheckHostIp no
>      ControlPath none
>
>
> >> This is due to inherited functionality from ssh.com, then openssh and
> >> then pkis-ssh: pub-format or DN (new). DER or PEM encoded X.509
> >> certificate is not supported directly yet.
> > Yeah, noted that. Do you have any plans to integrate such functionality
> > into PKIX-SSH?
> Low priority.  Note the word directly!
>
> There are utilities that could help user to convert a X.509 certificate
> into used formats.
> Also I forgot to mention "plain" public key format.
>
> Actually know host and authorized keys support  3 formats:
> 1) X.509 certificate blob
> ... x509v3-sign-dss MIIIMDCCB5mgAwIBAgIJIAQCFgkGAAARMA0.......
>
> 2) X.509 distinguished name
> ... x509v3-sign-dss Subject:C=XX,ST=World,O=SSH Test Team
> cyrillic-АБВ-Яабв-я greek-ΑΒΓ-Ωαβγ-ω,OU=SSH Testers cyrillic-АБВ-Яабв-я
> greek-ΑΒΓ-Ωαβγ-ω-2,OU=SSH Testers cyrillic-АБВ-Яабв-я
> greek-ΑΒΓ-Ωαβγ-ω-1,OU=SSH Testers cyrillic-АБВ-Яабв-я
> greek-ΑΒΓ-Ωαβγ-ω-3,CN=localhost DSA(rsa_sha1)
>
> 3) public key blob
> ssh-dss AAAAB3NzaC1kc3MAAACBAKI3WoVJ9jlZJt.....
>
>
> Hint for 3)
> after make check go to tests/CA/ and run following commands:
> $ F=`mktemp`
> $ openssl x509 -in testid_eccnistp384-dsa.crt -pubkey -noout > $F
> $ ssh-keygen -i -f $F -m PKCS8
> $ cat testid_eccnistp384.pub
> Note output from command 3 and 4.
>
> Hint for 1)
> $ (printf 'x509v3-ecdsa-sha2-nistp384 ' ; openssl x509 -in
> testid_eccnistp384-rsa_sha1.crt -outform DER | base64 -w 10000 )
> $ cat testid_eccnistp384-rsa_sha1.pub
> Is there a difference?
> Let check them:
> $ (printf 'x509v3-ecdsa-sha2-nistp384 ' ; openssl x509 -in
> testid_eccnistp384-rsa_sha1.crt -outform DER | base64 -w 10000 ) | diff
> -u - testid_eccnistp384-rsa_sha1.pub
>
> Hint for 2)
> No! ;)
> Please see commands in README.x509v3.
>
>
> Remark: There is no difference between x509v3-sign-rsa and
> x509v3-ssh-rsa and x509v3-rsa2048-sha256 in context of known host or
> authorized keys.
> Similar for x509v3-sign-dss or x509v3-ssh-dss. And this is mentioned in
> README.x509v3
>
>
>
> > For GNU/Linux implementation, there's SSH CA that does well
> > for ssh-rsa (and some others like ecdsa-sha2-nistp256), but for
> Dunno what you talking about.
> X.509 certificates are not only for single CA
> You could manage multiple CA.
> The X.509 certificate store is setup by options CACertificateFile,
> CACertificatePath and on client side
> in addition UserCACertificateFile and UserCACertificatePath.
>
> Those options are so common, i.e. similar in all programs  that use
> X.509 store based on OpenSSL
> (
> https://urldefense.proofpoint.com/v2/url?u=https-3A__roumenpetrov.info_domino-5FCA_&d=DwIGaQ&c=qE8EibqjfXM-zBfebVhd4gtjNZbrDcrKYXvb1gt38s4&r=9XrQNPIWJtsaesEtcBOvbGkSS-irozw8rW8oLr9bvaY&m=ZWWiMorRGVO5jIdR3ajVvB-uMjsx2Gj2MvRmHV671v4&s=HSmJw5t3ji0yz_L54qJEz8rNP0RKUsT2gIpeOiMxias&e=
> ) -  OpenSSL, Apache , PKIX-SSH,
> curl and etc.
> For more details see manual page verify(1) .
>
> Also PKIX-SSH manuals describe other options revocation lists , OCSP ,
> use of ldap to store certificates and crls .
>
>
> > x509v3-ssh-rsa that is the only one implemented in Cisco IOS it doesn't
> > work as a scale, as current trust on a per-host (per SSH server) isn't
> any
> > more scalable compared to per-host trust with ssh-rsa.
> Not clear. I cannot  see difference.
>
>
> Right now I'm not sure what is issue.
>
>
> You could use client option StrictHostKeyChecking set to ask for first
> connection.
> If after confirmation host key will be store in know host.
>
>
> Perhaps we could review some configuration steps again.
>
>
> > ---
> > Sergei Fomin
>
> [SNIP]
>
> Regards,
> Roumen Petrov
>
>
> _______________________________________________
> ssh_x509 mailing list
> ssh_x509 at roumenpetrov.info
>
> https://urldefense.proofpoint.com/v2/url?u=http-3A__roumenpetrov.info_mailman_listinfo_ssh-5Fx509-5Froumenpetrov.info&d=DwIGaQ&c=qE8EibqjfXM-zBfebVhd4gtjNZbrDcrKYXvb1gt38s4&r=9XrQNPIWJtsaesEtcBOvbGkSS-irozw8rW8oLr9bvaY&m=ZWWiMorRGVO5jIdR3ajVvB-uMjsx2Gj2MvRmHV671v4&s=4CYmfiq4wrjNTnRBuqjLs99X5sWVQO9WsH4xEuf7lts&e=
>


More information about the ssh_x509 mailing list