# 🔒 The Safer Way to Set Up SSH Keys

**URL:** <https://onehack.st/t/the-safer-way-to-set-up-ssh-keys/325180>\
**Category:** Tutorials & Methods\
**Tags:** networking, tips-tricks, self-hosted-tools\
**Created:** [August 31, 2026, 8:27am UTC](https://onehack.st/t/the-safer-way-to-set-up-ssh-keys/325180 "2026-08-31T08:27:38Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![BCBC](https://onehack.st/user_avatar/onehack.st/bcbc/32/174133_2.png) [@BCBC](https://onehack.st/u/BCBC)\
**Post date:** [August 31, 2026, 8:27am UTC](https://onehack.st/t/the-safer-way-to-set-up-ssh-keys/325180/1 "2026-08-31T08:27:39Z")

</div>

## 🔑 ED25519 key auth, verified explicitly AND normally before you touch password login — so a bad config can’t lock you out

Most SSH-key tutorials tell you to disable password login the second you set up a key. That’s exactly how people lock themselves out of their own server. This is the safer order: **set up the key, verify it actually works, THEN think about disabling the password fallback — not before.**

```plaintext
LOCAL WORKSTATION
       │
       │ ED25519 private key (never leaves this machine)
       ▼
SSH CONNECTION
       │
       │ matching public key only
       ▼
REMOTE SERVER

```

## 1️⃣ Check for an existing key

```bash
ls -l ~/.ssh/id_ed25519 ~/.ssh/id_ed25519.pub 2>/dev/null

```

Nothing there? Make one:

```bash
ssh-keygen -t ed25519 -C "workstation-to-server"

```

⚠ **`id_ed25519`** (no `.pub`) is your **private key** — never email it, paste it anywhere, put it in GitHub, put it in a zip, or send it to an AI chat. Only **`id_ed25519.pub`** ever leaves your machine.

## 2️⃣ Copy the public key to the server

```bash
ssh-copy-id -i ~/.ssh/id_ed25519.pub root@SERVER_FQDN

```

You’ll type your password one last time here, while the key gets installed.

## 3️⃣ Verify it explicitly, then verify it normally

```bash
ssh -i ~/.ssh/id_ed25519 root@SERVER_FQDN 'hostname' # explicit key test
ssh root@SERVER_FQDN 'hostname' # does it pick the key automatically?

```

If both return your hostname with **no password prompt** , key auth is working — for real, not just “should be working.”

```plaintext
BEFORE AFTER
ssh ssh
 ↓ ↓
password prompt client offers private key
 ↓ ↓
type password server verifies public key
 ↓ ↓
login login

```

## 🟢 Keep the password fallback — on purpose

You do **not** have to disable password login just because keys work. Keep both until you’ve tested from every machine you actually depend on. **There’s no prize for locking yourself out of your own server.**

## 🎁 Bonus: name your server so you stop typing the FQDN

```bash
nano ~/.ssh/config

```

```plaintext
Host myserver
    HostName server.example.com
    User root
    IdentityFile ~/.ssh/id_ed25519

```

```bash
chmod 600 ~/.ssh/config

```

Now `ssh myserver` is the whole command.

## 🔍 Checking your work

```bash
ssh -v root@SERVER_FQDN # see which identity it's trying
ls -la ~/.ssh/ # what keys exist
chmod 600 ~/.ssh/id_ed25519 # private key: owner-only
chmod 644 ~/.ssh/id_ed25519.pub # public key: fine to be readable

```

## ⚡ Full quick version

```bash
ls -l ~/.ssh/id_ed25519 ~/.ssh/id_ed25519.pub 2>/dev/null || \
ssh-keygen -t ed25519 -C "workstation-to-server"

ssh-copy-id -i ~/.ssh/id_ed25519.pub root@SERVER_FQDN
ssh -i ~/.ssh/id_ed25519 root@SERVER_FQDN 'hostname'
ssh root@SERVER_FQDN 'hostname'

```

Last command returns your hostname, no password asked? Done.

## 💭 Why ED25519 specifically

Small keys, fast, strong modern crypto, supported on every current Linux distro. It’s just the sane default now:

```bash
ssh-keygen -t ed25519

```