SSH without bastions or key distribution

The usual way to reach a fleet over SSH is a bastion plus a way of getting public keys onto every host - a configuration-management run, or an authorized_keys file somebody edits. Both age badly: the bastion is a permanently exposed port, and the key files drift from whoever actually works there.

The CLI agent can run an SSH server itself. It listens on TCP 24822 on the device's overlay address, its address inside SXAccess. Its authorized keys are the SSH keys of the devices an access rule connects this device with, in either direction. On a routing device of a network, they also include every device an access rule lets reach one of its resources. They come from the device's network map, the list of devices and routes that the management service keeps up to date on each device. When no access rule connects another device with this one any more, the next update removes the other device's key.

The server accepts interactive terminal sessions only: no remote commands, no scp or sftp, no port forwarding. Use the host's own sshd for those.

sxaccess shell first checks the target's host key against the key SXAccess distributes for that device. There is no prompt to trust the host on the first connection, and a host that presents any other key, or an address that belongs to no device, is refused.

• The bastion. There is no public SSH port to expose: the server listens only on the device's overlay address, so every session runs inside SXAccess.
• Key distribution. Authorized keys are maintained by SXAccess from the network map rather than by a configuration-management run.
• The leaver checklist. Blocking a member expires and disconnects every device they enrolled by signing in, at once. Removing them from the organization then deletes those devices, and a deleted device drops out of every network map, its SSH key with it. See Offboarding.

• Keep the host's own SSH daemon closed to the internet. SXAccess removes the need for a public port; it does not close one you left open.
• Name the account. Give user@ every time, with a personal or role account, so the target's own logs show who logged in.
• Switch SSH Access off where nobody needs it. The server only runs while both switches are on.

• Enabling the SXAccess SSH server requires root. Allowing the server needs root on the target. The message suggests two sudo commands; run sudo sh -c 'sxaccess stop && sxaccess start --allow-server-ssh' instead, as one line, as in step 1.
• This device is already connected, and SSH still does not work. start changes no setting while the device is connected; see start. Restart the agent with the flag: sudo sh -c 'sxaccess stop && sxaccess start --allow-server-ssh'. Run it as one line: a connection that goes through SXAccess, such as an SSH session to this machine, drops until start has finished.
• error: this command needs Administrator rights. sxaccess shell needs root on your own device too. Run it with sudo.
• SSH connection failed, and sxaccess info -d does not list the target. No access rule connects your device to it. Write the rule from step 3, or check that your device is in the rule's source group.
• SSH connection failed, and the target is listed. Its server is not running. Check under Devices that the target is online and that SSH Access is on and saved. On the target, the agent must run with --allow-server-ssh and without --block-inbound. To lift that block, run sxaccess stop && sxaccess start --block-inbound=false. Run it as one line: a connection that goes through SXAccess, such as an SSH session to this machine, drops until start has finished.
• The target runs Windows or one of the apps. The server is not available there: it runs only with the CLI agent on Linux and macOS.