The SSH gateway on Athenode Pro

On Athenode Pro, the SSH gateway is shared by everyone who works in a project: each connection belongs to one project, and the project roles decide who sees it, who runs commands through it and who manages it. Athenode Pro is the Athenode server a team runs itself, with accounts, project roles and a licence. The SSH gateway is the part of Athenode through which your AI agent runs commands and transfers files on your SSH hosts, each action approved by you or by a rule you set. A connection is one SSH host in the SSH gateway, with its login, its host key and its rules.

On a Pro server, each person can log in to a host with their own SSH credentials, allow rules can be personal, shared by a connection or global to the server, and only the person whose agent asked can approve an action.

	The athenode daemon	Athenode Pro
Who can use the gateway	Anyone working on your machine, with no sign-in	Accounts with a role in the connection's project
Login methods	Password, private key, local key path, ssh-agent	Password and private key
Import from SSH config	Available	Not available
Credentials	One login per connection	Personal or shared credentials, chosen per connection
Always allow in an approval	Saves an allow rule on the connection	Saves a personal rule that applies to you only
Rules for every connection	The global denylist	The global denylist and global allow rules
The project of an AI agent's session	Named in the address of the Athenode MCP server, or found from the repository's `.athenode/config.json`	Always named in the address of the Athenode MCP server

Who does what with a connection

What you can do with a connection follows your role in its project. An administrator of the server has the rights of an owner in every project. An account without a role in a project sees none of its connections.

Project roles are a Pro Team and up feature. On Pro Solo, every account acts as an owner of every project and sees all its connections, as Pro tiers describes.

Role	What you can do with the project's connections
Viewer	See the connections without their secrets, their sessions, Live, History, the output of what already ran and the health of services. Run nothing.
Editor	Also run commands, background jobs, file tools, transfers and health checks, test connections, and keep your own personal credentials and personal rules.
Owner	Also create, edit, delete and copy connections, set their shared credentials and credential mode, trust host keys, and manage shared allow rules, denylist additions, services and, from Pro Team, the connection's webhook.
Administrator	Everything an owner can do in every project, plus the gateway settings, the global denylist and its exclusions per connection, global allow rules and, from Pro Team, the gateway webhook, all under Settings.

The Access section on a connection's Settings tab shows your level, such as "you use it: run commands, jobs and checks (an editor of the project)", and links to the project's Members page, where owners grant the roles. The full matrix for specifications, ToDo cards, plugins, the library, the project and the gateway is on Project roles.

Choose the credential mode of a connection

The credential mode of a connection decides whose SSH login people use on it. You set it when you create or edit a connection, which needs the owner role in its project.

The credential mode and personal credentials are a Pro Team and up feature. On Pro Solo, every connection uses only its shared credentials, a new connection is shared, and the form says "Connections use their shared credentials on this tier. Personal credentials need Pro Team or above."

Mode	How people log in	What the connection's own credentials do
Personal (recommended)	Each editor or owner logs in with their own personal credentials. Without them, they cannot run anything on the connection.	Serve background work only: health checks, including Run now, the status poll and the follow-up of background jobs started with them.
Shared	Personal credentials come first. A member without them logs in with the connection's own credentials.	Serve background work and every member without personal credentials.

A new connection starts in the personal mode, and so does every copy of a connection. Connections that existed before your server was upgraded to Athenode Pro 0.12.1 are in the shared mode, so they keep working as before.

On the connection's Settings tab, select Edit.
Under Credential mode, choose Personal (recommended) or Shared.
If you chose Shared, Athenode asks "Share these credentials?". Select Share the credentials to confirm, or Keep personal.
Save the connection.

The change applies to the next session on the connection. Switching from shared to personal ends the open sessions that log in with the connection's own credentials, including health checks that are running at that moment. Each change of the mode is recorded in the audit, with the account that made it.

The connection's own credentials run the health checks, and owners write those checks. The personal mode keeps each person's interactive work under their own login. It does not limit what the project's owners can run on the host.

In the personal mode, Test connection tests your personal login. Owners also see Test shared login, which tests the connection's own credentials and is how you confirm the host key that background work uses.

Set your personal credentials on a connection

Personal credentials are your own SSH login on one connection. Your sessions use them in place of the connection's own credentials, through every jump host on the way. Nobody can read them back, administrators included. You need the editor or owner role in the connection's project.

A connection that needs your credentials shows Your credentials needed in the connection list, and the navigation counts how many connections need them.

Open the connection and its Settings tab.
In Your credentials, enter your Username.
Under Authentication, choose Password or Private key.
Enter the Password, or paste the key into Private key (OpenSSH format) and, if the key has one, its Key passphrase (optional).
Optional: enter a Sudo password (optional). It is used when you run a command with sudo while you log in with your own credentials.
Select Save my credentials.

Athenode confirms "Your credentials are saved: your next sessions use them", and the section then shows the login you use and which secrets are stored. To change them, enter the new values and select Replace my credentials. A field you leave empty keeps its stored value as long as you keep the same method.

When you create a connection in the personal mode with a password or a private key, select Also use as my credentials in the connection form to store the same login as your personal credentials in one step.

On a connection in the personal mode, the connection's sudo password is never sent with your login. Store your own sudo password to run commands with sudo there.

A jump host in the personal mode needs your personal credentials too. Until you set them, a test of a connection behind it reports "The jump host" followed by its name and "needs your personal credentials", with Add your credentials next to it.

Remove your personal credentials

In Your credentials, select Remove.
Confirm with Remove credentials.

Your stored login is removed with its password, private key, passphrase and sudo password. On a connection in the shared mode, your next sessions use the connection's own credentials. On a connection in the personal mode, you cannot run anything on it until you add your credentials again.

See who has set personal credentials

Owners see Members' credentials on the connection's Settings tab: each owner and editor of the project, whether their personal credentials are set or missing, and when they last changed them. The list shows no secret.

What your AI agent sees without personal credentials

When you have no personal credentials on a connection in the personal mode, your agent's commands, file tools and background jobs on it are refused with PERSONAL_CREDENTIALS_REQUIRED and the name of the connection that needs them. The refusal comes before any approval and leaves no entry in History. Set your credentials, then ask the agent to try again.

Your AI tool reaches a Pro server under your own account, and the address of the Athenode MCP server names the project. Connect to Athenode Pro shows how to set this up.

Add a personal rule

A personal rule is an allow rule that applies to your own actions on one connection. Matching actions of yours run without asking. Nobody else is affected, and the denylist still applies. You need the editor or owner role.

Open the connection and its Rules tab.
In Personal rules, enter a pattern in New personal rule, such as git -C /srv/app status.
Select Add.

You can also save a personal rule while you decide an action. In Live, open the pending action, select Always allow…, check the pattern in the dialog Always allow for you and confirm. The action runs and the rule is saved.

Patterns follow the rules of every allow rule: globs, /regex/ patterns, file rules and sudo patterns, with the same exceptions that are never auto-approved. Approvals and rules describes them.

Manage the shared rules of a connection

Shared rules apply to everyone who uses the connection. Owners manage them on the connection's Rules tab:

Always allow: allow rules for everyone, added with New always-allow rule.
Denylist additions: patterns added with New denylist addition that always need approval on this connection only.

The section Global denylist on this connection lists the entries of the global denylist. Switching an entry off for one connection is for administrators.

Set global allow rules

Global allow rules let matching actions run without asking on every connection of the server, for everyone with access to it. The denylist still applies. Everyone can read them, and administrators change them.

Open Settings.
In Global allow rules, enter a pattern in New global allow rule, such as git status*.
Select Add.

When a rule lets an action run, the action's row in its session shows the pattern that matched, marked "(global)" for a global rule and "(personal)" for a personal one.

Approvals on a team server

Live lists every action that waits for approval or is running in the project, from every member. Only the account whose agent asked can decide an action, administrators included. Another member's pending action shows "Waiting for its user", and your own shows Open to decide.

The same applies to the rest of a session:

Only the owner of a session changes its confirmation mode.
An agent reads the status and logs of, and cancels, only the background jobs of its own account.
Every role in the project sees the whole History of its connections, with the output of each action.

The approval timeout, the outcomes and the confirmation modes are the same as on the daemon, on Approvals and rules.

Logins Athenode Pro allows

A connection on Athenode Pro logs in with a password or with a private key stored on the connection. A local key path and an ssh-agent are not offered, and Import from SSH config is not available. Create each connection in the web UI with a password or a key you paste in. The key formats the gateway accepts are listed on the SSH gateway page.

Copy a connection to another project

Copy to project creates an independent copy of a connection in another project, with its settings, credentials, host key, rules, services and tags. History, jobs and status are not copied, and the jump host must exist in the target project under the same name. On Athenode Pro:

you need the editor role in the source project and the owner role in the target project;
the connection's own credentials are copied only when you are an owner of the source project. Otherwise the copy has none, its status poll is off and its health checks are turned off;
the copy is always in the personal mode, so everyone sets their own credentials on it.

Your agent can do the same with the copy_connection tool of the Athenode MCP server, under the same conditions.

Export the gateway's audit

Every action through the gateway is an audit entry under the account whose agent started it. Members export their own entries and administrators everyone's, from Export audit in the sidebar. The History page, the export and the forwarding are a Pro Team and up feature, and on Pro Solo the entries are still recorded, as Pro tiers describes. Audit export and forwarding covers the export and the forwarding to a syslog server or a webhook.

Last updated: 2026-10-30