Securing SSH

⚠️ An AI client with an active connector connection can read and write files, execute shell commands, run database queries, and perform deployments — all under the configured SSH user. Securing this user is therefore critical.

What is the risk?

Through the FlawDesk Code Connector, an external AI client gets direct access to your server. This access is as broad as the permissions of the configured SSH user:

File access — read and write anywhere the user has permissions
Shell commands — start processes, modify configurations, install packages
Database — queries against all reachable databases
Deployments — write files to any directory

A root user or an unrestricted user means full server access in case of an error or misuse.

Create a dedicated user

Create a separate user exclusively for the FlawDesk Connector — not root, not your personal account.

adduser --disabled-password --gecos "" flawdesk-agent

Grant this user write access only to the directories it actually needs:

chown -R flawdesk-agent:flawdesk-agent /var/www/my-app
chmod 755 /var/www/my-app

Everything the user doesn't need — other web directories, system configurations, other databases — should be inaccessible to it.

Restrict the SSH key

In the user's authorized_keys file, you can further restrict the key. For rsync-based deployments:

command="rrsync /var/www/my-app",no-agent-forwarding,no-port-forwarding,no-pty,no-user-rc,no-X11-forwarding ssh-ed25519 AAAA... your-key

rrsync is a restricted rsync wrapper script that limits access to the specified directory. It is included in most distributions as part of the rsync package.

Restrict database access

If the Connector needs database access, create a dedicated database user with rights only on the relevant databases:

CREATE USER 'flawdesk_agent'@'localhost' IDENTIFIED BY '...';
GRANT SELECT, INSERT, UPDATE, DELETE ON my_app.* TO 'flawdesk_agent'@'localhost';

No GRANT ALL, no access to mysql.* or other databases.

Systemd-based restriction (optional)

For additional isolation, you can restrict the user to specific paths via Systemd:

[Service]
User=flawdesk-agent
ReadWritePaths=/var/www/my-app
ProtectSystem=strict
ProtectHome=true
NoNewPrivileges=true

⚠️ These restrictions only apply to processes started through this Systemd unit — not to direct SSH logins.

Summary

Create a dedicated user for the Connector (not root)
Restrict filesystem permissions to what is necessary
Create a database user with minimal permissions
Restrict the SSH key in authorized_keys using command=

Workspace permissions as a second layer of protection

SSH hardening controls what is possible on the server. An independent additional layer of protection is the workspace permissions in FlawDesk — they control which MCP tools a user may call through their token, regardless of the SSH user.

This means: even if the SSH user could theoretically perform deployments, the gateway will block calls to flawdesk_code_deploy if the user does not have the Trigger deployments permission. Both layers operate independently of each other.

For production environments, the recommended combination is:

SSH user with minimal filesystem permissions (this page)
User group in FlawDesk with only the actually required permissions (Workspace Settings → Permissions)