SSH access

The host's SSH tab controls how you and your team connect to a host over SSH. From here you manage the public keys allowed to log in and whether password-based login is permitted.

You log in as a system user, not as root. Its password is on the host's Credentials tab, where you can reveal and copy it. New to this? Start at Accessing your server.

This tab covers:

• SSH keys - manage the public keys allowed to log in
• Keys for specific accounts - limit a key to some system users
• Password authentication - allow or disable password-based login
• Overriding a group setting - make this host's choice win
• SSH port - change the port SSH listens on

SSH keys

The table lists the public SSH keys allowed to access the server, with their Name and their Access. Access is All accounts or the list of system users the key is limited to. Add, edit, or delete keys as your team changes.

Each key supports an optional name or label to help you identify its owner or purpose. Both ed25519 and RSA (Rivest-Shamir-Adleman) keys are supported. For a step-by-step walkthrough of generating a keypair, see Add an SSH key.

To add a key:

1. Open the SSH tab for the host.
2. Select Add SSH Key.
3. Paste the public key. It must start with ssh-rsa or ssh-ed25519.
4. Optionally enter a name or label for the key.
5. Choose the access (see below) and select Save on the row.
6. Select Save & Publish in the host header. The row's Save only keeps the row. The key reaches the server when you publish the host.

Keys for specific accounts

By default a key opens every system user on the host (ssh_keys in the configuration). When an agency or a developer should only reach one application, limit the key:

1. Select Edit on the key, or add a new one.
2. Choose Only specific accounts and tick the system users it may open.
3. Select Save on the row, then Save & Publish.

In the configuration an account-specific key is stored under the system user, as system_users[].ssh_keys, in the same type key name format. A host without accounts offers only All accounts on this host: the key then opens every account added later.

Inherited group keys

SSH keys can also be defined at the group level. When a host belongs to a group, it inherits the group's SSH keys in addition to any keys defined directly on the host. This lets you grant a set of keys access across many hosts at once. Group keys always open every account on the host. They cannot be limited to specific accounts. See Groups for how inheritance works.

Password authentication

Only allow SSH authentication by keys controls whether password-based SSH login is permitted. Switch it on and users can connect only with an SSH key. In the configuration this is ssh_passwords: false - the checkbox is worded the other way round from the key it writes.

Before disabling password authentication, confirm that every user who needs access has a working SSH key configured so that no one is locked out.

Overriding a group setting

When a host belongs to a group, the group can also decide whether passwords are allowed. By default the stricter setting wins. If any of the host's groups disables password login, it is disabled on the host too, whatever the host itself says.

Enforce host SSH password setting changes that. Switch it on and the host's own choice above applies, ignoring its groups. The checkbox appears only when the host is in at least one group.

Enforce	What decides
Off (default)	A group that disables password login wins. Otherwise the host's own setting applies.
On	The host's setting applies, whether that allows passwords or not.

SSH port

The ssh_port setting controls which port the SSH service listens on. Changing it from the default can reduce noise from automated scans.

Related

• Credentials - where each system user's password is

• Accessing your server - the short overview

• TurboStack CLI - the tscli tool you run once connected over SSH

• Security

• Groups

• Applications

• Hosts overview