Skip to main content

Troubleshooting SSH "Permission Denied (publickey)" on DreamHost

 There are few context switches more jarring than moving from a seamless local development environment to a production server that refuses to let you in. You have generated your SSH keys, you have added the public key to the server, yet the terminal returns the infamous, flat rejection:

user@server.dreamhost.com: Permission denied (publickey).

On most raw Linux VPS instances, this indicates a file permission error or a missing entry in authorized_keys. However, on managed hosting platforms like DreamHost, the issue is rarely within the Linux filesystem itself. The root cause usually lies within the proprietary orchestration layer that manages user privileges.

This guide details the specific architectural constraints of DreamHost’s user management system and provides a rigorous, step-by-step resolution to restore your shell access.

The Architecture of the Failure

To fix the problem, we must understand the environment. DreamHost, like many managed hosting providers, does not provide standard users with root access. Instead, they utilize a customized shell environment (often using chroot jails or restricted shells) to isolate users on shared clusters.

When you attempt an SSH handshake, the OpenSSH daemon (sshd) consults specific configuration files. However, before sshd even verifies your cryptography, the operating system checks the user's login capabilities.

On DreamHost, a user account can exist in three states:

  1. SFTP Only: Can transfer files but cannot execute shell commands.
  2. FTP Only: Legacy protocol, insecure, no shell.
  3. Shell Account: Full terminal access via SSH.

The Root Cause: By default, new users created in the DreamHost panel are often initialized as SFTP users. While an SFTP user can authenticate via password or key for file transfer, the SSH protocol will reject a standard interactive shell request, often masking the privilege rejection behind a generic publickey error.

Phase 1: Enabling Shell Access (The Control Panel Fix)

Before debugging client-side configurations, you must authorize the server to accept shell connections for your specific user.

  1. Log in to the DreamHost Control Panel.
  2. Navigate to Websites > FTP Users & Files.
  3. Locate the specific username you are attempting to connect with.
  4. Check the Type column.
    • If it says SFTP or FTP, this is the problem.
  5. Click Edit on the user row.
  6. Change the user type to Shell Account.
  7. Click Save Changes.

Critical Wait Time: This change is not instantaneous. It requires the DreamHost automation scripts to update /etc/passwd and shell configurations across the cluster. This usually takes 5 to 15 minutes. Do not attempt to debug further until this propagation period has passed.

Phase 2: Correct Key Implementation

If the user is set to "Shell Account" and you are still blocked, the issue moves to key management. While you can manually edit ~/.ssh/authorized_keys via FTP, DreamHost provides a synchronization tool that ensures keys persist across server migrations and cluster updates.

1. Generate a Modern Key Pair (Local Machine)

Avoid using legacy RSA keys shorter than 2048 bits or DSA keys. Use Ed25519, which is the current industry standard for performance and security.

Run this in your local terminal:

# Generate a new Ed25519 key pair
# -a 100: Runs 100 rounds of KDF (Key Derivation Function) for higher resistance to brute-force
# -t ed25519: Specifies the algorithm
# -f: Output file path
# -C: Comment for identification

ssh-keygen -t ed25519 -a 100 -f ~/.ssh/id_dreamhost_ed25519 -C "devops@projectname"

2. Import Public Key to DreamHost

  1. Copy the content of your public key to your clipboard:
    cat ~/.ssh/id_dreamhost_ed25519.pub
# Output example: ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAA... devops@projectname
  2. Return to the DreamHost Panel (FTP Users & Files).
  3. Click the Security tab (or "SSH Keys" in newer interfaces).
  4. Select Add Public Key.
  5. Paste your key string and name it.
  6. Assign the key: After adding, you must explicitly assign this key to the specific shell user you enabled in Phase 1.

Phase 3: Client-Side Configuration (The .ssh/config)

Managing multiple SSH keys (Github, AWS, DreamHost) relies on the ~/.ssh/config file. If you rely on the default id_rsa, your SSH client may offer the wrong key to the server multiple times, causing the server to ban you for too many authentication failures (Error: Too many authentication failures).

Create or edit your local config file:

nano ~/.ssh/config

Append the following configuration block. Replace variables with your actual credentials:

# DreamHost Production Environment
Host dh-prod
    HostName server_name.dreamhost.com
    User your_shell_username
    IdentityFile ~/.ssh/id_dreamhost_ed25519
    IdentitiesOnly yes
    Port 22

Why IdentitiesOnly yes matters: This directive forces SSH to use only the key specified in IdentityFile. It prevents the SSH agent from trying every key in your keyring, which significantly reduces handshake latency and prevents authentication lockouts.

Phase 4: Validating Server Permissions

If you have enabled shell access and synced your keys but still face rejection, you must verify the permission bits on the server side. Linux sshd is notoriously strict about file permissions; if the .ssh directory is writable by others, SSH will refuse to use it for security reasons.

Since you cannot SSH in, use an FTP client (like FileZilla) or the DreamHost WebFileManager to inspect the file attributes.

Required Permissions:

  1. Home Directory (~/): 755 (drwxr-xr-x) or 750. It cannot be 777.
  2. SSH Directory (~/.ssh): 700 (drwx------). This is critical. Only the owner should have read/write/execute access.
  3. Authorized Keys (~/.ssh/authorized_keys): 600 (-rw-------). Only the owner should have read/write access.

If these are incorrect, most FTP clients allow you to right-click and "Set Permissions" (chmod).

Advanced Debugging: The Verbose Flag

If you are still unable to connect, you need to see exactly where the handshake breaks. Run the SSH connection with the verbose -v flag (or -vvv for maximum debug info).

ssh -v dh-prod

Analyze the output for these specific lines:

  1. Connection established: debug1: Connection established. If this fails, a firewall or local network issue is blocking Port 22.

  2. Key Offer: debug1: Offering public key: /Users/me/.ssh/id_dreamhost_ed25519 ED25519 ... This confirms your local config is pointing to the correct private key.

  3. Server Acceptance: debug1: Server accepts key: ... If you see this, but still get dropped, the issue is likely a shell environment configuration (e.g., .bashrc or .bash_profile containing errors that crash the session immediately).

Common Pitfalls and Edge Cases

1. The "Known Hosts" Mismatch

If DreamHost migrates your account to a new cluster, the server's fingerprint may change. SSH will block the connection to prevent Man-In-The-Middle attacks.

Error: WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!

Fix: Remove the old fingerprint.

ssh-keygen -R server_name.dreamhost.com

2. Carriage Return Issues (Windows Users)

If you copied your public key from Windows to the server manually (not via the panel), you might have introduced Windows-style line endings (\r\n) into the authorized_keys file. Linux expects Unix-style line endings (\n).

Fix: Ensure your text editor is set to Unix/LF mode, or run dos2unix ~/.ssh/authorized_keys on the server if you have any other means of access.

3. Bash Profile Loops

Sometimes a connection works, but the session hangs or closes immediately. This often happens if you have added commands to .bash_profile or .bashrc that require interaction or are syntax-invalid.

Fix: Rename these files via FTP to .bash_profile.bak to test a login with a clean slate.

Conclusion

The "Permission denied (publickey)" error on DreamHost is rarely a mystery of cryptography; it is almost always a misalignment between the User Type settings in the dashboard and your local configuration.

By explicitly enabling Shell Access, utilizing modern Ed25519 keys, and enforcing IdentitiesOnly in your SSH config, you ensure a robust, secure, and persistent connection to your infrastructure.

Labels: