SSH and IoT devices

[tsoos99dev]

Hi,

I'm experimenting with step-ca at home. I have a server and a few boards with a custom linux distro running on them.
The boards are gathering data from sensors and what not. I'd like to SSH into them remotely sometimes.
The boards can connect to a jump server via SSH if I send them a command via MQTT. I can set up host and user verification between the board and the jump server. Same for accessing the jump server from my remote computer. No problems there. The board itself can also verify my identity easily, but how could I then verifying the board's identity? What kind of host certificate can I issue for the board? There's no domain that belongs to the boards.

I was trying to give some extra context with the specific use case, but the question is really how to set up host verification for IoT devices that don't belong to a specific domain?

[hslatman]

Hey @tsoos99dev,

It sounds like in this case your Linux boards would be SSH clients, and the natural thing would be to issue an SSH user certificate to them. We have several provisioners that support doing that. Here's an overview of the provisioners per certificate type: https://smallstep.com/docs/step-ca/provisioners/#authorization-scope-by-provisioner.

Some options:

• The JWK provisioner can be used to obtain an initial certificate by provisioning the board with a JWT, and making it use step to obtain an SSH cert.
  • A variation on this is to first obtain an X509 certificate, and then to use the X5C provisioner with that X509 certificate to obtain an SSH user certificate. The benefit of this approach is that you'll be able to obtain new SSH user certificates using the existing X509 certificate.
• You could also mint an "X509 birth certificate" in some other fashion on the board, and use that with the X5C provisioner directly.
• If your boards have a TPM, you could look into using the ACME provisioner with device-attest-01 to obtain an initial X509 certificate, and then use the X5C provisioner to obtain an SSH user certificate.
• The OIDC provisioner supports issuing SSH certificates directly, but that requires authentication against an IdP. There might be a flow that could work for your devices, but it generally requires some user interaction, so it usually isn't the best fit for automated processes.
• A more niche option would be to use the Nebula provisioner, which requires your boards to be part of a Nebula network, and using its Nebula identity to obtain an SSH certificate.

One other nice property of having the X509 certificate is that you could use that as an identity certificate for other use cases too. You mention that the boards have access to an MQTT broker. I presume that is also authenticated in some manner. With the identity certificate in place you could use mTLS to authenticate to the MQTT broker 🙂

[tsoos99dev]

Hey @hslatman,

Thanks the X509 certificate for MQTT and even obtaining the SSH certificate is a really nice approach. I'll definitely explore that. Both the JWT and initial X509 approach could work well. No TPM module on the board and OIDC is problematic in this case, but no need for these.

In the situation I tried to describe the board is actually the host. It's a client to the jump server, no problems there, but then it creates a reverse SSH tunnel. I'm using that tunnel to log into the board remotely. This makes the board the host to my computer. If the host cert on the board isn't configured correctly I'm still going to get warnings about authenticity. I figured I could add localhost to the principals when I create the ssh host cert for the boards, but is that really an acceptable approach?

What about connecting to the board from my local network? Let's say I gave the board a static IP to make things easier. Is it okay to just add that IP as a principal when I issue the cert? Basically the board's cert would have the following principals in the end:

• localhost (for the reverse tunnel)
• 192.168. 1.10 (or something similar for local access)

Is this a sensible / safe approach? I think it'd solve all my problems.

Here's a diagram for my theoretical setup. The reverse tunnel is triggered with a command sent ot the web server that reaches the board via the MQTT broker. The jump server could be cloud hosted or internal.

[hslatman]

I think that should work with localhost and 192.168.1.10 set, yes, but I don't remember doing a similar setup. In terms of security I don't see an immediate issue, as long as the SSH host can only be authenticated to using certificates, and the client checks the SSH host cert to be from the expected SSH CA.

Given that the board is actually an SSH host (and a client, it seems?), you could also have a look at the SSHPOP provisioner, which allows renewing (just) SSH host certificates by authenticating to it with a proof of the private key.

[tsoos99dev]

Thank you. I'll also check the provisioner you mentioned!