Secure Access to a Linux VDS with an SSH Key

For secure administrative access to a Linux VDS, the most practical approach is to create an SSH key on your local computer and register only the public key on the server. Keep your existing administrative session and the provider’s console access available first; do not disable password login until you have verified the new-key connection in a separate session. This prevents an incorrect setting from causing you to lose management access to the server entirely.

Linux VDS preparation and required access

This procedure is intended for a Linux VDS environment where you can manage the server operating system and SSH service. With shared hosting panels, you generally cannot access system SSH settings; in that case, use the user account or supported key-upload screen provided by the hosting provider. You need an administrative account or an account with sudo privileges, the server’s public IP address, and an SSH client on your own computer.

Before making changes, check that the web console in the provider panel is working. Note the current SSH configuration file and the username you will change; if possible, take an appropriate backup, such as a VDS snapshot or the provider’s restore option. Do not change the port, firewall, and password settings at the same time. If a connection problem occurs, you can then identify which change caused it.

Creating an SSH key and separating the public key

Create a key pair on your local computer. The command in this example uses the Ed25519 format, which is common in modern SSH clients:

ssh-keygen -t ed25519 -C "linux-vds-erisim"

Of the two parts created by the command, the public key is usually the file with the .pub extension; only the contents of this file are transferred to the server. The file without an extension is the private key and must not be shared or placed in a public repository. Setting a passphrase for the private key during creation provides additional protection if the file is compromised on the local device.

Suppose you created the key on your laptop and your VDS provider allows you to paste a key through its panel. Add only the one-line public-key content to the panel field; do not change the key type at the beginning of the line or the comment at the end. If the panel does not provide this feature, use the existing administrative session to add the public key to the target user’s SSH keys file. Keep ownership and access permissions for the user’s home directory and SSH directory consistent with the distribution defaults; do not assign arbitrarily broad permissions.

Verifying the Linux VDS connection without disabling password login

First, open a new terminal window and try to connect using the key with the same user, IP address, and SSH port. In the successful session, check these three results: that you logged in as the correct user, that the expected hostname or IP address is shown, and, if an administrative operation is required, that the account actually has the necessary sudo privileges. Do not close the old SSH session during this process.

If the connection cannot be established, the type of error determines the next step. If the client indicates that it did not offer the key, check that the local SSH client is using the correct private-key file and that the file is readable. If the key was offered but the server rejected it, check that the key is present in the target user’s key file in full, that the file belongs to the correct user, and that the SSH service accepts that user. If the server cannot be reached at all, inspect the IP address, port, and provider firewall rules instead of changing the key settings; these are separate issues.

Matching a specific error finding with the correct fix

For example, suppose a new connection attempt shows that the client sent the key, but the server denied access, and the server authentication log states that the public-key file could not be read. In that case, you need to correct the ownership or file-access values in the target user’s SSH directory. This finding is not a reason to change the port or weaken the password policy. First note the existing values, correct the ownership of only the relevant file or directory, and do not touch any other setting.

Changing password login in a controlled manner

Once you are certain that you can log in with the new key, evaluate password-login behavior in the SSH service configuration according to your organization’s access policy and the status of the account you use. It is generally safer to first confirm that key access works with a separate sudo user rather than with an administrative account. Direct root login or password login should not be disabled before verifying the provider’s recovery console and an alternative administrative account.

1. Record the relevant authentication lines and their current values in the configuration file; change only the intended password setting.
2. Validate the SSH service configuration using the panel or management tool supported by your distribution. If it reports an error, do not reload the service; correct the syntax error first and retain the previous value.
3. If the change is accepted, keep the current session open and establish the SSH key connection again with the same user in a new terminal. This is a test that can be compared with the attempt made before the change.
4. Note the time of the new session and look for a successful key-based login at the same time in the server’s SSH authentication log. A successful record confirms only that the correct account connected; application permissions may need to be tested separately.

If the key connection still does not work after the change, restore the previous password setting from the existing console or open SSH session, validate the configuration safely, and repeat the same SSH operation. Inspect the new time-stamped log entry during the new attempt; do not treat older records as evidence of the new result. If the provider console is also unavailable, use the provider’s recovery procedure instead of increasing the risk of being locked out by making further configuration changes.

Acceptance criteria for initial use

Once setup is complete, an acceptable result is that the local client with a passphrase-protected key file connects to the expected user account, privileged operations are performed with sudo only when necessary, and an incorrect key is not accepted by the server. If these tests fail, the problem is most often that the key was added to the wrong user, file ownership is incorrect, the client selected the wrong key, or network access is unavailable; address these possibilities one at a time.

If you have not yet chosen a VDS, you can use the Turkey VDS server plans page only to review options while comparing operating systems and access methods. After selecting a plan, the first secure step is to verify the recovery console and test the SSH key without disabling password login.