@behrmann Do consider the UX you want on this. Currently you can only get a hold of the public keys with ssh-tpm-keygen -A --hierarchy owner. But maybe a bare --hierarchy owner should be permitted as well?

Do consider the UX you want on this. Currently you can only get a hold of the public keys with ssh-tpm-keygen -A --hierarchy owner. But maybe a bare --hierarchy owner should be permitted as well?

I'm not sure I understand what the difference would mean.

I gather there wouldn't be a semantic difference, when keys for a given hierarchy already exist, since -A would be a noop then, right? But if they don't exist yet, it probably shouldn't create them (imply -A) and error out instead?

I haven't built this yet, but I'll testdrive it tomorrow.

I gather there wouldn't be a semantic difference, when keys for a given hierarchy already exist, since -A would be a noop then, right? But if they don't exist yet, it probably shouldn't create them (imply -A) and error out instead?

Well, -A --hierarchy would only really be useable when you are setting up host keys. But if you are a user that want to pre-seed your agent you probably want to have a way to produce the public key files.

Maybe I'm still misunderstanding, but wouldn't that be something for a -l option?

While the ssh-tpm-agent understands PREFIX and DESTDIR and can be used to generate the unit files when packaging (I packaged it to get it on my test system), this doesn't work for ssh-tpm-hostkeys --install-sshd-config, I'll open a separate issue for that, since I think that's an issue already.

Fwiw, I regret implementing that entire thing. I thought it would be neat but it's clear to me it's just way too complicated.

Related, I'm not sure whether it makes sense to have hostkeys from different hierarchies at the same time, but if so, it might make sense to encode the name of the hierarchy in the filename, since otherwise the condition in the keygen service would not be able to tell apart different hierarchies.

I don't see a use-case for this yet so I reckon this is a "WONT FIX" until someone gives me a better idea.

Speaking of the unit files, though, with the introduced hierarchy setting, they should maybe become template units with DefaultInstance=owner.

I actually can't quite tell what this setting does?

Fwiw, I regret implementing that entire thing. I thought it would be neat but it's clear to me it's just way too complicated.

Maybe a good point to drop it then? You're still below 1.0. I have to agree that the UX there is problematic.

I don't see a use-case for this yet so I reckon this is a "WONT FIX" until someone gives me a better idea.

Fine by me.

I actually can't quite tell what this setting does?

I'm currently running these unit files

# ssh-tpm-agent@.service
[Unit]
ConditionEnvironment=!SSH_AGENT_PID
Description=ssh-tpm-agent service
Documentation=man:ssh-agent(1) man:ssh-add(1) man:ssh(1)
Wants=ssh-tpm-genkeys@%i.service
After=ssh-tpm-genkeys@%i.service
After=network.target
After=sshd.target
Requires=ssh-tpm-agent@%i.socket

[Service]
ExecStart=/usr/bin/ssh-tpm-agent --key-dir /etc/ssh --hierarchy %i
PassEnvironment=SSH_AGENT_PID
KillMode=process
Restart=always

[Install]
WantedBy=multi-user.target
DefaultInstance=endorsement

[Unit]
Description=SSH TPM agent socket
Documentation=man:ssh-agent(1) man:ssh-add(1) man:ssh(1)

[Socket]
ListenStream=/var/tmp/ssh-tpm-agent.sock
SocketMode=0600
Service=ssh-tpm-agent@%i.service

[Install]
WantedBy=sockets.target
DefaultInstance=endorsement

and

[Unit]
Description=SSH TPM Key Generation
ConditionPathExists=|!/etc/ssh/ssh_tpm_host_ecdsa_key.tpm
ConditionPathExists=|!/etc/ssh/ssh_tpm_host_ecdsa_key.pub
ConditionPathExists=|!/etc/ssh/ssh_tpm_host_rsa_key.tpm
ConditionPathExists=|!/etc/ssh/ssh_tpm_host_rsa_key.pub

[Service]
ExecStart=/usr/bin/ssh-tpm-keygen -A --hierarchy %i
Type=oneshot
RemainAfterExit=yes

The DefaultInstance makes that when doing systemctl enable ssh-tpm-agent@.socket what actually gets enabled is ssh-tpm-agent@endorsement.socket, i.e.

# systemctl enable ssh-tpm-agent@.socket
Created symlink /etc/systemd/system/sockets.target.wants/ssh-tpm-agent@endorsement.socket → /lib/systemd/system/ssh-tpm-agent@.socket

I'm not entirely sure whether this is actually worthwhile. In light of the above "WONT FIX", it's probably better to just ship a dropin that changes the ExecStart=—I usually don't want to do that, but the ones here are plain enough and probably won't change much.

The most important thing: I can't say whether this so far survives a reboot with my testing, I've been holding it wrong for a bit and waiting for my machine to reinstall.

I can report back now, it's working fine. The endorsement hierarchy key survives fine.

@behrmann ah, the service files are clever. I'll need to think a little bit on how this could be packaged up in the project though.

Added service files here https://github.com/Foxboron/ssh-tpm-agent/tree/morten/hierarchy-keys/contrib/services/hierarchy_keys

Not sure how I'll distribute it yet, but now it's somewhere :)