SSH access
A device runs an SSH server so you can reach its console for administration. You control whether SSH is enabled, how users authenticate, and where connections may originate. SSH settings are managed from the dashboard (or the API) and applied to the device automatically.
Enabling or disabling the SSH server
You can turn the SSH server off entirely for devices that should never accept direct shell access. With the server disabled, you can still administer the device through remote access over the platform connection.
Authentication
You can control how users authenticate:
| Setting | Effect |
|---|---|
| Disable password authentication | Require keys; passwords are not accepted. |
| Disable key authentication | Accept only password authentication. |
| Authorized keys | The set of public keys allowed to log in. |
Authorized keys
You can provide one or more authorized public keys. Each key entry supports the usual SSH key options, including:
- marking a key as a certificate authority, so SSH certificates it signs are accepted
- restricting a key to specific source addresses
- forcing a specific command
- applying restrictions and principals
Using a certificate authority is recommended for fleets: you can issue short-lived SSH certificates to operators instead of distributing individual keys to every device.
Restricting where connections come from
You can limit which source addresses may connect:
- an allow list of addresses/ranges permitted to connect
- a deny list of addresses/ranges that are blocked
This is the closest thing to a host firewall for SSH and is the recommended way to limit exposure when SSH must remain reachable on a LAN.
Brute-force protection
The device protects the SSH service against repeated failed login attempts by temporarily banning offending sources. You can tune this behavior through the device configuration, including:
- the ban duration applied to an offending source
- an ignore list of trusted sources that are never banned
Recommendations
- Prefer key or certificate authentication and disable passwords where possible.
- Use source restrictions to limit who can reach SSH.
- Keep an ignore list for your own management hosts so administrative tooling is not banned.
Related
- User accounts — the administrator account used for login.
- Remote access — administer devices without exposing SSH on the LAN.