How to Give Claude SSH Access to a Development Server

Giving Claude Code SSH access to a development server means setting up remote development so Claude Code runs commands in an environment that can reach the server—not pasting credentials into the chat. Tools like fenbs keep the authorized task scope and handoff record so every session knows what is approved without needing to store or transmit credentials.

Never paste a private key, password, or connection string into a Claude conversation. Those details end up in conversation history and may be logged. Set up the SSH connection in your environment before starting a Claude Code session, then tell Claude what the connection is called, not how to authenticate to it.

What SSH access means for Claude Code

Claude Code runs commands in your local shell. To reach a remote server, it needs a way to run commands there. The two most common patterns are running Claude Code inside a VS Code Remote SSH session (Claude Code executes locally but the workspace points at the remote), or using a remote development server where Claude Code is installed directly and accessed over an SSH tunnel.

In both cases, the SSH authentication happens at the environment level—your SSH agent, your key files, your config in ~/.ssh/config. Claude Code does not manage SSH credentials. It runs whatever commands you tell it to, in the shell it has access to. If that shell can SSH to a server, so can Claude Code.

Setting up the SSH connection before starting Claude

Complete the SSH setup before opening a Claude Code session. Test the connection manually, add the server to your ~/.ssh/config with a friendly name, and confirm you can run commands on the remote without entering a passphrase. Then open Claude Code with that environment already working.

• Add the server to ~/.ssh/config with a Host alias, HostName, User, and IdentityFile.
• Load the key into your SSH agent with ssh-add so Claude Code does not encounter a passphrase prompt mid-task.
• Test the connection with ssh your-alias echo ok before starting the session.
• For VS Code Remote SSH, open the remote folder in VS Code first, then start Claude Code in the integrated terminal.

If the connection drops mid-session, Claude Code will see a shell error when it tries to run a command on the remote. Tell it to stop and reconnect rather than trying to diagnose the failure as a code problem.

Credential handling: what never goes in the chat

Private keys, passphrases, server passwords, API tokens, and database connection strings should never appear in a Claude conversation. If a task requires a credential, store it in a secrets manager, an environment variable, or a .env file that is excluded from the context. Tell Claude where the credential lives, not what it is.

A CLAUDE.md rule like "Never ask for or paste credentials; read them from environment variables or .env files only" sets a clear boundary. If Claude Code cannot complete a task without a credential it does not have access to, it should ask you to add it to the environment—not ask you to type it in.

See how to give an AI agent access to your project board for how fenbs handles agent authorization without exposing credentials.

Approval boundaries and task scope

Treat remote server access as a named permission, not a general one. Write a task that says "Install the updated build artifact on the staging server at staging.example.internal" and give Claude the commands for that specific task. That is narrower than "you have SSH access to all our servers; do what you need."

Set boundaries in CLAUDE.md for the remote environment: which directories Claude may write to, which services it may restart, and which changes require a person to review before they are applied. A clear boundary makes the session auditable—you can check what ran against what was approved.

For production servers, require explicit approval for every command that changes state. Claude Code can propose the commands; you run them. The safest pattern is: Claude drafts the commands, you review and run them yourself, Claude reads the output and continues.

Keeping a handoff record

Remote development sessions often span multiple connections. When a session ends—whether by plan or because the connection dropped—record where things stand: which commands ran, what they changed, what still needs to happen. The next session should not have to re-discover the remote state by reading logs.

A handoff note for a remote task might read: "Installed artifact version 2.3.1 on staging; restart of the web service is pending—it requires a maintenance window. The rollback command is recorded in the task notes." That is enough for the next session to continue safely.

How to do this with fenbs

Connect Claude Code to fenbs to keep the access decisions and handoff record for remote work.

1. Create a free account and add a project for the remote environment or the work being done on it.
2. Connect Claude Code from Integrations and follow the MCP setup guide.
3. Add a Decision for each approved remote connection: the server alias, the approved task scope, who approved it, and the date. Never include the actual credentials.
4. Add a standing rule for credential handling: "Read credentials from environment variables or .env files only; never accept credentials as chat input." Rules appear first in the AI context every session reads.
5. At the end of each remote session, ask Claude Code to save progress in fenbs: what ran, what changed, what still needs to happen, and whether anything is waiting on a person. The next session starts from that record.