6

I'm following along a rather good text about SSH certificates written for RHEL 6 and openssh-5.3p1-94.el6 (which makes it about 10 years old) while trying to mimic the examples on my OpenBSD-current system.

One of the examples shows creating a host CA key and then signing the host's RSA key:

ssh-keygen -s ~/.ssh/ca_host_key -I host_name -h -Z host_name.example.com -V -1w:+54w5d /etc/ssh/ssh_host_rsa.pub
Enter passphrase:
Signed host key /root/.ssh/ssh_host_rsa-cert.pub: id "host_name" serial 0 for host_name.example.com valid from 2015-05-15T13:52:29 to 2016-06-08T13:52:29

When I tried this on OpenBSD, I don't get the for host_name.example.com output. The text says that

The -Z option restricts this certificate to a specific host within the domain.

... and I'm a bit confused about this as the OpenBSD manual for ssh-keygen(1) never mentions a -Z option at all. I'm also confused about ssh-keygen accepting this undocumented option without complaining.

Looking at the source code for ssh-keygen, the -Z option is accepted but seems to have something to do with a "format cipher" (or possibly "cipher format") rather than with a hostname (provided that I'm looking at the correct code):

case 'Z':
    openssh_format_cipher = optarg;
    break;

Looking at older versions of the code, it has always had something to do with "format cipher".

The release notes for OpenSSH do not mention -Z.

Question: Is ssh-keygen on RHEL 6 (I'm not sure the release is relevant, but the equivalent documentation about SSH certificates for RHEL 7 or RHEL 8 seems not to be available) patched with RedHat-only patches that makes -Z act differently?

0
8

tl;dr; with newer versions of OpenSSH, you should use the -n option instead of -Z to set the principals (eg. hostname or user).

Looking at the source code for ssh-keygen, the -Z option is accepted but seems to have something to do with a "format cipher"

Yes, and the reason why you don't get an error is because that openssh_format_cipher variable is not used when creating a certificate, but only when generating a key with a passphrase.

If you generate a key with ssh-keygen -f ./path -Z some_garbage and set a passphrase you will get an error.

Is ssh-keygen on RHEL 6 ... patched with RedHat-only patches that makes -Z act differently?

Yes, it used to be. You can see in the openssh-5.3p1-ssh-certificates.patch from here:

+               case 'Z':
+                       cert_principals = optarg;
+                       break;
                case 'p':

That patch is no longer used in newer rpms.

1
  • 1
    It seems as if the -Z option for ssh-keygen on RHEL 6 is pretty much the same as the -n option for the same utility in the current upstream OpenSSH. Thanks for your answer. – Kusalananda Dec 23 '19 at 21:42
1

Expanding the @mosvy answer as it is a bit longer than for just a comment.

RHEL6 was released with OpenSSH 5.3p1 from 2009 (I think initially it was older version, but I don't have it at hand now) and over the years new features were implemented or backported from upstream including this one for SSH certificates.

But this was quite later. For some years, there was initial support for smart cards through NSS (in changelog dated back to 2007), which took over the -n switch in ssh-keygen. How did it work is described for example in this blog post from 2008 (I can not find if this patch was proposed upstream or why it was rejected, but these days smart cards are used directly through standard PKCS#11 interface). For more information, see openssh-5.3-p1-nss-keys.patch from source rpm linked in the previous answer.

Only some time later after OpenSSH 5.4p1 release with the certificate support, it was decided to backport this particular feature (in changelog dated back to 2013) and there was a clash with existing switch (the ssh-keygen is now using all of the letters in alphabet if I remember well) and only way how to backport this feature was to move the option to different switch (existing scenarios could not be broken with minor update) and document it.

And that is the whole story.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.