DEV Community

Cover image for Connect to Multiple Linux Servers via SSH Without Entering Password: Step-by-Step Guide
Elliot Brenya sarfo
Elliot Brenya sarfo

Posted on

Connect to Multiple Linux Servers via SSH Without Entering Password: Step-by-Step Guide

Constantly entering passwords when connecting via SSH irritate me a lot. I used to have several local machines, and every time I type the keys, remembering what the password is... But there is a simple solution now which is SSH keys.

You set it up once, and then everything goes like clockwork. Like one password but for servers.

In this article, I will tell you how to do it step by step, especially if you are new to Linux or SSH.

First, a few words about what SSH is.

SSH (Secure Shell) is a protocol for secure remote access to a server. It encrypts all data so that no one can eavesdrop on your password or commands. Usually, you connect with a command like ssh user@ip-аddress, and the server asks for a password. But with keys, no password is needed authentication happens automatically through cryptography.

Key point

You don't have to create a separate key for each server. One good key can be "distributed" to all the machines you want to connect to. This saves time and effort. I've been doing this for a long time, and it really simplifies life, especially if you have a cluster of servers or virtual machines on your home network.

Setup steps

Step 1: Generate SSH key (done once)

First, you need to create a pair of keys: private and public. It's like a lock and a key - the private key stays with you, and the public "lock" is placed on the servers.

Open a terminal (on Windows, this could be PowerShellor Git Bashif you have Git installed). Enter the command:

ssh-keygen -t ed25519 -C "your_email@example.com"
Let's take a look at what's going on here:

ssh-keygen : This is a key generation utility. It is part of the standard OpenSSH suite, which is usually already installed on most systems.

-t ed25519 : Option for key type. Ed25519 is a modern algorithm, it is fast, secure and compact.

-C " your_email@example.com " : This is a comment that is added to the key. Not required, but useful for identification - for example, if you have several keys. Replace with your real email.

When you run the command, it will ask where to save the files. By default, it is C:\Users<your_name>.ssh\id_ed25519(on Windows) or ~/.ssh/id_ed25519(on Linux/Mac). If it asks you to overwrite the existing key, do not agree unless you want to lose the old one.

Then it will ask you to enter passphrase(password for the key). This is optional, but I recommend setting it - this is additional protection. If there is no passphrase, then the connection will be completely automatic, but if someone steals your private key, they will get access to everything. With passphrasethe key "locked" until you enter the password, but for automation (for example, in scripts) this may be inconvenient.

As a result, two files will be created:

id_ed25519 — private key. This is your "secret key", never copy it to other machines!

id_ed25519.pub is a public key. It can be distributed left and right.

If you have Windows, check the folder .sshin your profile. If it is not there, it will be created automatically.

Step 2: Copy the public key to the servers

Now you need to "install" the public key on each server. There is a convenient command for this ssh-copy-id.

For each server, run:

ssh-copy-id -i "C:\Users<your_name>.ssh\id_ed25519.pub" user@IP-address
Let me explain the parameters:

-i "path_to_public_key": Specifies which key to copy. Replace with the actual path.

user@IP-address: Here user is the username on the server (for example, administrator or root), and IP address is the server address, like 192.168.98.98.

The first time you run it, it will ask for a password (yes, for the last time!). It will connect via SSH, add your public key to a file ~/.ssh/authorized_keyson the server, and exit. Repeat this for all servers.

If ssh-copy-idit doesn't work (on older systems), you can do it manually: copy the contents id_ed25519.pub(open in notepad, for example), connect to the server via SSH with a password, create a file ~/.ssh/authorized_keys(if not), and paste the key string at the end of the file. Don't forget to set the rights: chmod 600 ~/.ssh/authorized_keys.

Step 3: (Optional) Customize the config file for convenience

To avoid typing long commands like ssh admin@192.168.98.98, create a file ~/.ssh/config(on Windows C:\Users<ваше_имя>.ssh\config). It's like an address book for SSH.

Open the file in an editor (notepad will do) and add blocks like:

Host server1
    HostName 192.168.98.98
    User admin
    IdentityFile ~/.ssh/id_ed25519

Host server2
    HostName 192.168.98.214
    User administrator
    IdentityFile ~/.ssh/id_ed25519
Enter fullscreen mode Exit fullscreen mode

Host server1: This is the alias how you will call the server.

HostName: Real IP or domain.

User: Default username.

IdentityFile: Path to the private key.

Save the file. Now connecting is easy ssh server1. Cool, right?

Step 4: Checking the connection

Now try: ssh server1.

If everything is OK, it will connect without a password. If it asks passphrase, enter it (if you set one).

How it works under the hood

Let's figure out why this works, so there is no magic. SSH keys are based on asymmetric cryptography ( public-key cryptography ). When generated, a pair is created:

Private Key: Stored only by you, used to "sign" the connection request.

Public key: Open, located on servers in authorized_keys.

When you connect, the client (your computer) sends a request: "Hey, server, I have a private key that matches this public one." The server generates a random challenge, the client "signs" it with the private key, the server checks the signature with the public key. If it matches, welcome!

The public key is not a secret because it cannot be used to "hack" the private key. But the private key is, yes, your main asset.

Conclusion

That's it! Now you can connect to a bunch of servers without passwords.

Top comments (2)

Collapse
 
thedeepseeker profile image
Anna kowoski

Feels Dangerous

Collapse
 
elliot_brenya profile image
Elliot Brenya sarfo

You’re right to flag security concerns. SSH keys are safer than passwords, but only when set up correctly. That’s why I included permissions, recommended ed25519, and noted disabling passwords only after testing. If a step feels risky, I’d love to hear which one so I can clarify it further.