SSH Keys and SFTP: Server Access Done Right

Servers exposed to the internet can receive automated login attempts from bots testing common usernames and passwords. Weak, reused or compromised credentials increase the risk of unauthorized access.

SSH key authentication provides a stronger alternative to password-based SSH logins. Instead of relying solely on a password, the server verifies that the connecting user possesses the private key corresponding to a public key authorized on the server.

For developers, system administrators and hosting customers, combining SSH keys with secure file transfer, individual user accounts and regular access reviews creates a more controlled way to manage servers.

1. Generate an SSH Key Pair on Your Computer

An SSH key pair consists of two files:

• Private key: Kept securely on your own computer. Never share it or upload it to a server.

• Public key: Installed on the server to authorize access.

For most modern OpenSSH setups, Ed25519 is a good default choice.

On Linux, macOS or Windows with OpenSSH installed, open a terminal and run:

ssh-keygen -t ed25519 -C "your-name@yourcompany.com"

Follow the prompts to choose where to save the key. Set a strong passphrase to protect the private key if the file is copied or stolen.

By default, the key files are typically stored in the .ssh directory within your home directory. The private key commonly has no file extension, while the public key ends in .pub.

Important: Never send your private key to a hosting provider, contractor or developer. Only the public key should be installed on the server.

2. Install the Public Key on the Server

Your public key must be added to the authorized_keys file for the Linux user who needs access.

If password-based SSH access is currently enabled, you can often install the public key using:

ssh-copy-id -i ~/.ssh/id_ed25519.pub username@server-address

Replace username with your server account and server-address with the server's hostname or IP address.

If ssh-copy-id is unavailable, you may need to add the public key manually through an existing authenticated session or your hosting provider's console. Ensure the .ssh directory and authorized_keys file have appropriate ownership and permissions.

Typical permissions are:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Run these commands as the relevant server user, adjusting ownership where necessary.

3. Test Key Authentication Before Disabling Passwords

Do not disable password authentication immediately after adding a key. First, verify that the new method works.

Open a second terminal and connect using the key:

ssh -i ~/.ssh/id_ed25519 username@server-address

Confirm that the connection succeeds and that you can perform the tasks required for that account.

Keep your original session open while testing. If the new login fails, you can use the existing session to troubleshoot rather than risking being locked out.

Check the SSH server logs if authentication fails. Common causes include an incorrect username, the wrong key, invalid file permissions or a server configuration that does not permit public-key authentication.

4. Disable Password Authentication and Direct Root Login

Once key authentication has been tested successfully, review the SSH server configuration. On many Linux systems, the main file is:

/etc/ssh/sshd_config

The relevant settings commonly look like this:

PubkeyAuthentication yes
PasswordAuthentication no
PermitRootLogin no

These settings must be compatible with your server's existing configuration and any included configuration files. Some systems use additional files under /etc/ssh/sshd_config.d/.

Before applying changes:

1. Confirm that you have a working administrative account with sudo privileges.

2. Check the configuration syntax using the appropriate SSH daemon validation command, commonly sshd -t.

3. Reload or restart the SSH service using the command appropriate for your operating system.

4. Test a new connection from another terminal before closing your existing session.

5. Verify that password authentication and direct root login are disabled as intended.

The exact service name and reload command can differ between Linux distributions.

Do not make these changes without an alternative recovery route. If your key, account or configuration is incorrect, you could lose remote access. Keep access to your hosting control panel, cloud console or another approved recovery method.

5. Use SFTP for Secure File Transfers

SFTP, or SSH File Transfer Protocol, transfers files over an SSH connection. It encrypts the connection and can use the same SSH key authentication configured for server access.

Unlike plain FTP, SFTP does not send the session over an unencrypted connection.

Connect using the command line:

sftp -i ~/.ssh/id_ed25519 username@server-address

Once connected, common commands include:

CommandPurposelsList files on the remote server.pwdDisplay the current remote directory.cd directoryChange the remote directory.put file.txtUpload a local file.get file.txtDownload a remote file.byeEnd the SFTP session.

Graphical SFTP clients can also be useful for developers who prefer dragging and dropping files. Configure the client to use SFTP and the appropriate private key rather than falling back to plain FTP.

6. Give Each Developer Their Own Account

Sharing a single server login among employees or contractors makes it harder to track access and remove permissions when someone leaves.

Instead, create a separate user for each person who needs access. Assign only the permissions required for their work.

For example:

• A developer working on one website should not automatically have access to unrelated client files.

• A contractor who only needs to upload website files should not receive unrestricted administrative privileges.

• A system administrator may need sudo access, but that access should be granted deliberately and reviewed periodically.

Where supported, configure SFTP-only users with restricted directory access, such as a suitable chroot environment. Test the configuration carefully: directory scoping, filesystem permissions and application requirements must all work together.

SteboHost's developer hosting setup is relevant for teams looking for developer-focused hosting and controlled access to project files. Confirm the available user-management and directory-restriction features for your chosen plan.

7. Remove Access When a Project Ends

Access management does not end when the initial setup is complete. Contractors change, employees leave and temporary projects finish.

When someone's access is no longer needed:

1. Remove their public key from the appropriate authorized_keys file, or disable their individual account.

2. Revoke any associated credentials or permissions they no longer require.

3. Review shared deployment credentials, API tokens and other secrets they may have accessed.

4. Confirm that their account can no longer access the relevant systems.

5. Record the change if your organization maintains an access log.

Removing one public key is straightforward when every user has a separate account. If several people share an account or key, identifying and removing the correct access becomes more difficult.

8. Protect and Review SSH Keys Regularly

A passphrase helps protect a private key if someone obtains the file, but it does not replace device security or access controls.

Follow these practices:

• Use a strong passphrase and secure your computer with a screen lock and disk encryption.

• Keep private keys out of source-code repositories, shared folders and public cloud storage.

• Use separate keys for different users or purposes where practical.

• Remove old keys that no longer have a valid owner or business purpose.

• Rotate keys when a device is lost, a key may be compromised or an access policy requires it.

• Review authorized users and administrative privileges periodically.

• Consider an SSH agent or hardware-backed key where appropriate, while protecting access to the agent or device.

Key rotation should include installing and testing the replacement key before removing the old one, unless a suspected compromise requires immediate revocation.

SSH Security Checklist

Use this checklist when hardening a new server or reviewing an existing one.

• Generate a modern SSH key pair on a trusted computer.

• Protect the private key with a passphrase.

• Install only the public key on the server.

• Test a new key-based connection before changing SSH settings.

• Confirm that a named user has the required administrative permissions.

• Disable password authentication only after verifying key access.

• Disable direct root login where appropriate.

• Use SFTP instead of unencrypted FTP for file transfers.

• Create individual accounts for developers and contractors.

• Restrict access to the files and commands each user needs.

• Keep a recovery method available.

• Review keys and accounts when people join, leave or change roles.

Frequently Asked Questions

Are SSH keys safer than passwords?

SSH keys can significantly reduce the risk of password guessing and credential reuse when configured correctly. A protected private key is difficult to guess, but stolen keys, compromised devices and misconfigured permissions can still create security risks.

What is the difference between SSH and SFTP?

SSH provides an encrypted connection for remote access and other secure operations. SFTP is a file-transfer protocol that operates over SSH, allowing users to upload, download and manage files securely.

Can I use the same SSH key for multiple servers?

Technically, yes. However, separate keys for different environments, devices or purposes can make access management and revocation easier. Follow your organization's security policy.

What happens if I lose my private key?

You cannot recreate the original private key from the public key. If you still have authorized access through another method, generate a new key pair, install its public key and remove the old public key. If the lost key may have been stolen, revoke it promptly and review access logs.

Should I disable SSH password authentication?

For a server intended to use key-based SSH authentication, disabling password authentication can reduce exposure to password-guessing attacks. First confirm that the required accounts can log in with keys and that you have a reliable recovery method. Some environments require different authentication policies, so review the server's operational needs before changing settings.

Secure Server Access Starts with Good Habits

SSH keys, SFTP, individual accounts and regular access reviews provide a practical foundation for safer server administration. The important part is not simply enabling key authentication; it is managing the entire lifecycle of access, from creating credentials to removing them when they are no longer needed.

If you are setting up an environment for application development, deployment or website management, explore SteboHost developer hosting to review the hosting options available for your workflow.