SSH and Connectivity

SSH is how Devpilot talks to your servers. Every management operation — installing software, running scripts, creating databases, streaming terminal sessions, taking backups — runs over a secure SSH session initiated by Devpilot. Understanding how authentication works keeps your servers reachable and your access auditable.

Authentication Methods

Devpilot supports three authentication modes. You pick one when you add the server and can update it later.

Password

You provide the SSH user's password. Devpilot encrypts and stores the password and uses it to log in.

Uploaded Keys

You provide your own OpenSSH-format private key (and passphrase if it's encrypted). Devpilot uses that key to authenticate as the SSH user. You keep a copy of the key locally; Devpilot stores its copy securely inside your workspace so it can reconnect.

Supported key types:

ssh-keygen -t ed25519 -C "your-email@example.com"

ssh-keygen -t rsa -b 4096 -C "your-email@example.com"

Generated Keys

Devpilot generates a fresh SSH key pair scoped to the server. You deploy the public key to the server once (either by pasting it into ~/.ssh/authorized_keys during setup or, for provisioned servers, having Devpilot place it during provisioning). Devpilot retains the private key so it can reconnect.

This is the default for servers you provision through Devpilot, because the entire flow — including key placement — is automated.

How Keys Are Stored

For uploaded and generated keys, Devpilot stores the key material on disk under a workspace-scoped path (for example app/workspaces/<workspace>/server_keys/<server>/<timestamp>/ssh_key) with both an OpenSSH key and a PuTTY-format .ppk variant. Only the Devpilot backend accesses these files.

Connection Status

Every server shows a live connection status in the server list and dashboard:

• Connected — Devpilot currently has a working SSH session. All management features work.
• Disconnected — Devpilot can't reach the server. Devpilot retries automatically; management operations that require SSH are unavailable until the connection is restored.

Disconnection is usually transient — a network blip, a reboot, a firewall tweak — and resolves on the next retry.

Troubleshooting Connectivity Issues

If a server is stuck Disconnected, work through the following.

Network and firewall

• Verify the server is powered on. For cloud servers, check the provider console.
• Confirm the IP address or hostname Devpilot has on file still points to the server. Instance reboots on some providers can change the public IP.
• Confirm the SSH port is open on both the OS-level firewall and any cloud security groups.
• From a separate machine, try ssh -p <port> <user>@<host> or nc -vz <host> <port> to rule out a general networking issue.

SSH daemon

• Make sure sshd is running: systemctl status ssh (or sshd).
• If someone changed the SSH port in sshd_config, update it in Devpilot's server settings.
• File permissions matter: ~/.ssh should be 700, ~/.ssh/authorized_keys should be 600, and the user's home directory must not be group- or world-writable.

Authentication

• If the server uses password auth and the password was rotated, update it in Devpilot's server settings.
• If the server uses key auth and the authorized_keys file was rewritten (for example by a configuration management tool), re-add Devpilot's public key.
• Confirm the user account isn't locked or disabled.

Hardened SSH configs

If you've tightened sshd_config, make sure Devpilot isn't blocked:

• AllowUsers / AllowGroups — The Devpilot user must be in the allowed list.
• MaxSessions — Devpilot opens multiple concurrent sessions. Set it to at least 10.
• MaxStartups — Too-low values can cause dropped connections during bursts.

Security Best Practices

• Prefer key authentication over passwords for production servers.
• Prefer ED25519 for new key pairs — stronger and smaller than RSA.
• Disable root SSH login once a sudoer account is configured and tested.
• Disable password auth once key auth is verified working.
• Use a non-standard SSH port to cut down on automated scanning noise (this complements, but does not replace, strong authentication).
• Rotate keys periodically — remove stale public keys from authorized_keys when people leave or machines are retired.
• Review auth logs (/var/log/auth.log on Debian/Ubuntu, /var/log/secure on RHEL-family) for unexpected login attempts.