Multiple Ways and Tips for SSH Passwordless Login Between Linux Servers

In Linux server management, achieving passwordless login cangreatly improve work efficiency, reducing the hassle of frequently entering passwords. However, in practical operations, we may encounter various restrictions, such asnot knowing the root user password,being unable to use<span>ssh-copy-id</span> command,SSH service running on a non-default port, etc. This article will detail how to achieve passwordless login between Linux servers under these restrictions and share some tips!🚀

1. 🔑 Generate SSH Key Pair

First, we need to generate a pair of SSH keys (public key and private key) onServer A. This can be done using the<span>ssh-keygen</span> command:

ssh-keygen -t rsa -b 2048

After executing the above command, the system will prompt you to enter the location to save the key (default is<span>~/.ssh/id_rsa</span>), as well as whether to set a password to protect the private key. To simplify operations, you can choose not to set a password here (but it is recommended to set a password in production environments!🔐).

Once generated, you will see two files in the<span>~/.ssh</span> directory:

• <span>id_rsa</span> (private key, equivalent to yourdigital ID)

• <span>id_rsa.pub</span> (public key, equivalent toaccess card)

2. 📂 Manually Copy the Public Key to the Target Server

Since we cannot use the<span>ssh-copy-id</span> command, we need to manually copy the public key toServer B’s<span>~/.ssh</span> directory and add it to the<span>authorized_keys</span> file. This step usually requires logging into Server B through other means (such as via a bastion host).

1. Log into Server B via Bastion Host:

• Assuming you can log into Server B as the root user via the bastion host (even if you do not know the bastion host’s root password).

• After logging into the bastion host, SSH into Server B.🔗

Manually Add the Public Key:

• OnServer A, use the<span>cat</span> command to view the public key content:

  cat ~/.ssh/id_rsa.pub  # Copy this content 📋

• OnServer B, execute the following operations:

  mkdir -p ~/.ssh          # Create directory (if it does not exist)
  chmod 700 ~/.ssh         # Set strict permissions!🛡️
  vi ~/.ssh/authorized_keys  # Paste public key content
  chmod 600 ~/.ssh/authorized_keys  # Permissions must be 600!

3. ⚙️ Configure <span><span>~/.ssh/config</span></span> File to Specify Non-Default Port

To simplify SSH connection configuration, we can modify the<span>~/.ssh/config</span> file to specify the connection information for the target server (especially for non-default ports).

InServer A’s configuration file, add the following content:

Host serverB                 # Custom alias (for example, call it "Little B")
    HostName 192.168.1.100   # Target server IP or domain name
    Port 2222                # Specify non-default port 🚪
    User root                # Login user
    IdentityFile ~/.ssh/id_rsa  # Specify private key path (optional)

After this, you can connect with just one command:

ssh serverB  # Say goodbye to complex `ssh -p 2222 root@ip`!🎉

4. 🔄 Public Key and Private Key Reuse Strategies and Management Recommendations

1. Public Key and Private Key Reuse:

• ✅ Supported Scenarios: The same key pair can be authorized formultiple servers (just add the public key to each server’s<span>authorized_keys</span>).

• ⚠️ Risk Warning: If the private key is leaked, all associated servers will be exposed!💥

Golden Rule for Key Management:

Scenario	Strategy	Example
Production Environment	Each server uses an independent key pair	<span>ssh-keygen -f ~/.ssh/prod_key</span>
Testing Environment	Can reuse the same key pair	Simplify maintenance, but clean up regularly!🧹
Cross-Team Collaboration	Assign independent keys to members + permission auditing	Use<span>command=</span> to restrict public key permissions!🔒

Security Enhancement Tips:

• 🌐 Use ED25519 Algorithm (more secure):

  ssh-keygen -t ed25519 -C "Secure Key-$(date +%F)"  

• 🗝️ Private Key Encryption Protection:

  ssh-keygen -p -f ~/.ssh/id_rsa  # Add password to existing private key

• 🗑️ Regular Key Rotation (recommended every 3 months):

  # Generate new key → Deploy to target server → Delete old key

🚨 Common Pitfalls and Solutions

1. Permission Issues Leading to Failure:

• Error phenomenon:<span>Permission denied (publickey)</span>

• Fix command:

  chmod 700 ~/.ssh && chmod 600 ~/.ssh/*

SSH Port Blocked by Firewall:

• Check command:

  telnet targetIP 2222        # Test port connectivity
  sudo ufw allow 2222      # Open port (Ubuntu)

Configuration File Not Effective:

• Debug method:

  ssh -vT serverB  # Show detailed connection process 🐞

🌈 Conclusion: Making Operations Elegant as Poetry

By reasonably using SSH key pairs, flexibly configuring<span>~/.ssh/config</span> file, and following secure key management strategies, you can easily achieveseamless transitions between servers. Remember:

• 🔥 The private key is crucial, never share it, and rotate it regularly!

• 🛠️ Automation is key, and later you can use Ansible to batch deploy keys.

• 🧠 Understand not just how, but why, understand the encryption logic behind the SSH protocol (like the RSA handshake process).

📣 Next Preview: “SSH Tunnel Practice: The Magical Channel Through Firewalls”—teaching you how to use SSH for port forwarding, intranet penetration, and even scientific internet access!🌟

(Find it useful? Like⭐ ➕ Follow, and no longer get lost!)

Follow me to learn more Linux operation and maintenance knowledge.