Connect to your server with SSH

SSH keys are safer than passwords and quicker to use. This guide sets them up on your workstation, copies them to your FlexDedi server, then turns off password logins without locking you out.

You need the server's IPv4 address and root password, both shown with your server in the control panel. Examples use 203.0.113.10; replace it with your address.

Before you start

OpenSSH is preinstalled on Linux, macOS, Windows 10 and 11, and Windows Server 2019 and later. On Windows, run ssh -V in PowerShell to check. If the command is missing, install the client from an elevated PowerShell:

Add-WindowsCapability -Online -Name OpenSSH.Client~~~~0.0.1.0

1. Create a key pair

The command is the same in a Linux or macOS terminal and in Windows PowerShell:

ssh-keygen -t ed25519 -C "alice@laptop"

Accept the default location and set a passphrase. The private key (id_ed25519) stays on your workstation, in ~/.ssh on Linux and macOS or C:\Users\alice\.ssh on Windows. Only the public key (id_ed25519.pub) goes on servers.

2. Copy the public key to the server

On Linux and macOS, ssh-copy-id asks for the root password one last time and appends the key with the right permissions:

ssh-copy-id -i ~/.ssh/id_ed25519.pub root@203.0.113.10

Windows has no ssh-copy-id, so pipe the key over SSH instead:

Get-Content $env:USERPROFILE\.ssh\id_ed25519.pub | ssh root@203.0.113.10 "umask 077; mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"

Then confirm that the key works. You should get a shell without a password prompt:

ssh -i ~/.ssh/id_ed25519 root@203.0.113.10

3. Load the key into an agent

An agent remembers the unlocked key, so you type the passphrase once per session. On Linux, run ssh-add ~/.ssh/id_ed25519. On macOS, ssh-add --apple-use-keychain ~/.ssh/id_ed25519 also stores the passphrase in your keychain.

On Windows, enable the agent service once from an elevated PowerShell, then add the key:

Get-Service ssh-agent | Set-Service -StartupType Automatic
Start-Service ssh-agent
ssh-add $env:USERPROFILE\.ssh\id_ed25519

4. Save the server in ~/.ssh/config

A host entry replaces long command lines with a short name. Add this to ~/.ssh/config (on Windows, C:\Users\alice\.ssh\config, same syntax):

Host fd-db1
    HostName 203.0.113.10
    User root
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes
    ServerAliveInterval 30

Now ssh fd-db1 connects, and the name works with scp and rsync too, as in rsync -a ./site/ fd-db1:/srv/site/. IdentitiesOnly yes stops the client from offering every key in your agent, which otherwise can end in "Too many authentication failures".

5. Disable password logins safely

Password logins invite brute-force attempts. Turn them off once key login works, in this order.

Step 1. Keep your current SSH session open, and confirm key login from a second terminal.

Step 2. Create a drop-in file that allows keys only:

cat > /etc/ssh/sshd_config.d/00-keys-only.conf <<'EOF'
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin prohibit-password
EOF

The 00- prefix matters. On Ubuntu, Debian, AlmaLinux and Rocky Linux, the Include line for this directory sits at the top of /etc/ssh/sshd_config, and sshd keeps the first value it reads for each setting. Files read earlier win, including over a 50-cloud-init.conf that enables passwords.

Step 3. Validate the configuration and print the settings sshd will actually use:

sshd -t && sshd -T | grep -Ei '^(passwordauthentication|kbdinteractiveauthentication|permitrootlogin)'

Expect no, no and without-password, an older name for prohibit-password.

Step 4. Restart the service. Open sessions stay connected:

# Ubuntu and Debian
systemctl restart ssh

# AlmaLinux and Rocky Linux
systemctl restart sshd

Step 5. From your workstation, check that passwords are now refused:

ssh -o PubkeyAuthentication=no -o PreferredAuthentications=password root@203.0.113.10

The expected answer is Permission denied (publickey). Keep a strong root password set anyway: it still works at the KVM console, which does not go through SSH, and that is your way back in.

6. Recover access through the KVM console

A lost key, a firewall rule that blocks port 22, a ban from fail2ban or a broken sshd file can all lock you out. The KVM console reaches the server's screen and keyboard directly, without the network or SSH.

1. In the control panel, open your server and launch the KVM console.
2. Log in as root with your password.
3. Find the cause:

sshd -t                                   # syntax errors in the configuration
journalctl -u ssh -n 50 --no-pager        # use -u sshd on AlmaLinux and Rocky Linux
chmod 700 /root/.ssh && chmod 600 /root/.ssh/authorized_keys
ufw status verbose                        # or: nft list ruleset
fail2ban-client set sshd unbanip 198.51.100.7   # your workstation's IP, if banned

To install a new key, the simplest path is to set PasswordAuthentication yes in your drop-in file, restart SSH, run ssh-copy-id from your workstation, then set it back to no.

If you no longer know the root password either, boot the rescue system and add a key or reset the password from there, as described in Reinstall the OS or boot rescue mode. The console itself is covered in Use IPMI and the HTML5 KVM console.

Host key warnings after a reinstall

A reinstall generates new host keys, so your client warns that the remote host identification has changed. If you just reinstalled, remove the old entry and reconnect:

ssh-keygen -R 203.0.113.10

If you did not reinstall, do not bypass the warning. Check the fingerprint through the KVM console first, as shown in Getting started.