Team Access Without Sharing Passwords: SSH Key Management

Adding a teammate

neo key add [email protected] --key ~/.ssh/id_ed25519.pub

This appends their public key to the server's authorized_keys — nothing secret ever moves between machines. They authenticate with their own private key, which never leaves their laptop.

Listing and removing

neo key list       # who has access to the current server
neo key remove [email protected]

Removing revokes access immediately — no shared password to rotate, no key to redistribute to everyone else.

Automatic key discovery

When you run neo init or connect to a server for the first time, Neo checks ssh-agent, then ~/.ssh/id_ed25519, then ~/.ssh/id_rsa, before falling back to a password prompt — so on most machines, adding a server is zero-config: Neo finds a key that already works.

Multi-server correctness

neo key add targets the currently active server by default — on a machine with several servers configured, adding a key without confirming the target used to occasionally apply to the wrong one when server resolution and the key command disagreed on which was "current." That's fixed; neo key add --server <name> still lets you be explicit regardless.

Why this is safer than sharing root

A shared root password (or a shared private key, which is nearly as bad) means revoking one person's access means rotating credentials for everyone. Per-person public keys mean revoking one person is one command, and every action they took is attributable to their own SSH session in the server's auth logs.