Enforcing security constraints around SSH public key types

[tomfitzhenry]

Hi all,

I have a fleet of personal machines, some of which I consider to be important, and others that are throw-away. For the important machines, I try to enforce that only FIDO SSH keys can be used to SSH onto them.

In the past I've done this in Nixlang (via assertions to fail the build if a constraint is not satisfied), but I wanted to move to something a bit more distro-agnostic, to include my non-NixOS machines.

Here's what I've done in Cue:

// Package sshd manages set of SSH public keys, and a mapping from host to which public keys that host accepts.
package sshd

// ===================================
// CUE Definitions (Schema)
// ===================================

#KeyType: "ssh-rsa" | "ed25519-sk" | "ecdsa-sk"

#HardwareBackedKeyType: "ed25519-sk" | "ecdsa-sk"

// #KeyIdentity defines the structure for a single SSH public key entry.
#KeyIdentity: {
	name:  string
	type:  #KeyType
	value: string // The actual public key string (e.g., "AAAAB3Nz...")
}

#LinuxHost: {
	hostname: string
	acceptedKeys: {
		[string]: #KeyIdentity
	}
}

// #SecureHost defines the structure for a host that requires extra security for its accepted keys.
#SecureHost: #LinuxHost & {
	// Constraint: Every item in the acceptedKeys array must conform to the #HardwareBackedKeyIdentity schema.
	acceptedKeys: {
		[string]: {
			type: #HardwareBackedKeyType
		}
	}
}

// ===================================
// Configuration Data (Instances)
// ===================================

// identities holds the source of truth for all valid SSH keys.
_identities: {
	[string]: #KeyIdentity

	"alice-laptop": {
		name:  "Alice"
		type:  "ssh-rsa"
		value: "AAAA_ALICE_PUBLIC_KEY_123..."
	}
	"bob-server-key": {
		name:  "Bob"
		type:  "ed25519-sk"
		value: "AAAA_BOB_PUBLIC_KEY_456..."
	}
	"sysadmin-security-key": {
		name:  "Security Admin FIDO"
		type:  "ed25519-sk"
		value: "AAAA_SYSADMIN_SECURITY_KEY..."
	}
}

// hosts specifies which hosts accept which key identities.
hosts: {
	[string]: #LinuxHost

	// Constraint: The sysadmin can access all machines.
	[string]: {
		acceptedKeys: {
			"sysadmin-security-key": _identities["sysadmin-security-key"]
		}
	}

	"web-server": {
		hostname: "web.example.com"
	}

	"db-server": #SecureHost & {
		hostname: "db.example.com"
		// If you tried to add a non-SK key, validation would fail.
	}

	"test-vm": {
		hostname: "test.example.com"
		// Since test-vm is not a SecureHost, adding non-hardware-backed keys is permitted.
		acceptedKeys: {
			"alice-laptop":   _identities["alice-laptop"]
			"bob-server-key": _identities["bob-server-key"]
		}
	}
}

The output is a JSON object, from hostname to the list of keys that the host should accept:

{
    "hosts": {
        "web-server": {
            "hostname": "web.example.com",
            "acceptedKeys": {
                "sysadmin-security-key": {
                    "name": "Security Admin FIDO",
                    "type": "ed25519-sk",
                    "value": "AAAA_SYSADMIN_SECURITY_KEY..."
                }
            }
        },
        "db-server": {
            "acceptedKeys": {
                "sysadmin-security-key": {
                    "name": "Security Admin FIDO",
                    "type": "ed25519-sk",
                    "value": "AAAA_SYSADMIN_SECURITY_KEY..."
                }
            },
            "hostname": "db.example.com"
        },
        "test-vm": {
            "hostname": "test.example.com",
            "acceptedKeys": {
                "sysadmin-security-key": {
                    "name": "Security Admin FIDO",
                    "type": "ed25519-sk",
                    "value": "AAAA_SYSADMIN_SECURITY_KEY..."
                },
                "alice-laptop": {
                    "name": "Alice",
                    "type": "ssh-rsa",
                    "value": "AAAA_ALICE_PUBLIC_KEY_123..."
                },
                "bob-server-key": {
                    "name": "Bob",
                    "type": "ed25519-sk",
                    "value": "AAAA_BOB_PUBLIC_KEY_456..."
                }
            }
        }
    }
}

I then feed this JSON into NixOS, to ensure each host accepts the right set of keys. Likewise for other OSs.

This enforces two properties:

• my sysadmin FIDO keys enables me to SSH into all machines (this acts more as a config deduplication)
• any important host can only be accessed via a FIDO key

This is my first Cuelang, and I'm keen for any feedback.

In particular, is there a way to avoid awkward config like this:

		acceptedKeys: {
			"alice-laptop":   _identities["alice-laptop"]
			"bob-server-key": _identities["bob-server-key"]
		}

Having "alice-laptop" twice feels like unnecessary code, and risk for weird bugs. A set (rather than a map or list) feels like a more natural data type. Maybe https://cuetorials.com/cueology/futurology/associative-lists/ would help me?

[perelo]

Hello and welcome,

The straightforward way to deduplicate would be to apply the _identity to all acceptedKeys using an pattern constraint with alias on the key-key. Then, hosts would add key entries as fields with top value _.

hosts: {
	[string]: acceptedKeys: [Key=string]: _identities[Key]
	"test-vm": acceptedKeys: {
		"alice-laptop":   _
		"bob-server-key": _
	}
}

This may be a little bit weird for users. A list could be used instead and then processed to output the final struct, but it doesn't work well when composing multiple lists of keys that are set from different places because unifying of lists works by unifying each element 2 by 2

hosts: {
	[string]: {
		_acceptedKeys: [...string]
		acceptedKeys: {
			for key in _acceptedKeys {
				(key): _identities[key]
			}
		}
	}
	[string]: _acceptedKeys: [ "sysadmin-security-key", ... ] // first element, need to know that there may be more (trailing ...)
	"test-vm": _acceptedKeys: [ _, "alice-laptop", "bob-server-key" ] // need to know that there is a first element (leading _) and forbids more keys
}