How to Connect to a Linux Server Securely Using SSH

Why SSH Matters for Your Linux Server

What SSH is in plain English

SSH, or Secure Shell, is a way to open a remote terminal on your server so you can type commands as if you were sitting in front of it. Everything sent between your computer and the server is encrypted, including:

• What you type, such as commands and passwords
• What the server sends back, such as logs and configuration files

This encryption helps prevent anyone on the network from reading or tampering with your session.

Older tools such as Telnet send information in plain text, which means anyone with access to the network path can see usernames, passwords and commands. SSH provides a secure replacement for these older, insecure methods.

Control panels such as cPanel or a VPS dashboard are helpful for many tasks, but they are not a full replacement for SSH. Some deeper server work, and most troubleshooting, is still easiest and most reliable from an SSH session.

When you will use SSH in real life

In practice, you will use SSH whenever you need direct control of a VPS or virtual dedicated server. Typical tasks include:

• Installing or updating software packages
• Restarting services such as Nginx, Apache, MySQL or PHP-FPM
• Checking system logs when something behaves unexpectedly
• Deploying or updating a WordPress or WooCommerce site
• Editing configuration files for performance or security tuning

If you use a hosting control panel (cPanel, Plesk, DirectAdmin and similar), SSH sits alongside it rather than replacing it. You might:

• Use the control panel for email, DNS and basic site management
• Use SSH for advanced configuration, diagnostics or automation scripts

For WordPress and WooCommerce, SSH lets you run WP-CLI, manage file permissions safely, and inspect logs that are not always accessible from the browser.

Security basics before you start

Any server on the public internet will attract automated connection attempts. Strong authentication is therefore essential, even for small personal projects.

SSH itself is designed to be secure, but only if it is configured sensibly. Password guessing bots, weak passwords, or shared logins can undermine its benefits. Using SSH keys, limiting who can log in, and keeping SSH updated are the foundations of a safe setup.

If you would prefer not to handle SSH security, user management and ongoing updates yourself, a managed virtual dedicated server can take care of these tasks for you so that you can focus on your websites and applications.

Information You Need From Your Hosting Provider

Before you open a terminal, it helps to collect a few details about your server. These are usually in your VPS or VDS welcome email or control panel.

• Server IP address or hostname
  The address you will connect to, for example 203.0.113.10 or server.example.com.
• SSH port
  By default this is port 22. If your provider uses a non standard port, note it carefully (for example 2222).
• Username
  Commonly root on unmanaged servers, or a regular user such as ubuntu, debian or a named account.
• Authentication method
  Usually an initial password, or an SSH key that has already been installed for you.

You can normally view or reset these details in your provider’s control panel if you misplace the original email.

Root user vs normal user

On Linux, the root user is the superuser. Root can:

• Install or remove any software
• Read and modify any file
• Change system wide settings for all users

This power is useful but also easy to misuse. A single mistaken command run as root can break services or delete important data.

A safer pattern is:

• Log in as a normal user
• Use sudo to run specific administrative commands when needed

For managing WordPress and most applications, a normal user with sudo access is usually sufficient. Reserving root for exceptional cases reduces the chance of accidental damage.

Step 1: Connecting with SSH from Windows, macOS and Linux

Using the built in SSH client (macOS and Linux)

On macOS and most Linux distributions, the SSH client is installed by default. You use it from the terminal.

The basic connection command is:

ssh username@server-ip

Here:

• ssh is the SSH client program
• username is your account on the server
• server-ip can be an IP address or a domain name

For example:

ssh alice@203.0.113.10

When you run this command for the first time, you will see a message about the server’s fingerprint. It will look similar to:

The authenticity of host '203.0.113.10 (203.0.113.10)' can't be established.
ED25519 key fingerprint is SHA256:examplefingerprint.
Are you sure you want to continue connecting (yes/no/[fingerprint])?

This fingerprint helps you verify that you are connecting to the correct server, not a different one pretending to be it. In practice, for test or new servers, many people accept it the first time. On important production systems, especially in regulated environments, it is good practice to confirm the fingerprint with your hosting provider before typing yes.

After you type yes and press Enter, your computer will remember this server fingerprint in a file called known_hosts.

If your SSH service listens on a non standard port (for example 2222), you specify it with -p:

ssh -p 2222 username@203.0.113.10

This uses exactly the same connection, just on a different port number.

Using SSH on Windows (PowerShell, Windows Terminal, or PuTTY)

Recent versions of Windows 10 and 11 include an SSH client. You can use it from PowerShell, Command Prompt, or Windows Terminal.

Open PowerShell and run:

ssh username@server-ip

The behaviour is the same as on macOS and Linux. You will see the first time fingerprint warning and then a password prompt or key based login.

If your version of Windows does not have the built in SSH client, or you prefer a graphical interface, PuTTY is a long established alternative. In PuTTY you typically set:

• Host Name (or IP address): your server’s hostname or IP
• Port: usually 22, or the custom port provided
• Connection type: SSH

Then click “Open” to start the session and log in when prompted.

First time login and basic prompts

When you log in with a password, SSH will ask for it like this:

alice@203.0.113.10's password:

As you type, nothing will appear on screen. This is normal and is done so that someone looking over your shoulder cannot see the length of your password. Type the password carefully and press Enter.

Once logged in, you will see a shell prompt, often similar to:

alice@server:~$

This usually means:

• alice is the current user
• server is the server’s hostname
• ~ is your home directory
• $ indicates a normal user. A # would indicate root

To log out, you can type:

exit

or simply close the terminal window. In either case, the SSH session ends on the server.

Safety notes for your first SSH session

In your first few sessions, it is wise to move slowly and avoid commands you do not fully understand yet. In particular:

• Avoid rm for now, especially with options like -r or -f
• Avoid shutdown, poweroff and reboot until you are comfortable with the correct procedures

There is a separate guide, Essential Linux Commands Every VPS Owner Should Know, which introduces safe, commonly used commands. When you are ready to restart your system, How to Reboot Linux Commands explains how to do this correctly.

Step 2: Set Up SSH Key Based Authentication

What SSH keys are and why they are safer than passwords

SSH keys use a pair of files to identify you:

• Private key: stays on your computer, protected and never shared
• Public key: safe to copy to servers that should trust your login

You can think of this as a matched lock and key. The server stores the public “lock” and your computer holds the private “key”. When you connect, the server proves it has the lock and your client proves it has the matching key, without sending the key itself.

Compared to passwords:

• SSH keys are far harder to guess or brute force
• You do not need to type your server password every time
• You can use different keys for different users or servers

For internet facing servers, keys are strongly recommended.

Generate an SSH key pair on your computer

On macOS and Linux, you generate a key with ssh-keygen. A good modern choice is Ed25519:

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

In this command:

• -t ed25519 selects the Ed25519 key type
• -C adds a label, often your email address, to help you recognise the key later

On older systems that do not support Ed25519, you can use a strong RSA key instead:

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

Here -b 4096 sets a 4096 bit key size, which is considered strong.

After running the command, you will see prompts such as:

Enter file in which to save the key (/home/you/.ssh/id_ed25519):

• Press Enter to accept the default path (recommended in most cases)

Next:

Enter passphrase (empty for no passphrase):
Enter same passphrase again:

This passphrase encrypts your private key on disk. It is a good idea to set one. You will then unlock the key with this passphrase when you use it. If you prefer convenience and are working on a trusted personal computer, you can leave it empty, but that is less secure.

Once complete, you will have two important files in ~/.ssh:

• id_ed25519 (or id_rsa): your private key. Keep this safe, do not email it or upload it.
• id_ed25519.pub (or id_rsa.pub): your public key. This is what you copy to servers.

Copy your public key to the server

The server needs to know your public key so it can recognise your login. The easiest way on macOS and Linux is ssh-copy-id.

From your local machine, run:

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

This will:

• Ask for your server password one last time
• Append your public key to ~/.ssh/authorized_keys on the server

If you receive an error that ssh-copy-id is not found, you can use a manual method.

Manual method if ssh-copy-id is not available

1. On your local computer, display your public key:

   cat ~/.ssh/id_ed25519.pub
   

   Select and copy the entire line that starts with ssh-ed25519 or ssh-rsa.

2. On the server, logged in as the target user, create the .ssh directory with correct permissions:

   mkdir -p ~/.ssh
   chmod 700 ~/.ssh
   nano ~/.ssh/authorized_keys
   chmod 600 ~/.ssh/authorized_keys
   

   The steps here are:

   • mkdir -p ~/.ssh creates the directory if it does not exist
   • chmod 700 ~/.ssh restricts access to you only
   • nano ~/.ssh/authorized_keys opens a simple text editor to create or edit the file
   • You paste your public key as a single line and save the file (in nano, Ctrl+O, Enter, then Ctrl+X)
   • chmod 600 ~/.ssh/authorized_keys restricts the file so only you can read or write it

SSH is strict about permissions. If the .ssh directory or authorized_keys file is too open, the server may ignore them to avoid security risks.

Test logging in using your SSH key

Now log out of the server:

exit

Then connect again from your local machine:

ssh username@server-ip

If everything is set up correctly, you should see one of two behaviours:

• You are logged in immediately without a password prompt
• You are asked for your key passphrase instead of the server account password

When you later change SSH configuration, it is sensible to keep one working SSH session open in the background. Use a second terminal window to test new settings so that if something is misconfigured, you still have access to revert the change.

Step 3: Harden Your SSH Configuration Safely

Locate and back up your SSH server configuration file

The SSH server settings live in /etc/ssh/sshd_config on most Linux distributions. Before changing it, create a backup so you can easily undo any mistake.

Run:

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.backup

This copies the current configuration file to sshd_config.backup. If anything goes wrong after your edits, you can restore this copy.

When working on SSH configuration, it is very important to keep at least one existing SSH session open. Test new connections in a second window. That way, if the new connection fails, you still have an open shell to fix the issue.

Disable password authentication once keys are working

Once you have confirmed that SSH keys work for all accounts that need access, you can disable password logins. This stops bots from guessing passwords entirely.

Open the SSH configuration file with a text editor such as nano:

sudo nano /etc/ssh/sshd_config

Look for existing lines related to password authentication. You may see lines starting with # which means they are commented out. Add or adjust the following lines so they appear exactly once and without a leading #:

PasswordAuthentication no
ChallengeResponseAuthentication no
UsePAM yes

In plain language, these settings mean:

• PasswordAuthentication no tells SSH not to accept normal passwords
• ChallengeResponseAuthentication no disables some alternative password like methods
• UsePAM yes keeps PAM enabled, which is typical and works well with key based setups

Important: Only do this once you have tested key based access for every account that needs SSH. If no working key is installed, and you restart SSH after making this change, you will lock yourself out.

Optional: change the SSH port and other sensible tweaks

Many automated bots target the default SSH port (22). Changing it will not make SSH unbreakable, but it can significantly reduce noise in your logs and the number of automated connection attempts.

In /etc/ssh/sshd_config, find the Port line. If it is commented out, it might look like #Port 22. You can change it to, for example:

Port 2222

Choose a port between 1024 and 65535 that is not already in use. After changing the port:

• Update any firewall rules to allow the new port and, if appropriate, remove or restrict port 22
• Update your SSH command to use the new port, for example:

ssh -p 2222 username@server-ip

Another useful setting is to prevent direct root logins and instead use sudo from a normal account. In sshd_config:

PermitRootLogin no

This means root cannot log in directly over SSH. You would instead log in as your normal user and run administrative commands with sudo.

These changes improve security in a straightforward way. Just be sure that you have at least one non root user with sudo access and working SSH keys before disabling root login.

Apply and test your SSH changes

After editing sshd_config, you need to tell the SSH service to reload its configuration. On systemd based distributions, you can usually use:

sudo systemctl reload sshd    # Common on CentOS, Rocky, AlmaLinux
sudo systemctl reload ssh     # Common on Ubuntu, Debian

Use the command that matches your distribution’s service name. If reload is not supported, you can use restart instead.

The difference is:

• reload applies configuration changes without dropping existing connections where possible
• restart stops and starts the service, which disconnects all sessions

Where available, reload is safer while you are testing changes because your current SSH session should survive.

After reloading, open a new terminal window and test logging in with your updated settings, including any new port number. Only close your original, known working session once you have confirmed that new logins work as intended.

If something goes wrong and you need to revert to the previous configuration, restore your backup:

sudo cp /etc/ssh/sshd_config.backup /etc/ssh/sshd_config
sudo systemctl restart sshd   # or 'ssh' on Ubuntu/Debian

This replaces your changed file with the original and restarts the service using the known good configuration.

Managing SSH Access for Multiple Users

Create separate users instead of sharing logins

When more than one person needs SSH access, it is better to give each person their own Linux user account rather than sharing a single login. This has several advantages:

• You can see which user ran which command in logs
• You can revoke access for one person without affecting others
• You avoid sharing passwords or private keys

To create a new user called alice and optionally give them sudo access, you might run:

sudo adduser alice
sudo usermod -aG sudo alice   # give sudo access if required

The first command creates the user and will prompt you to set a password for them. The second command adds them to the sudo group so they can perform administrative tasks with sudo. If you prefer not to grant admin rights, omit the second command.

For a deeper look at organising permissions with groups, see How to Add a User to a Linux Group and How to List Users on Linux.

Give each user their own SSH keys

Each person should generate their own SSH key pair on their personal computer, just as you did earlier, and then send you their public key only.

The process is:

1. User generates a key pair locally with ssh-keygen.
2. They send you the contents of their id_ed25519.pub (or id_rsa.pub) file.
3. You log in as their Linux user (or sudo su - username) and add the key to their ~/.ssh/authorized_keys.

This design has a useful benefit: if someone leaves the team or no longer needs access, you can remove their key from authorized_keys or disable their user account without changing anything for other users.

Common SSH Problems and How to Troubleshoot Them

Connection timed out or refused

Two common error messages when trying to connect are:

• Connection timed out: your computer tried to reach the server but did not get a response in time. This often indicates a network issue or a firewall blocking access.
• Connection refused: the server responded immediately that nothing is listening on that port. This often means the SSH service is not running on that port or is using a different one.

On the server, you can check whether the SSH service is running with:

sudo systemctl status ssh
sudo systemctl status sshd

One of these will typically report the status, for example:

● ssh.service - OpenBSD Secure Shell server
   Loaded: loaded (/lib/systemd/system/ssh.service; enabled)
   Active: active (running)

If it is not running, you can start it with sudo systemctl start ssh or sudo systemctl start sshd. If you cannot reach the server at all, use your hosting control panel’s console access to diagnose firewall rules or network settings.

Permission denied (publickey)

A “Permission denied (publickey)” message usually means the server did not accept any of the SSH keys your client offered.

Useful checks include:

• Is the public key in the correct user’s ~/.ssh/authorized_keys file?
• Are the permissions correct?
  • .ssh directory should be 700
  • authorized_keys should be 600
• Are you using the correct username and host in your SSH command?

To see more detail about what the SSH client is doing, add the -v flag:

ssh -v username@server-ip

This prints verbose output, including which keys are being tried and any error messages from the server. On stubborn issues, you can increase this further with -vv or -vvv, but start with -v as it is easier to read.

Accidental lockouts and when to get help

It is possible, especially when first learning, to lock yourself out of SSH. Common causes include:

• Disabling password authentication before confirming your keys work
• Misconfiguring sshd_config and restarting the service
• Changing the SSH port without updating firewall rules

Most VPS panels provide a web based console that connects directly to the virtual machine, bypassing the network firewall and SSH settings. This console is invaluable for recovering from lockouts. From there, you can restore sshd_config.backup, adjust firewall rules, or re enable password access temporarily while you fix key based logins.

If this is a production system or you run a busy WordPress or WooCommerce shop, you may prefer to have SSH security, firewall rules and monitoring handled for you. In that case, a managed virtual dedicated server can reduce the chance of extended downtime caused by configuration mistakes.

When It Makes Sense to Choose Managed Hosting Instead

Running an unmanaged VPS or virtual dedicated server involves several ongoing tasks related to SSH and overall system security:

• Setting up and rotating SSH keys for all users
• Creating and managing user accounts and groups
• Hardening SSH configuration and reviewing it after updates
• Applying operating system and OpenSSH security updates
• Monitoring logs for unusual login activity or repeated failures

If your main goal is to run one or two business websites rather than to administer Linux every week, it may be more practical to offload this to a managed platform.

• Managed WordPress hosting can look after the operating system, SSH access, firewalls and performance tuning, while you manage your WordPress content and plugins.
• For multi site setups, custom applications or ecommerce with stricter compliance needs, a managed solution on PCI conscious hosting or a managed virtual dedicated server gives you more control with expert help on the security side.

Managed services do not remove every responsibility, but they reduce the depth of Linux knowledge you need day to day and provide a safety net when something goes wrong.

Next Steps and Further Reading

Once you can connect to your server securely with SSH, the next step is to become comfortable inside the shell environment.

• Learn a set of safe, essential commands with Essential Linux Commands Every VPS Owner Should Know.
• Explore secure file transfers using SSH in SCP Command Examples.
• Practice using simple monitoring tools such as nload to understand your server’s network usage.
• Read about safe restart procedures in How to Reboot Linux Commands so you know how to recover cleanly after updates.

Whatever stack you use, regular backups are important. For WordPress in particular, keep both:

• Server level backups or snapshots from your hosting provider
• Application level backups of the database and wp-content directory

This way, if a configuration mistake over SSH affects your site, you have a straightforward route to recovery.

If you find yourself spending more time on server administration than on your actual projects, it may be worth exploring managed virtual dedicated servers or Managed WordPress hosting so that SSH security, updates and monitoring are handled for you while you focus on your websites.