How to add SSH support to an existing step-ca?

[B3DTech]

So in the documentation - I have come across nothing about running 'step ca init -ssh' to enable ssh certs on hosts.

I get all the way through configuring step-ca as an intermediate signed off our internal root, everything seems OK. Go to add a host with 'step ssh certificate --host hostname.domain.com ssh_host_ecdsa_key' and it fails saying the method is not implement by the CA.

CA logs show error="authority.Authorize; ssh certificate flows are not enabled"

Seems like I needed to do 'step ca init -ssh' to enable SSH certs? If that's the case, is there a way to enable this after having the CA set up, or do I need to blow it all away and start from scratch?

If I run 'step ca init -ssh', are the ssh certs generated off the self-created root and intermediate CA certs? Because after doing the init, I replace the root and intermediate with those created from our existing root. Will this invalidate the SSH certs created during the init?

[maraino]

is there a way to enable this after having the CA set up, or do I need to blow it all away and start from scratch?

Hi, @B3DTech yes, there's a way, but you need to manually edit the ca.json. To add a block like this one

"ssh": {
    "hostKey": "/home/name/.step/secrets/ssh_host_ca_key",
    "userKey": "/home/name/.step/secrets/ssh_user_ca_key",
}

Those are the private keys used to sign host and user certificates. You can generate them with:

step crypto keypair ssh_host_ca.pub ssh_host_ca_key
step crypto keypair ssh_user_ca.pub ssh_user_ca_key

⚠️ Make sure to use the same password that you used before, that way, if not step-ca will fail if you're using it with --password-file (or with the "password" property in ca.json).

You can also start from scratch and replace ~/.step, or you can even start from scratch but keeping the same root with step ca init --ssh --ca root_ca.crt --key root_ca_key or just copy the new files over.

By default when you run step ca init ... it will generate the files under your STEPPATH, if the environment variable STEPPATH is not defined it will use '$HOME/.step`. So if you want to generate a new PKI without overwriting the previous one you can run:

STEPPATH=/tmp/mytempca step ca init --ssh ...

If I run 'step ca init -ssh', are the ssh certs generated off the self-created root and intermediate CA certs?

No, new keys are created for SSH certificates. So you can always replace them (but use the same password).

Will this invalidate the SSH certs created during the init?

No.

[mmalone]

In theory, you should be able to use an ssh-agent that's backed by a Yubikey. Something like https://github.com/FiloSottile/yubikey-agent.

Context:

• An ssh-agent is a little program that exposes a standard API to your SSH clients that lets your SSH client create keys and sign stuff without actually having direct access to key material. Your SSH client typically talks to your agent over a Unix domain socket. The path to the domain socket is read from the SSH_AUTH_SOCK environment variable. OpenSSH comes with a default ssh-agent that holds key material in memory. The advantage is that key material never has to touch disk.
• You can replace the default ssh-agent with a different one that manages key material some other way (e.g., by using the secure enclave on a Mac, or by using a Yubikey). Switching should be super easy (just start the new agent and set the SSH_AUTH_SOCK to point to the right file / domain socket.

There is one caveat: I'm pretty sure the step CLI isn't generating keys using the ssh-agent API. Instead, it generates a key in memory then adds the key to ssh-agent. The yubikey-agent linked above says "the key is generated on the YubiKey and can't be extracted." So there may be an incompatibility there if yubikey-agent doesn't let step import a key. I haven't tried this setup, but I'd be super interested to know whether it works!

[tashian]

@msaratov You can use the YubiKey PIV application to hold keys for both X.509 and SSH CAs; however, the step-yubikey-init utility only supports X.509 at this time. For SSH support, you must manually generate and configure SSH CA keys on the YubiKey.

Here's our YubiKey PIV docs

[tashian]

@msaratov see also: #529 which has instructions for generating and configuring the SSH CA keys on the YubiKey

[0x6c66]

Thanks for your help! I followed the steps and feel like I am close to success, but step-ca now throws an error about slot 82 being unsupported when I start it. I've cross-posted in #529, because I felt it would be more relevant there.

[maraino]

@msaratov What version are you using?
That slot has been supported since v0.15.7, and I've just tested it on a development branch and the slot certificate is working.

[B3DTech]

Thank you - seems to be working. Having a few OIDC issues, but it successfully issued the SSH host cert.

[danb35]

I'm in a similar situation, but I think I'm going to need a little more guidance. I set up the CA following https://smallstep.com/blog/build-a-tiny-ca-with-raspberry-pi-yubikey/, and it's been working quite nicely. I'm now wanting to set up the CA to issue SSH certificates.

Thus far, I've created the keypairs (the step crypto keypair commands noted), put the private keys in /etc/step-ca/secrets (though I'm not quite clear what to do with the public keys right now), put password.txt in /etc/step-ca with the appropriate password, and edited the systemd unit file to use the password file. So far, so good. I'd also, following a recommendation I received in the chat, set up a SSHPOP provisioner by running step ca provisioner add sshpop --type SSHPOP. Again, no errors there.

The problem comes with adding the ssh: block to ca.json, and perhaps I'm just putting it in the wrong place. When I add it to the end of ca.json, just before the closing brace, so the last five lines read like this:

        "ssh": {
                "hostKey": "/etc/step-ca/secrets/ssh_host_ca_key",
                "userKey": "/etc/step-ca/secrets/ssh_user_ca_key"
        }
}

(NB: the response on 15 Oct has a comma following the userKey line as well, but I believe that's improper syntax--but I get the same error with or without that comma). The CA refuses to restart, and I see this error in the system logs:

Jun 28 17:11:08 tinyca sh[2842]: error parsing /etc/step-ca/config/ca.json: invalid character '"' after object key:value pair

I'd appreciate a little further guidance here.

[mmalone]

What version of step-ca are you running? Release notes at the end of this blog post indicate that "retired key management certificate slots (82-95) are now supported by YubKey PIV" as of version 0.15.8. Based on the error message my guess is that you're running an earlier version and an upgrade should fix things?

[danb35]

Ah, indeed. I'd been running 0.15.6. But the rabbit trail continues--the downloadable binary doesn't have yubikey support. So I went to rebuild it from source for the 0.15.15 release, as the "tiny CA" post instructed--and the build errored out:

ubuntu@tinyca:~/certificates-0.15.15$ sudo !!
sudo make bootstrap
# Using a released version of golangci-lint to take into account custom replacements in their go.mod
golangci/golangci-lint info checking GitHub for tag 'v1.39.0'
golangci/golangci-lint info found version: 1.39.0 for v1.39.0/linux/arm64
golangci/golangci-lint info installed /bin/golangci-lint
ubuntu@tinyca:~/certificates-0.15.15$ make build GOFLAGS=""
github.com/dgraph-io/badger/options
golang.org/x/sys/internal/unsafeheader
github.com/dgraph-io/badger/trie
(snip)
github.com/smallstep/certificates/acme/api
github.com/smallstep/certificates/ca
# github.com/smallstep/certificates/ca
ca/tls.go:58:10: undefined: tls.Dialer
ca/tls.go:66:5: not enough arguments to return
make: *** [Makefile:98: bin/step-ca] Error 2

[tashian]

@danb35 Wow, this is becoming quite a journey. Which Go version are you using here? If you're using 1.15, you may want to try 1.16.

Also, you're welcome to join us in Discord to continue this in real-time.

[danb35]

Which Go version are you using here?

ubuntu@tinyca:~$ go version
go version go1.14.7 linux/arm64

Looks like it could be a problem, and apparently I'd installed that from the package (apt install golang) rather than by direct download from golang.org. Removed that package, downloaded and installed Go 1.16.5, and now step-ca builds. Woohoo!

Copied the binary into /usr/local/bin, re-added the ssh block into ca.json, and started step-ca--and it starts without errors in the system log. Excellent.

The step ssh config --roots command isn't working as expected (if run on the CA, it says it requires the --ca-url flag; if run on a client machine, it gives ssh certificate not found: please run step ssh login <identity>), but if I run step ssh login dan on a client machine, it asks for a provisioner, and when I select my OIDC provisioner (going to a local LemonLDAP::NG installation), it does launch that web page for me to log in.

Now, LLNG tells me I'm not authorized to access that host--I'm suspecting that's a configuration issue on its end.

So, takeaways:

• Keep up to date--both with step-ca, and with go
• If one private key is on a Yubikey, all private keys need to be there
• JSON is picky about formatting

I'm not 100% where I need to be, but much closer. Thanks again.

[tashian]

One more thing @danb35, check that each provisioner you want to use for SSH has the following in its config:

"claims": {
	"enableSSHCA": true
}