SSH Key Authentication: Configuring Passwordless Access

SSH keys instead of passwords: where access to servers breaks

Password login remains the weakest point of infrastructure: a password can be brute-forced, pulled from an old database dump or someone else's password vault, and it does not change for years. While password login to a server is open, protection of other perimeters almost does not matter.

Shared accounts add a second class of problems. When three engineers and a contractor work under one login, it is impossible to understand who changed the configuration, and you cannot revoke access for one person without breaking the others' work. The list of those with access grows faster than it can be cleaned up.

Password brute-forcing is cheap for an attacker: tens of thousands of attempts per minute on the standard port, weak passwords give in even faster.

Limiting attempts reduces noise in logs, but does not close the issue — one leaked "login and password" pair opens the server entirely, along with the keys and data inside.

A key pair removes both risks. The private key is not transmitted over the network and does not remain on the server; brute-forcing it is practically impossible, and access is revoked by deleting a line in the authorized keys file — individually, without affecting colleagues.

SSH key setup is built exactly on this: generating a pair, logging in to the server by key, disabling password login, and checking that backup access remains working.

Below we cover, using OpenSSH, which parameters are responsible for key login, where access most often breaks, and in what order to disable passwords so as not to lose connection to the server.

What changes after switching to key authentication

A password is a shared secret: it leaks through messages, settles in command history and deployment scripts, and is guessed by automated scanners within hours.

As soon as a ban on password login appears in the server configuration, this class of failures goes away entirely — brute-forcing and substituting stolen credentials stop working.

The OpenSSH client is present in any current branch of the system; no separate agent needs to be deployed.

Key authentication also changes onboarding a new engineer: they generate a pair themselves, hand over only the public part, and it is added as a single line to the allowed list on the required hosts.

The private key never leaves the owner's machine and is not stored anywhere by the administrator. Offboarding an employee means deleting a line or revoking a certificate: minutes instead of changing passwords across the entire server fleet.

Manual work for administrators drops: "forgot password" tickets, scheduled rotation of a shared password across the entire infrastructure, and handling lockouts after a series of failed logins leave the task queue. One operation remains — add or remove a key.

A key is tied to a person, so logs show exactly who opened a session, rather than a faceless shared login. It is further restricted: allowed addresses, a fixed command on connection, port forwarding disabled — access is granted exactly for the task it is needed for.

Because of this, team access management becomes a reproducible procedure, and secure access to servers becomes verifiable rather than agreed upon.

Access options: SSH keys, passwords, and certificates

A password at login is the cheapest mode to set up and the most expensive to operate: it is reused on several servers, sent in messages, and not changed for years, and logs later make it impossible to understand who exactly connected.

A key pair removes password guessing, but adds its own work — public parts need to be distributed and accounted for, private parts protected, and when an employee leaves, access must be revoked on all nodes where the key is listed.

Certificates close this too: lifetime is issued for hours, renewal is automatic, and revoking access does not require going around servers.

In practice, modes are almost always combined: keys — for machines and service tasks, certificates — for people, a gateway — as a single entry point to servers with a log of all connections.

We check that each option combines with your current configuration management tools, and only after that disable the password — with an emergency login left under control.

How key access is implemented in infrastructure

Implementation of key access starts not with generating keys, but with inventory: who, from where, and to which hosts goes today.

Password login remains an emergency channel until it is confirmed that all scenarios — admin sessions, build and deployment, maintenance tasks — work with keys.

1. Server access audit: collect the list of hosts, accounts, connection sources, and current authorized_keys with fingerprints. Separately mark shared keys, root login, and entries no one can confirm.
2. Access model design: roles (administrator, deployment, log reading), a separate key per role and per person, a single bastion node for external connections instead of direct ports on each server.
3. Key generation and storage: a modern signature algorithm, a passphrase on the private part, the private key only in a protected vault, public parts and fingerprints go into the registry.
4. Rolling out public keys and configuration: authorized_keys via templates and configuration management, in sshd_config — disabling passwords and root login, limiting algorithms and number of sessions. Apply without restarting production services.
5. Checking access setup: test login for each role, checking key revocation and log reaction, verifying that old login methods are closed but the emergency channel is available to the on-call engineer.
6. Handing keys to the team: issuance over a secure channel, a ready ssh_config with aliases and a bastion, rotation and revocation procedure, a short guide for new engineers.
7. Policy and support: key lifetime, scheduled rotation, a checklist for role changes or employee departure, a fingerprint registry as the source of truth.

The perimeter is considered handed over when a new engineer gets access according to the guide within minutes, and key revocation closes login on all hosts at once.

What remains with you after access setup

After implementation, you retain not only working access but also everything needed to support it independently: server configurations, an access diagram, policies, and documentation for the on-call shift. We hand over the kit so a new engineer can understand it without us.

• Server configurations — sshd_config with password authentication disabled, restrictions by users and groups, attempt limits and session timeout, in a form that transfers to configuration management.
• Key access diagram — which SSH keys lead where, where private parts are stored, which nodes are open directly and which are reachable only through an intermediate host.
• Key issuance policy — who initiates a request, how the pair is formed, where the private key lives, what is recorded in the request, and who approves issuance.
• Revocation policy — the deadline for deleting a record from authorized_keys, the procedure for termination and role change, verification that the previous key no longer grants access.
• On-call shift documentation — typical symptoms (authentication failure, incorrect directory permissions, log overflow), what to check first, and who to contact during an incident.
• Access inventory — a table "employee — key — server — validity period" showing who has access and when it should end.
• Monitoring points — which events are written to the log (successful and unsuccessful attempts, key set changes), where they go, and what threshold triggers an alert.

Case study: how password login was closed in a distributed team

Before: 140 servers and passwords in three places

A team of 60 engineers across four sites maintained about 140 servers in three perimeters. Login was password-based: some accounts were in a shared file, some with on-call engineers, and contractors had one service user for everyone. Issuing access took from several hours to two days.

Revocation cost even more. When an employee left or a contractor changed, the password was changed manually down the list, and no one could say on how many machines it remained the same.

After: a personal key and a short certificate

Each engineer received a personal key, and the servers received trust in the center's signature: the file with allowed keys stopped being a growth point, and the access role is issued by certificate parameters.

The certificate lifetime is short, renewal is automatic, so revocation is refusal to reissue rather than manually going around the list of machines.

Rollout was done via Ansible: the server inventory and access rules are described declaratively, and a new machine receives the same policy as the others.

What changed

Access issuance dropped from days to minutes, revocation — from "when someone gets around to it" to one certificate lifetime. Password login is closed on all servers, including staging.

Three classes of failures are gone: password brute-forcing, a shared service login, and live access for departed employees. Logs now show who logged in and when — incident analysis relies on records, not testimony.

What to do if password login is deployed on all servers

Yes, there is an order, and it does not depend on how many servers already run on passwords. First keys are placed on all machines, then key login is checked, and only after that is the password disabled — and not everywhere at once.

The basic migration rule: there is no step after which you are left with a single way to get to the server.

On each node, we make configuration edits so that both schemes work in parallel: the key is already in the user's authorized keys file, the password is still allowed.

We check not "by eye" but with a separate test user without other login paths and by reviewing the effective settings. While it is guaranteed to log in by key, the server remains in its group and is not moved further.

Separately, what must not be done all at once: banning passwords across the entire fleet at once, disabling emergency access, and combining migration with a system update.

We check emergency login via the provider console before the first edits — otherwise there is a chance of being left without access to the machine.

The final password login ban is introduced by groups: first we look at who logged in from where, close the leftovers, and only then remove the password on the last group.

Doubts and limitations before access setup

Key access removes the password as a point for guessing, but does not remove operational questions: service accounts, old equipment, key rotation procedure, and actions upon loss. Below are the things most often asked before starting.

Separately about key access risks: a private key without a passphrase is a file whose copy equals loss of access. Therefore we set a key lifetime, store it on a protected medium, and keep a connection log for each host, not only by account.

How should access be issued for service accounts and automation?

For services, we create separate keys for each perimeter, not one shared one. In the allowed list we restrict the permitted command and disable an interactive shell: an automation key can perform exactly one action and does not turn into a full login.

What if some systems do not support keys?

Panels and network devices often support only a password. We leave such points as an exception: an isolated segment, source address restriction, logging. On the rest of the fleet, password login is closed — this is a deliberate exception in the policy, not a forgotten hole.

How often should keys be rotated and who controls this?

We tie scheduled rotation to events: employee departure, role change, host compromise. The policy records the key owner, lifetime, and revocation procedure — otherwise in six months no one will be able to say whose key still opens prod.

Let's discuss passwordless access to servers

To discuss access setup concretely, rather than "by eye," we need a snapshot of your perimeter: what exists now and what it should become.

We work with OpenSSH — the reference implementation present in any modern distribution, so you won't have to change your usual tooling. Below is a list sufficient for us to come back with an estimate for access work and a plan.

• Inventory. How many servers and environments, which operating systems, whether any equipment without updates remains.
• Who connects and from where. Employees and services, static or dynamic addresses, direct login or via an intermediate node.
• What the situation with passwords is today. Shared accounts, rotation, where private keys are stored and how they are protected — file, hardware token, secrets vault.
• Rights and roles. Who needs access to the production perimeter and administrative login, how environments are separated between teams.
• Automation. Build jobs, release deployment, backups — where a key permanently lives on the executor server.
• External contractors and audit. To whom we issue temporary access, how we revoke it, whether login logs tied to a person are needed.
• Limitations and maintenance window. What must not be changed, whether there is a test perimeter for trial runs, and when changes are allowed.

From these answers we assemble a plan: the order of stages, which configuration files and rules are affected, how we verify the result, and how we roll back if access is lost somewhere. Describe the task — we will return with an estimate and work plan.