More than 256 principals

[blcetux]

Hi,

We are having an issue on which, if we have more than 256 principals, we get the following error from ssh-agent:

could not store certificate to an agent: could not add to agent: agent: failure

Regards, Bruno Costa

[blcetux]

Hi,

Based on this: https://github.com/openssh/openssh-portable/blob/master/sshkey.h#L108

This appears to be an hard-limit of ssh-keygen: #define SSHKEY_CERT_MAX_PRINCIPALS 256

Is it possible for ssh-inscribe to split the principals every 256 principals and generate multiple certificates?

Regards, Bruno Costa

[aakso]

Hello,

Thanks for the feedback. Interesting, the specification doesn't seem to mention a limitation like that.

Out of curiosity, does this happen only with ssh-agent or are you able to use a cert with OpenSSH when loading it from a file? (use sshi req --agent=false -g -i /path/to/file -w to write the generated key and cert to files)

The splitting feature could be introduced in backwards compatible manner as we return the generated certificate in authorized_keys file format where a line represents a single key or a certificate. However, I'm not sure if ssh-inscribed should do this by default or if a user should be given a chance to specify the maximum amount of principals per certificate.

In the meantime, I'd suggest to limit the amount of principals by using --include or --exclude flags with a glob pattern to filter out unnecessary principals. You can also use envvars SSH_INSCRIBE_INCLUDE_PRINCIPALS and SSH_INSCRIBE_EXCLUDE_PRINCIPALS to set these.

Thanks, Anton

[blcetux]

Hi,

We've tried to generate the cert manually, write the generated key and cert. We had an error when we've tried to add it to the agent:

Too many certificate principals specified

Actually, we have a very simple way to reproduce it:

1. Create a dummy CA/Key

   $ cd /tmp/
   $ ssh-keygen -t ecdsa -C "The CA" -N "" -f ca
   $ ssh-keygen -t ecdsa -C "My Key" -N "" -f my-key

Then, try to sign it with 255 principals. This will work:

$ ssh-keygen -s ./ca -I testing-my-ca -n $(for number in `seq  1 255`; do echo  -ne "g${number},"; done | sed 's/,$//g') -V +1w -z 1 ./my-key.pub
Signed user key ./my-key-cert.pub: id "testing-my-ca" serial 1 for g1,g2,g3,g4(...)

When you change to 257 principals, it won't work:

$ ssh-keygen -s ./ca -I testing-my-ca -n $(for number in `seq  1 257`; do echo  -ne "g${number},"; done | sed 's/,$//g') -V +1w -z 1 ./my-key.pub
Too many certificate principals specified

In the meantime, we are using SSH_INSCRIBE_INCLUDE_PRINCIPALS to limit the scope by a few dozens, but we are only postponing this until we have more principals in our environments

Regards, Bruno Costa

[aakso]

Ok, so the limit is probably baked into some generic code all the OpenSSH binaries use.

Have you tested if your proposal of multiple certs in the agent with different principals works when you try to connect to a host that requires a specific principal? As in, is the cert without the required principal but with a signature from the correct CA correctly skipped during handshake?

[blcetux]

Hi,

I've tested using sshi twice, with: --exclude sshca- --keytype ed25519 --include sshca- --keytype rsa

I've performed that way, because otherwise the certificate/keys were being replaced.

$ ssh-add -l
2048 SHA256:o0/puu***** ssh-inscribe managed (RSA-CERT)
2048 SHA256:o0/puu***** ssh-inscribe managed (RSA)
256 SHA256:cJYkY8***** ssh-inscribe managed (ED25519-CERT)
256 SHA256:cJYkY8***** ssh-inscribe managed (ED25519)

I was able to still perform SSH connections. The only issue that I could think that can cause issues, is that if we exceed "MaxAuthTries" on destination servers - but that is configurable :-)

Regards, Bruno Costa

[aakso]

I've performed that way, because otherwise the certificate/keys were being replaced.

Yeah that is by design. Maybe we should support giving each certificate an identifier that would be appended to the cert comment and then only the relevant cert would be replaced.

I was able to still perform SSH connections. The only issue that I could think that can cause issues, is that if we exceed "MaxAuthTries" on destination servers - but that is configurable :-)

This has been a problem for other users too. This is why the current version on ssh-inscribe has an --agent-filter flag (enabled by default) which can be used together with exec and ssh subcommands. It will start a forwarding agent and filter out certs (and other keys) that are not signed by the selected CA.

In any case the splitting functionality seems like a usable feature for some users. Still, you are the first one that has so many principals. Are you getting them from a Directory Server or thru OIDC?

[blcetux]

Hi,

We are getting that from an LDAP Directory Server.

Regards, Bruno Costa

[aakso]

Here is a possible implementation: #17

You can clone the repo and checkout the branch. You can then build the client and server with make linux or make darwin depending on whether you running linux or macos.

If you don't have a go compiler but you have Docker you can also run make dist to build everything inside a container. Files will be written to dist directory.

To request multiple certs:

sshi req -g --max-principals-per-certificate 256

[aakso]

Please test and we'll merge this and make a release.

[blcetux]

Hi,

I've performed some tests with SSH_INSCRIBE_MAX_PRINCIPALS_PER_CERTIFICATE=100, without issues. I was able to login into servers from different CERTs, without issue.

LGTM

Best regards

[blcetux]

Hi @aakso,

Is it possible to make a new release that includes this?

Best regards

[aakso]

Yes, will make a release shortly.

[aakso]

Release is now available at https://github.com/aakso/ssh-inscribe/releases/tag/0.10.0