-
Notifications
You must be signed in to change notification settings - Fork 71
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SSH certificate authority support #210
Comments
You can use Ignition's (We usually support specific host features via FCCT sugar, rather than directly in Ignition. The two cases you mentioned are special: |
You note concerning FCCT sugars makes sense and didn't even occur to me when I wrote the ticket, thanks. Concerning the missing (so to speak) directives to conveniently support SSH CAs I suppose something like the following might make sense (using fcct wording): ignition:
config:
security:
ssh:
certificate_authority:
# This entry should create a matching "TrustedUserCAKeys /etc/ssh/<NAME>.pub" in /etc/ssh/sshd_config and also create the file at "/etc/ssh/<NAME>.pub"
authority:
name: # string
certificate: # one of compression, source, inline, local
host_keys: # Each entry here should ceate a matching "HostCertificate /etc/ssh/ssh_host_<TYPE>_key-cert.pub" entry in /etc/ssh/sshd_config I believe
- type: rsa # (ssh key types)
key:
contents: # one of compression, source, inline, local
certificate:
contents: # one of compression, source, inline, local
There's a couple of other attributes etc. (such as |
Yes, it'd be helpful if you can provide as complete an example as possible. Thank you! We'd normally put sugar for specific services into its own top-level struct, e.g. |
I'd personally put this into the Okay, I am 95% confident that the following should work as expected: ignition:
config:
security:
ssh:
certificate_authority:
user_authorities: # Create "TrustedUserCAKeys /etc/ssh/ssh_user_ca" in /etc/ssh/sshd_config and also create the file at "/etc/ssh/ssh_user_ca"
# create one entry per certificate listed below
- certificate:
contents: # like file.contents: one of compression, source, inline, local (the public certificate of the CA to be trusted)
host_keys: # Create "HostCertificate /etc/ssh/ssh_host_<TYPE>_key-cert.pub" entry in /etc/ssh/sshd_config for each provided host_key
# this also needs to create a "HostKey /etc/ssh/ssh_host_<TYPE>_key" enty /etc/ssh/sshd_config for each provided host_key overriding the defaults
- type: rsa # string (ssh key types such as rsa, ed25519, ecdsa)
key:
contents: # like file.contents: one of compression, source, inline, local
pub: # only relevant assuming ign/fcc shouldn't re-calculate the public keey during transformation
# e.g. using "ssh-keygen -y -f ~/.ssh/id_rsa > ~/.ssh/id_rsa.pub"
contents: # like file.contents: one of compression, source, inline, local
cert:
contents: # like file.contents: one of compression, source, inline, local
revoked_keys: # Create "RevokedKeys /etc/ssh/ssh_user_ca_revoked_keys" in /etc/ssh/sshd_config and also create the file "/etc/ssh/ssh_user_ca_revoked_keys"
# containing the list of public keys below in the format of "@revoked <public_key>"
- certficate:
contents: # like file.contents: one of compression, source, inline, local
passwd:
users:
- name: core
ssh_authorized_principales: # Generates a file at %h/.ssh/authorized_principals containing the list of principals below
# also has to add AuthorizedPrincipalsFile %h/.ssh/authorized_principals in /etc/ssh/sshd_config
- # string Instead of modifying the
A local test run using these to files using latest CoreOS worked perfectly fine for me. |
Awesome, thanks for the detailed proposal!
The |
That totally makes sense … may bad. I used my initial example to continue working on and just quickly glanced at the fcct spec and must have mistook the indention level for variant: fcos
version: x.y.z
ssh: # new stuff here
# and here
passwd:
users:
- name: core
ssh_authorized_principales: Would be the correct indention and keying of properties, right? |
Yup, that's right. |
So, after sleeping and looking at this again noticed a small design issue concerning the Because using authorized principles is no longer key based (as in a particular, personal key has to be used) but "role" based (the key has to be signed to be used in this capacity) I think it might be worthwhile to do the following instead:
Which would mean that any By the way technically the same issue can happen for |
I had some time to poke around the Go code and also had another look at the original draft for the yaml spec and simplified it somewhat. I may give it a try to implement but the whole I am still unsure about the principals file location and I am wondering whether moving the attribute from ssh:
authorized_principals:
- user: <name>
principals:
- # string This would encapsulate all new SSH settings in one block and also let ssh:
certificate_authorities: # Create "TrustedUserCAKeys /etc/ssh/ssh_user_ca" in /etc/ssh/sshd_config and also create the file at "/etc/ssh/ssh_user_cas"
# create one entry per SSH key listed below
- contents: # like file.contents: one of compression, source, inline, local (the public key of the CA to be trusted)
host_keys: # Create "HostCertificate /etc/ssh/ssh_host_<TYPE>_key-cert.pub" entry in /etc/ssh/sshd_config for each provided host_key
# this also needs to create a "HostKey /etc/ssh/ssh_host_<TYPE>_key" enty /etc/ssh/sshd_config for each provided host_key overriding the defaults
- type: <type> # string (ssh key types such as rsa, ed25519, ecdsa)
key:
contents: # like file.contents: one of compression, source, inline, local
pub: # only relevant assuming ign/fcc shouldn't re-calculate the public keey during transformation
# e.g. using "ssh-keygen -y -f ~/.ssh/id_rsa > ~/.ssh/id_rsa.pub"
contents: # like file.contents: one of compression, source, inline, local
cert:
contents: # like file.contents: one of compression, source, inline, local
revoked_keys: # Create "RevokedKeys /etc/ssh/ssh_user_revoked_keys" in /etc/ssh/sshd_config and also create the file "/etc/ssh/ssh_user_revoked_keys"
# containing the list of public keys below in the format of "@revoked <public_key>"
- contents: # like file.contents: one of compression, source, inline, local
passwd:
users:
- name: <name>
ssh_authorized_principals: # Generates a file at %h/.ssh/authorized_principals containing the list of principals below
# also has to add AuthorizedPrincipalsFile %h/.ssh/authorized_principals in /etc/ssh/sshd_config
- # string |
In before comment spam 🤷♂️ – sorry. Had some time to verify the concept sans butane sugar actually works as desired: name='fcos-ssh-certs'
buInc=$(realpath ./ssh)
ca=$(realpath ./ca)
ssh-keygen -t ecdsa -N "" -f "${buInc}/ssh_host_ecdsa_key" -C "${name}"
ssh-keygen -t ed25519 -N "" -f "${buInc}/ssh_host_ed25519_key" -C "${name}"
ssh-keygen -t rsa -N "" -f "${buInc}/ssh_host_rsa_key" -C "${name}"
ssh-keygen -s "${ca}" \
-I "${name} host key" \
-n "${name},${name}.local" \
-V -5m:+3650d \
-h \
"${buInc}/ssh_host_ecdsa_key" \
"${buInc}/ssh_host_ed25519_key" \
"${buInc}/ssh_host_rsa_key"
ign_config=$(butane --strict --files-dir="${buInc}" ssh-certs.bu | base64 | tr -d '\n') HostCertificate /etc/ssh/ssh_host_ecdsa_key-cert.pub
HostCertificate /etc/ssh/ssh_host_ed25519_key-cert.pub
HostCertificate /etc/ssh/ssh_host_rsa_key-cert.pub variant: fcos
version: 1.3.0
storage:
files:
- path: /etc/hostname
mode: 420
overwrite: true
contents:
inline: |
fcos-ssh-certs
- path: /etc/ssh/sshd_config.d/40-host-certificates.conf
mode: 0600
append:
- local: /sshd_config.d/40-host-certificates.conf
- path: /etc/ssh/ssh_host_ecdsa_key
mode: 0600
append:
- local: ssh_host_ecdsa_key
- path: /etc/ssh/ssh_host_ecdsa_key-cert.pub
mode: 0644
append:
- local: ssh_host_ecdsa_key-cert.pub
- path: /etc/ssh/ssh_host_ecdsa_key.pub
mode: 0644
append:
- local: ssh_host_ecdsa_key.pub
- path: /etc/ssh/ssh_host_ed25519_key
mode: 0600
append:
- local: ssh_host_ed25519_key
- path: /etc/ssh/ssh_host_ed25519_key-cert.pub
mode: 0644
append:
- local: ssh_host_ed25519_key-cert.pub
- path: /etc/ssh/ssh_host_ed25519_key.pub
mode: 0644
append:
- local: ssh_host_ed25519_key.pub
- path: /etc/ssh/ssh_host_rsa_key
mode: 0600
append:
- local: ssh_host_rsa_key
- path: /etc/ssh/ssh_host_rsa_key-cert.pub
mode: 0644
append:
- local: ssh_host_rsa_key-cert.pub
- path: /etc/ssh/ssh_host_rsa_key.pub
mode: 0644
append:
- local: ssh_host_rsa_key.pub
passwd:
users:
- name: core
ssh_authorized_keys:
- ssh-ed25519 <snip> $ ssh -v core@fcos-ssh-certs
#...
debug1: Server host certificate: ssh-ed25519-cert-v01@openssh.com SHA256:..., serial 0 ID "fcos-ssh-certs host key" CA ssh-rsa ... valid from 2021-04-21T18:38:36 to 2031-04-19T18:43:36
#... 🥳 |
Not to throw a wrench in the proposal, as I think ssh certificates would be a great option to support, this approach kinda flies in the face of best practices. In production environments at least, private keys should be generated on the box and never leave. So, instead, and I understand this isn't as ideal, the host should generate the keys, use information in the I found this issue because I was looking to solve the same problem, but with generic TLS certificates. For my use case, I will likely implement something like |
That's a very fair point and Step-Ca or HashiCorp Vault (with its client + SSH Engine) are also on my own radar (and have been for a while). This is one of the reasons I have not invested any time beyond the things written here. Other than that I tried to present a collection of "working" things to prevent a Wisdom of the Ancients situation. At the time I wrote this proposal + workarounds above I was not very familiar with step-ca/vault as options nor was I interested in the perfect solution … more of any (better) solution than what exists out of the box. |
Feature Request
Environment
What hardware/cloud provider/hypervisor is being used to run Ignition?
Any
Desired Feature
I would very much like it if ignition (and subsequently fcct/Fedora CoreOS) would natively support SSH certificate authorities. Currently the ignition spec supports a
security
declaration with custom certificate authorities fortls
as well as a user specific declaration for individualsshAuthorizedKeys
. Sadly, there is no built in way to roll out a SSH CA onto a machine with ignition.Having the ability to roll out an SSH certificate authority with ignition would greatly simplify SSH key management and deployment of machines (especially with the same canonical name). The dreaded host key verification dialog would thus be a thing of the past because a client could verify authenticity of the remote machine by virtue of the given certificate signed by a mutually trusted CA.
Other Information
This might be slightly icky because the host keys would have to be supplied alongside the host certificates via ignition because I don't see that injecting the signing authority certificate into the boot process to sign randomly generated certificates is a good idea.
For more information SSH CAs see e.g.:
The text was updated successfully, but these errors were encountered: