Configure SSH Passwordless Login on openSUSE

To configure passwordless SSH login on openSUSE, create an SSH key on the computer you will connect from, then add its public key to the account on the openSUSE computer. After confirming that key-based login works, you can optionally turn off password authentication; keep an existing session or console access available until you have verified the change.

How SSH key login works

SSH normally authenticates a remote account with a password. With public-key authentication, your client keeps a private key and sends proof that it owns the matching key. The server stores the corresponding public key in the remote account’s ~/.ssh/authorized_keys file. The private key should remain on the client and should never be copied to the server.

“Passwordless” usually means you do not have to enter the remote account password for each connection. If you protect the private key with a passphrase, you may still need to unlock it, though an SSH agent can cache that unlock during a login session. A key passphrase protects the key if its file is copied; it is distinct from the account password.

1. Check SSH on the openSUSE computer

The destination machine must be running an SSH server. On openSUSE, the server package is commonly named openssh, and its systemd service is sshd. On the openSUSE machine, check the service with:

sudo systemctl status sshd

If the command reports that the service is not installed, install the distribution’s OpenSSH package using YaST Software or the appropriate openSUSE package-management command, then start and enable the service:

sudo systemctl enable --now sshd

Enabling makes the service start at boot; starting it makes it run now. If you use a firewall, allow SSH through the firewall configuration in use. The standard SSH port is TCP 22 unless the server has been configured to use another port. Do not expose SSH to networks you do not intend to reach it from.

2. Create a key on the client

Run key-generation commands on the computer from which you will connect, not on the server. Ed25519 is a widely supported modern choice:

ssh-keygen -t ed25519 -C "your-name@client"

When prompted for a file, the default is usually ~/.ssh/id_ed25519. Choose a passphrase if you want protection at rest, or leave it empty if you understand the trade-off and need unattended use. Do not overwrite an existing key unless you have confirmed it is no longer needed; you can specify a different filename when prompted.

The command creates two files: id_ed25519, the private key, and id_ed25519.pub, the public key. Share only the public file. If Ed25519 is unsuitable for a particular older client or server, RSA may be supported, but use an adequate key size and follow the compatibility requirements of that environment.

3. Install the public key on openSUSE

If available on the client, ssh-copy-id can install the key. Replace the example account and host with the actual remote username and hostname or IP address:

ssh-copy-id -i ~/.ssh/id_ed25519.pub user@opensuse-host

It will usually ask for the remote account password once to copy the public key. If the server uses a nonstandard port, specify it with -p, for example ssh-copy-id -p 2222 -i ~/.ssh/id_ed25519.pub user@opensuse-host.

If ssh-copy-id is unavailable, create the directory and append the public key over an authenticated SSH connection. On the server, the target account needs a private SSH directory and an authorized-keys file:

mkdir -p ~/.ssh
chmod 700 ~/.ssh
cat >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

For the cat step, paste the single line from the client’s id_ed25519.pub file, then press Ctrl-D to finish. Check that these files belong to the remote account, not root. SSH may reject keys if ownership or permissions are too open. Keep the public key on one line; do not paste the private key.

4. Test the connection before changing settings

From the client, connect using the same account and host:

ssh user@opensuse-host

If the key has a passphrase, enter it when requested. If the session opens without asking for the remote account password, key authentication is working. A first connection may ask you to verify the server’s host-key fingerprint. Confirm it through a trusted channel when possible; accepting an unexpected fingerprint without checking can conceal a connection to the wrong server.

To see which keys the client offers, use verbose mode:

ssh -v user@opensuse-host

For a nonstandard port, use ssh -p 2222 user@opensuse-host. Test a new connection in a second terminal before closing any existing administrative session.

Common problems and fixes

• It still asks for the account password: Confirm you installed the public key for the same remote username used in the SSH command. Check that the key is in that account’s ~/.ssh/authorized_keys file and that the client is offering the intended private key; try ssh -i ~/.ssh/id_ed25519 user@opensuse-host.
• Permission denied: On the server, check ownership and restrictive permissions for the home directory, ~/.ssh, and authorized_keys. The usual directory and file modes are 700 and 600. Also check the server log and SSH configuration for authentication restrictions.
• Connection refused or timed out: A refused connection often means the server is not listening on that address or port. A timeout can indicate a network route or firewall issue. Check that sshd is active, the host and port are correct, and the firewall permits the intended connection.
• The key file is ignored: Specify it with -i, check its location and permissions, and use ssh-add if an agent should manage a passphrase-protected key. Avoid making private-key permissions broadly readable.
• SELinux or file labels are involved: If permissions appear correct but the server still rejects the key, review system logs and the host’s security configuration. Do not disable security controls as a first troubleshooting step.

Optionally disable password authentication

Key login and password login are separate server settings. Only consider disabling password authentication after a successful key-based login, and only if every required user and automation process has a working alternative. On openSUSE, inspect the effective SSH configuration and any included configuration files before editing; directives in included files can affect the result. A typical setting is PasswordAuthentication no in the server configuration.

After editing, validate the configuration before reloading the service. The OpenSSH server supports sshd -t for syntax checking. If it reports no errors, reload with sudo systemctl reload sshd where supported, then test a fresh connection. Retain console or other recovery access until the test succeeds. Disabling password authentication can lock out users whose keys are missing, so it is not required merely to use SSH keys.

Frequently Asked Questions

Does passwordless SSH mean there is no password at all?
Not necessarily. It avoids the remote account password when key authentication succeeds, but a passphrase-protected private key may still need unlocking. An SSH agent can reduce repeated passphrase prompts.

Where do I put the public key on openSUSE?
For the account you will log in as, put the public key line in ~/.ssh/authorized_keys. The directory and file should be owned by that account and have appropriately restrictive permissions.

Can I use one SSH key for more than one server?
Yes, but separate keys can make access easier to manage and revoke. Keep private keys protected and install only the relevant public key on each destination.

Why does SSH still ask for a password after I copied the key?
Common causes are a mismatched username, the wrong key being offered, incorrect file ownership or permissions, or server configuration that disallows public-key authentication. Use ssh -v on the client and check server logs to narrow it down.

Should I disable SSH password login?
It is optional. Do so only after verifying key access for all needed accounts and maintaining a recovery route; a working key does not require password authentication to be disabled.

Related

• Chatbots Explained: How They Work and When to Use One
• Heroes World Codes: Current Rewards and How to Redeem
• Castlevania Belmont’s Curse: Where to Go After Medusa