SSH User Key-Based Authentication

Standard SSH access often relies on personal user accounts or risky password authentication. For automation like Jenkins or secure team environments, you need a “Service User” approach: no passwords, strictly limited permissions, and cryptographic keys.

The least privilege concept

In a modern setup, we move away from sharing administrative credentials. Instead, we create a dedicated, locked-down user that can only do exactly what it is supposed to do—and nothing more.

Key features of this setup:

No Password: The user cannot log in via a password, preventing brute-force attacks.
Key-Based: Access is granted only via a specific SSH Private Key.
Sudo Restriction: The user can only run a specific script as root, not the entire system.

Creating the Locked-Down User

We start by creating a user that is “headless”—it has no password and is intended only for service tasks.

Create the User

Use the --disabled-password flag to ensure no one can guess a password to get in.


sudo adduser --disabled-password --gecos "" jenkins

Configure Sudo Elevation (`visudo`)

Instead of adding the user to the sudo or docker groups (which would be too much power), we grant permission for one specific command only.

Open the secure editor:


sudo visudo

Add this line at the very end:


jenkins ALL=(root) NOPASSWD: /var/www/vhosts/lpj.app/deploy.sh

Now, the user can run sudo /path/to/script without being asked for a password, but sudo ls, ... will still be denied.

Cryptographic Authentication

SSH keys are the “Gold Standard” for secure access. We generate an Ed25519 key pair, which is faster and more secure than older RSA keys.

Switch to the Service User

Always generate the keys as the user who will own them so switch to the created user first.


sudo su - jenkins

Generate the Ed25519 Key Pair

When prompted, enter a secure Passphrase (recommended). This adds a second layer of security: even if someone steals your private key file, they cannot use it without the passphrase.


mkdir -p ~/.ssh && chmod 700 ~/.ssh
ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519

Note

chmod 700 ...:
Only the owner can read/write/execute the .ssh directory, preventing unauthorized access.

ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519:
This creates a new Ed25519 key pair, saving the private key to id_ed25519 and the public key to id_ed25519.pub.

Authorize the Key

Copy the public key into the “Guest List” of the server itself.


cat ~/.ssh/id_ed25519.pub >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

Note

cat ~/.ssh/id_ed25519.pub >> ~/.ssh/authorized_keys:
This appends the public key to the authorized_keys file of the server, which is the list of keys allowed to log in server-wide. Each line in this file represents a different key that can access the server.

chmod 600 ...:
Only the owner can read/write the authorized_keys file, ensuring that no one else can modify the list of authorized keys.

(Optional) Connecting with SSH Keys

To use this setup from your local machine, you need to provide the Private Key to your SSH client. This guide also works for normal user access. For this you need to follow the steps below:

Extract the Key: Run cat ~/.ssh/id_ed25519 on the server and copy the entire block (including the BEGIN and END lines).
Save Locally: Create a file on your PC (e.g., jenkins.pem) and paste the content.
F. e. MobaXterm Setup:

Create a new SSH Session.
Remote Host: Your Server IP.
Username: Your SSH-Username.
Advanced SSH Settings: Check “Use private key” and select your jenkins.pem file.

Troubleshooting Checklist

Issue	Root Cause	Fix
`Permission denied (publickey)`	Wrong user or key not in `authorized_keys`.	Check `ls -la ~/.ssh` permissions (700/600).
`sudo: a terminal is required`	Command not in `visudo` or missing `sudo` prefix.	Ensure the path in `visudo` is absolute and matches exactly.
`error in libcrypto`	Key format or Passphrase mismatch in Jenkins.	Re-paste the private key and verify the passphrase in Credentials.

Warning

The Security Golden Rule

Never share your Private Key (id_ed25519). If a key is compromised, immediately remove its corresponding Public Key from the authorized_keys file on the server.

Summary

By following this guide, you can create a bridge between your automation tools like Jenkins and your server that is resistant to password leaks and limits the “Blast Radius” in case of a breach.

Created: 27.03.2026

Last Updated: 27.03.2026