无认证使用ssh-copy-id的Linux服务器机制及安全风险咨询

Great question—let’s unpack this clearly, since it ties directly to how SSH authentication works and the security risks involved.

First: When does ssh-copy-id work without authentication? #

ssh-copy-id’s core job is to connect to your server over SSH, then append your local public key to the target user’s ~/.ssh/authorized_keys file. For this to happen without you entering a password or providing a private key, one of these scenarios is almost always at play:

• Empty user password + enabled password authentication: If the target user on the server has an empty password, and SSHd is configured with PasswordAuthentication yes (the default in some older distros), anyone can SSH into that user account without credentials. ssh-copy-id just leverages this open access to add the public key.
• Host-based authentication is enabled: Some servers use host-based auth, where trusted client hosts are listed in /etc/ssh/shosts.equiv or the user’s ~/.shosts. If your client machine is in that trusted list, SSH lets you log in automatically, so ssh-copy-id works seamlessly without a prompt.
• You already have an authorized key: Maybe you forgot that you (or someone else) already added a public key for your client to the server’s authorized_keys. In this case, ssh-copy-id uses your existing valid key to authenticate, so you don’t need to enter a password again.
• Alternative ticket-based auth (like Kerberos): If the server uses a system like Kerberos, and you already have a valid authentication ticket on your client, SSH will use that for access—no password prompt needed.

Second: Does this expose the server to malicious file uploads? #

Short answer: It depends on why ssh-copy-id is working without authentication, but in the riskiest scenarios, yes—this is a critical security issue.

• Empty password + open password auth: This is the most dangerous case. If anyone can SSH into the user account without a password, they aren’t limited to just adding a public key. They can upload any malicious file (scripts, malware, backdoors), modify existing system files, run arbitrary commands, or even escalate privileges if the user has sudo access. ssh-copy-id is just one tool they could use—full shell access is already wide open to them.
• Host-based auth risks: If your trusted host list is misconfigured (e.g., includes a broad range of unvetted IPs or a compromised machine), an attacker could use that trusted host to gain access. Again, they’d have full shell access, not just the ability to add keys.
• Existing authorized key: This is safe—only the person holding the matching private key can authenticate. They’re already a trusted user, so adding another public key (or uploading files) is intended behavior.

Quick security fixes to mitigate risks #

If you’re seeing this happen unexpectedly, lock down your server right away:

• Set a strong, unique password for every user account (never leave an empty password).
• Edit /etc/ssh/sshd_config to set PasswordAuthentication no (use key-based auth exclusively).
• If you rely on host-based auth, restrict the trusted hosts to only machines you fully control, and keep shosts.equiv/.shosts permissions tight (chmod 600 for user-specific files, chmod 644 for system files).
• Limit SSH access to specific users or IP ranges with AllowUsers or AllowGroups in sshd_config.

内容的提问来源于stack exchange，提问作者Prem