指南Guides · 2026-08-17

SSH 密钥入门：选 Ed25519 还是 RSA，以及私钥该怎么保管SSH Keys Explained: Ed25519 or RSA, and How to Keep the Private Half Safe

密钥登录比密码安全得多，但"公钥私钥"这套东西第一次接触时容易绕晕。这篇把它讲清楚，并给出手机上管理密钥的实际做法。

它是怎么工作的

一把 SSH 密钥其实是一对文件：

公钥（id_ed25519.pub）——可以公开，放到服务器的 ~/.ssh/authorized_keys 里。
私钥（id_ed25519）——绝不外传，留在你自己的设备上。

登录时服务器出一道只有持有私钥的人才能答对的题，客户端用私钥签名作答。私钥本身从不经过网络。这就是它比密码安全的根本原因——密码要发出去，私钥不用。

Ed25519 还是 RSA

	Ed25519	RSA
安全强度	≈ 3000 位 RSA	需 3072 位以上才够用
密钥长度	很短（一行）	长
签名速度	快	慢一些
兼容性	OpenSSH 6.5+（2014 年起）	无处不在

结论：新建密钥一律用 Ed25519。只有在对接特别老的设备（某些网络设备、老旧堡垒机）时才需要 RSA，且此时至少 3072 位——ssh-keygen -t rsa -b 4096。1024 位 RSA 早已不安全，2048 位也在逐步退役。

还会看到 ECDSA，它介于两者之间，但既没有 Ed25519 的简洁也没有 RSA 的兼容性，一般没有选它的理由。

生成与部署

在电脑上：

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

它会问你要不要设口令（passphrase）——设。这样即便私钥文件被人拿走，没有口令也用不了。

把公钥送到服务器，最省事的是：

ssh-copy-id user@server

没有这个命令就手动追加（注意是 >> 追加，不是 > 覆盖，否则会清掉已有的密钥）：

cat ~/.ssh/id_ed25519.pub | ssh user@server \
  "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

权限很关键：~/.ssh 要 700、authorized_keys 要 600。权限过松时 sshd 会直接拒绝使用该文件——这是"明明配好了却还是要密码"最常见的原因。

验证与收尾

先确认密钥能登录，再关闭密码登录，顺序别反了，否则容易把自己锁在外面。确认无误后在服务器上改 /etc/ssh/sshd_config：

PasswordAuthentication no

然后 systemctl reload sshd。建议保留一个已登录的会话，直到用新配置成功登录过一次。

私钥保管

一台设备一把钥匙。不要把同一把私钥拷到所有设备上——某台丢了，你只需在服务器上删掉对应的那一行公钥，而不是全部重来。
不要用聊天工具传私钥。需要在新设备上用，就在新设备上生成一把新的，把公钥加到服务器。
给私钥设口令。这是文件被拿走后的最后一道防线。
存在受保护的地方。手机上应存进系统钥匙串这类受设备解锁保护的存储，而不是普通文件。

手机上怎么管

最稳妥的做法是直接在手机上生成一把 Ed25519 密钥，然后把公钥复制出来贴进服务器的 authorized_keys。这样私钥从诞生起就没离开过这台设备，比"在电脑上生成再想办法传过去"少一整类风险。

Shellby 支持在设备上生成 Ed25519 密钥、导入已有私钥（OpenSSH / PEM / PKCS#8，含 Ed25519、RSA、ECDSA）、查看指纹与复制公钥；私钥写入系统钥匙串，不以明文形式留在配置里。要备份或换机时可以导出，但那是一份登录凭证——只在必要时导出，别发给任何人。

常见问题

配了密钥还是提示输密码？

九成是权限问题（见上）。其次检查公钥是不是完整一行、有没有被换行截断，以及是不是加到了目标用户的家目录下（root 和普通用户是两个 authorized_keys）。

一台服务器能放多把公钥吗？

能，authorized_keys 一行一把。团队协作和多设备就是这么做的，删除某台设备的访问权只需删掉对应那一行。

私钥丢了怎么办？

私钥无法找回，也没有"重置"一说。处理方式是用另一种方式登录服务器（控制台、其它设备），把对应的公钥行从 authorized_keys 删掉，再生成并部署一把新的。

Key auth is far safer than passwords, but the public/private pairing trips people up the first time. Here's the model, the choice of algorithm, and how to look after the private half — including on a phone.

How it works

An SSH key is a pair:

Public key (id_ed25519.pub) — safe to share; goes in the server's ~/.ssh/authorized_keys.
Private key (id_ed25519) — never leaves your device.

At login the server poses a challenge only the private key holder can answer, and the client signs it. The private key never crosses the network. That's precisely why it beats a password — a password has to be sent, a private key doesn't.

Ed25519 or RSA

	Ed25519	RSA
Strength	≈ 3000-bit RSA	Needs 3072-bit or more
Key size	Tiny (one line)	Long
Signing speed	Fast	Slower
Compatibility	OpenSSH 6.5+ (since 2014)	Everywhere

Use Ed25519 for anything new. Reach for RSA only when talking to genuinely old gear — and then at 3072 bits minimum: ssh-keygen -t rsa -b 4096. 1024-bit RSA has long been unsafe and 2048 is on the way out.

You'll also meet ECDSA. It sits between the two without Ed25519's simplicity or RSA's ubiquity — rarely a reason to choose it.

Generating and deploying

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

It asks for a passphrase — set one. If the key file is ever stolen, the passphrase is what stands between the thief and your servers.

Ship the public half with:

ssh-copy-id user@server

Without that command, append manually — note >> (append), not >, which would wipe existing keys:

cat ~/.ssh/id_ed25519.pub | ssh user@server \
  "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

Permissions matter: ~/.ssh must be 700 and authorized_keys 600. sshd refuses files that are too permissive — the single most common reason for “I set up the key and it still asks for a password”.

Verify, then lock down

Confirm the key logs you in before disabling passwords, not after — get that order wrong and you can lock yourself out. Then on the server, in /etc/ssh/sshd_config:

PasswordAuthentication no

followed by systemctl reload sshd. Keep one session open until you've logged in successfully under the new config.

Looking after the private key

One key per device. Don't copy the same private key everywhere — lose a device and you delete one line from authorized_keys instead of rotating everything.
Never send a private key over chat. Need access from a new device? Generate a key there and add its public half.
Always set a passphrase. It's the last line of defence if the file is taken.
Store it somewhere protected — on a phone, the system Keychain rather than a plain file.

Keys on a phone

The soundest approach is to generate the key on the phone and paste its public half into the server's authorized_keys. The private key then never leaves that device, which removes a whole category of risk compared with generating on a computer and finding a way to transfer it.

Shellby can generate Ed25519 keys on device, import existing ones (OpenSSH / PEM / PKCS#8 — Ed25519, RSA, ECDSA), show fingerprints and copy the public key. Private keys go into the system Keychain, never plaintext in config. You can export for backup or migration, but that file is a login credential — export only when you must, and send it to no one.

FAQ

Key is set up but it still asks for a password

Nine times out of ten it's permissions (above). Then check the public key is one unbroken line, and that it went into the right user's home — root and a normal user have separate authorized_keys.

Can one server hold several public keys?

Yes — one per line. That's how teams and multi-device setups work; revoking one device means deleting one line.

I lost my private key

It can't be recovered and there's no reset. Get in another way (cloud console, another device), remove that public key line from authorized_keys, then generate and deploy a new pair.