← Blog

An app that tails logs over SSH holds the keys to every machine it watches. Where it keeps them matters more than any feature you can see. Here is how LogRaker handles them, and what changes now that a key can live in your Mac’s Secure Enclave.

No files, no agent, no subprocess

LogRaker speaks SSH itself, through swift-nio-ssh, inside its own process. It never runs ssh, never talks to ssh-agent, and never writes a key to a temporary file for another program to read.

When you pick a key file in a Source editor, LogRaker reads it once and stores its contents in the macOS Keychain. From then on the Source signs in with the stored copy, not the file. Passwords and passphrases go to the same place. LogRaker’s database, an exported .lograker configuration, and the iCloud records that sync your setup never contain a secret.

The keychain, and iCloud Keychain

Credentials are stored as synchronizable items in the data-protection keychain. Two things follow from that:

• They reach your other Macs through iCloud Keychain, which is end-to-end encrypted with keys only your own devices hold. Apple can’t read them. Set a Source up on one Mac and it connects on the others, with no key file to pick again.
• They can be read only after the Mac has been unlocked once since it started, never while it sits at the login window.

A passphrase is stored under the SHA-256 of its key’s public half, not under a Source. One encrypted key used by five Sources is unlocked once, and the keychain entry doesn’t contain the public key itself.

These items don’t show up in Keychain Access, so Settings ▸ Security ▸ ‘Stored Credentials…’ lists them: what each secret is, what uses it, and whether anything on this Mac still does.

Deleting a Source doesn’t delete its credential on the spot, because Undo brings the Source back and the credential has to be there for it. At quit, the Mac where you deleted it removes the credential if the Source is still gone, and iCloud Keychain removes it everywhere else. A credential is never removed just because no Source seems to need it. Sources and credentials sync separately, so a Mac may have the credential before the Source arrives. Deleting by absence would destroy a working secret on all your Macs.

The SSH Key Manager

Tools ▸ ‘SSH Key Manager’ does what ssh-keygen and ssh-copy-id do, without Terminal. ‘Create Key’ makes an Ed25519 key pair with CryptoKit, and the private half goes straight into the keychain. It touches the disk only if you export it.

‘Deploy’ signs in to the server the way the Source already does (its key, its stored password, or a password you type once and that is not stored) and runs:

mkdir -p -m 700 ~/.ssh && touch ~/.ssh/authorized_keys \
  && chmod 600 ~/.ssh/authorized_keys \
  && { grep -qxF '<key>' ~/.ssh/authorized_keys \
       || echo '<key>' >> ~/.ssh/authorized_keys; }

Then it connects again with the new key, and only reports success if that works. Removing a key does the reverse and checks that the key no longer signs in. A key can’t be deleted while it is still installed on a server, so no forgotten lines are left behind in authorized_keys.

Export writes the private key as a file with mode 600 from its first byte, so there is no moment when other users on the Mac could read it.

Touch ID, if you want it

Settings ▸ Security ▸ ‘Require Touch ID for stored credentials’ makes LogRaker ask before it uses any of them. One prompt unlocks all of them until your Mac locks or sleeps, you switch users, or you quit.

Streams that are already running keep running while the Mac is locked, reconnects included. A log viewer that stopped every time the screen locked would be no use overnight. A Stream asks again when it starts, or when you change what it reads or how it signs in.

Keys that can’t be copied

iCloud Keychain is a good default. It is end-to-end encrypted, and it is what makes a Source work on every Mac. But a synced key exists, by design, in more than one place. Some people want a key that cannot leave the machine at all.

That is what the Secure Enclave is for. It is a separate processor in every Apple silicon Mac, and in Intel Macs with a T2 chip, that creates keys and signs with them but never hands a private key out: not to the app, not to macOS, not to you.

Getting OpenSSH to use one is still fiddly, and tools like Secretive exist to fill that gap. They are good at it if you live in Terminal. LogRaker has its own SSH stack, so it can use the Secure Enclave directly. There are two ways in:

• SSH Key Manager ▸ ‘Create Key’ ▸ ‘Store in the Secure Enclave’, then ‘Deploy’ as usual.
• In a Source editor, set Auth to ‘Secure Enclave’ and click ‘Create and Deploy…’. LogRaker creates the key, installs it on the server and picks it for the Source, in one step.

Under the hood, the key is created like this:

let access = SecAccessControlCreateWithFlags(
    nil, kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly,
    .privateKeyUsage, &error)
let key = try SecureEnclave.P256.Signing.PrivateKey(accessControl: access!)

What LogRaker keeps is key.dataRepresentation: an opaque handle that only this Mac’s Secure Enclave can turn back into a working key. It is stored in the keychain on this Mac only. It doesn’t sync, isn’t in backups, and is useless anywhere else.

The Secure Enclave offers one curve, P-256, so these are ecdsa-sha2-nistp256 keys. OpenSSH has accepted them since 2011, and so does dropbear, the server on many small devices.

The key doesn’t ask for Touch ID on every signature. Streams reconnect on their own at 3 a.m., and a key that needs a finger every time would leave them waiting. If you want a prompt, the Touch ID switch above covers these keys too.

One key per Mac

A key that cannot leave a Mac cannot sync, so each Mac needs its own. The Source’s setting does sync: on every Mac, “use the Secure Enclave” means that Mac’s own key. Your other Macs list the key as being in the Secure Enclave of another Mac. A Mac without a key of its own yet stops the Source’s Streams and says what to click. Removing one Mac’s key from a server leaves the keys of your other Macs in place.

Deleting a Secure Enclave key destroys it for good, so LogRaker only does that after you delete it and quit. It never deletes one because a row seems to be missing from the Key Manager’s list, say after restoring an older configuration or while iCloud is still catching up. A lost handle is a lost key.

What it doesn’t protect against

The Secure Enclave stops the key from being copied. It doesn’t decide who may use it: while your Mac is unlocked, LogRaker signs in without asking unless you turn the Touch ID switch on.

And a key that can’t be copied can’t be recovered either. A new Mac, a wiped one or a replaced logic board means the key is gone. Keep another way in, such as a second Mac’s key, a synced key or a password, for every server that matters.

Which one to use

A synced key is one key on all your Macs. It can be exported and is protected by iCloud Keychain. A Secure Enclave key is tied to one Mac, can’t be exported and can’t be stolen as a file. Both work in both editions of LogRaker, and you can mix them: a synced key for the Raspberry Pi in the closet, a Secure Enclave key for production.