Connecting Your PC to JumpServer and TargetServer: First Steps with SSH Key and Password Authentication Skipped

To connect your PC to JumpServer and TargetServer securely, you must generate an SSH key pair on your local machine and add the public key to both servers. This process disables password authentication by default in many configurations, requiring you to use the private key for all subsequent login attempts. Follow these steps to establish a secure, passwordless connection.

Understanding the Authentication Shift

The primary goal of this configuration is to enhance security by eliminating password-based logins, which are vulnerable to brute-force attacks. When you configure SSH keys, the server verifies your identity using cryptographic proof rather than a shared secret string. JumpServer acts as the bastion host or jump box, meaning your traffic from your PC routes through it before reaching the TargetServer. This adds a layer of network isolation but also means you need valid credentials (the private key) for both endpoints. If you previously relied on passwords, skipping this step will result in immediate access denied errors. It is crucial to understand that the private key never leaves your PC, while the public key resides on the servers.

Generating the SSH Key Pair

Before attempting any connections, you need a unique key pair on your local machine. Open your terminal or command prompt and run the following command:

ssh-keygen -t ed25519 -C "[email protected]"

Using ed25519 is recommended over RSA because it is faster and more secure for modern systems. The tool will ask for a file location; pressing Enter accepts the default path (~/.ssh/id_ed25519). You will then be prompted for a passphrase. While optional, adding a strong passphrase encrypts the private key on disk, providing defense-in-depth if the file is stolen. After generation, verify that two files exist in your .ssh directory: id_ed25519 (private) and id_ed25519.pub (public). Never share the private key with anyone or upload it to untrusted repositories. For reference on handling key permissions and troubleshooting related issues, see our guide on Troubleshooting SSH with Private Key.

Adding the Public Key to JumpServer

JumpServer requires the public key to authenticate your user account. Log into the JumpServer web interface and navigate to your user profile settings. Look for the section labeled "SSH Keys" or "Public Keys." Copy the entire content of your id_ed25519.pub file, which starts with ssh-ed25519, and paste it into the input field. Save the changes. Alternatively, if you have command-line access to JumpServer via another method, you can append the public key to the ~/.ssh/authorized_keys file of your specific user account on the JumpServer host. Ensure the permissions on the .ssh directory are set to 700 and the authorized_keys file is 600.

Configuring TargetServer Access

Once JumpServer trusts your key, you must do the same for the TargetServer. Since you cannot log in directly with a password anymore, you might need to use a temporary password if one is still enabled, or use a different out-of-band method provided by your system administrator. Add the same public key to the ~/.ssh/authorized_keys file on the TargetServer. If you are managing multiple servers, consider using an SSH config file to streamline connections. Create or edit ~/.ssh/config on your PC:

Host jumpserver
    HostName 
    User 
    IdentityFile ~/.ssh/id_ed25519

Host targetserver
    HostName 
    User 
    ProxyJump jumpserver
    IdentityFile ~/.ssh/id_ed25519

The ProxyJump directive tells SSH to automatically route the connection to targetserver through jumpserver. This simplifies the workflow, allowing you to type ssh targetserver instead of manually chaining sessions. If you encounter resolution issues during this setup, check our article on SSH: Temporary Name Resolution Failure for 'desktop11900' for common DNS pitfalls.

Testing the Connection

Verify the setup by initiating a connection from your PC to JumpServer first. Run:

ssh jumpserver

If configured correctly, you should be logged in without a password prompt. Next, test the proxy connection to the TargetServer:

ssh targetserver

You should now be inside the TargetServer environment. If you receive a permission denied error, check that the private key file has correct read-only permissions for the owner (chmod 400). Also, ensure that password authentication is disabled on the servers only after you have confirmed key-based access works reliably. Disabling it prematurely can lock you out. For further details on connecting to cloud instances with similar constraints, refer to Connecting to an EC2 instance using SSH with password authentication - Ubuntu 22.04.

Troubleshooting Common Issues

If the connection fails, enable verbose mode to see detailed logs:

ssh -v targetserver

Look for lines indicating "Offering public key" and whether the server accepts it. A common mistake is having incorrect ownership of the .ssh directory, which causes SSH to ignore the key for security reasons. Another issue is the server rejecting the key due to strict host key checking if the server was reinstalled. In such cases, remove the old entry from ~/.ssh/known_hosts. Always back up your private key securely, as losing it may require administrative intervention to reset access.

Frequently Asked Questions

Can I keep password authentication enabled alongside SSH keys?

Yes, you can leave password authentication enabled as a fallback, but it is strongly discouraged for security reasons. Most organizations enforce policies that disable password logins once keys are established to prevent brute-force attacks. If you must keep it, ensure you use strong, unique passwords until you switch entirely to keys.

What happens if I lose my private key?

If you lose your private key, you will be locked out of the servers unless you have another authentication method or physical console access. You must regenerate a new key pair and update the public keys on JumpServer and TargetServer. Always store backups of your private key in a secure, encrypted location.

Why does SSH still ask for a passphrase even though I set up a key?

This occurs if you added a passphrase when generating the key. The private key is encrypted on your disk, so you must enter the passphrase to decrypt it before SSH can use it. If you did not want a passphrase, you would need to regenerate the key without one, though this reduces security slightly.

How do I fix "Permission Denied (publickey)" errors?

This error usually means the server does not recognize your public key or the client is not offering it. Verify that the public key is correctly appended to ~/.ssh/authorized_keys on the server side. On the client side, ensure the private key file permissions are set to 600 and that the key matches the one on the server.

Is ProxyJump supported on older versions of SSH?

No, the ProxyJump directive was introduced in OpenSSH 7.3. If you are using an older version, you must manually chain connections by logging into the jump server first and then executing SSH from there. Consider upgrading your local SSH client to take advantage of simplified multi-hop configurations.