Default sshd configuration: where access breaks
The basic configuration of an access server is designed for the convenience of the first connection, not for operations: password login is allowed for all accounts, direct login as superuser is unrestricted, and session lifetime is not set.
While there are one or two machines, this does not get in the way — when there are dozens of servers and access is held by contractors and on-call shifts, the same set of values becomes the main attack vector.
Password brute-forcing in such a scheme happens constantly: bots brute-force dictionary login-password pairs around the clock.
The login attempt log grows, but no one reads it, so a spike of failed authentications from a single address is noticed only after a successful brute-force. There is no rate limiting of attempts or source blocking in the base sshd configuration.
The second weak point is extra accounts. Service users, accounts of departed employees, and shared logins for a team live for years: several people know their password, and revoking access when one person leaves is technically impossible.
Each such account is another valid key to the machine, and it is not visible in the user list until you start checking it manually.
The third problem is a single common template for dozens of servers.
The file is copied between machines, then edited pointwise for a specific task, and after six months the actual configuration diverges: somewhere password login is allowed again, somewhere superuser login is open. We will look at how this is closed.
What a verified access server configuration provides
A verified sshd_config is not cosmetic, but an access boundary. While password login is allowed, every request reaches credential verification, and brute-forcing goes on until the last attempt.
Keys instead of passwords, prohibition of direct superuser login, and an attempt limit cut off automated brute-forcing at the entrance — logs retain a few failures instead of thousands.
Access revocation begins to be measured in minutes. When allowed accounts and keys are described by one template rather than assembled manually across servers, termination or role change is closed by editing the template and reloading the configuration.
At the same time, the risk disappears that login remained on a forgotten stand that no one remembers.
The same template removes discrepancies between servers: one policy for the entire fleet, automatic checking of deviations from the reference, identical rules for production and test machines. Divergence is visible in advance, not after an incident.
A separate storyline is contractor access. Match blocks allow issuing a personal key, limiting the set of allowed commands, binding an address, and setting a lifetime without opening general access.
The OpenSSH implementation covers this with standard directives — without third-party add-ons and extra points of failure, and therefore without new vulnerabilities in the access chain.
Comparison of approaches: sshd configuration by keys and by password
The choice between password and key is only the first step. sshd_config allows assembling access from several mechanisms at once: disable password entirely, leave keys open, and layer on top address restrictions and a second factor. Therefore, it is worth comparing not 'key versus password' but sets of controls.
The cheap-to-configure option is usually more expensive to operate: keys must be issued, revoked when an employee leaves, and rotated.
A corporate account directory removes this routine but ties the server to an external source and forces you to decide in advance what to do when it is unavailable.
| Option | When it fits | What it does not cover and how it complicates support |
|---|---|---|
| Permanent key (AuthorizedKeysFile) | Small server fleet, stable engineering staff | Key compromise gives indefinite access; manual revocation on each server |
| Key with address-based access restriction (Match Address, AllowUsers) | Admin contour from fixed subnets or via bastion | Does not save you if the key is stolen from a trusted machine; breaks when the network changes |
| Corporate account directory + two-factor authentication | Many employees, audit requirements, frequent rotation | Dependency on the directory; login is harder to debug, a fallback path is needed |
| Service accounts with separate keys | Automation, exports, deployment | Keys live for years; shell must be disabled and command restrictions applied |
Password as the only factor was deliberately not included in the table — it is disabled. Address restriction and two-factor authentication complement each other: the address cuts off noise from outside, the second factor covers key theft.
Service accounts are isolated separately — with a forced command and their own Match rule, so that automation has no interactive access.
Implementation stages: from configuration audit to handover
The access server is the single point where a configuration error cuts the administrator off from the machine.
Therefore, sshd_config edits do not go 'in one evening across the entire fleet' but as a sequence of steps where each has a way to roll back: first we record the current state, then change one block at a time and confirm login again.
- Audit of the current configuration. We take working configuration files from all servers, record accounts, allowed login methods, and who actually connects from which addresses. We consolidate discrepancies between machines into a single document — usually they are the source of excessive privileges.
- Role-based access scheme. We separate administrators, on-call staff, and service accounts: who gets key login, who only from certain addresses, which groups are limited by a set of commands. The scheme becomes the basis of the configuration, not the other way around.
- Test contour. We copy the current settings to separate machines and test the rules there, including checking login for new roles.
- Step-by-step editing. We enable changes in blocks: first keys, then disabling passwords, then restrictions for service accounts. We check the new connection in a separate session, keeping the current one open until confirmation.
- Rollback. Before each step, we save a working copy of the configuration and keep a ready return scenario: restore the file and restart the service in one action.
- Monitoring on production servers. We roll out in groups with a pause so that a failure manifests on part of the fleet, not on all at once.
- Documentation handover. We hand over the final configurations, the regulation for issuing and revoking keys, the procedure for employee departure, and a memo for the on-call engineer.
What you retain after the work: configurations and regulations
Configured access is useless if only the author of the edit can maintain it.
Therefore, along with the work, we hand over a kit that your engineer can use to reproduce the configuration from scratch, and a new person can be brought into access without chatting and searching for 'that very' script. Below is what exactly you retain.
- Final configuration file OpenSSH — with a comment for each directive: why this value was chosen and what will break if it is changed. As a separate block — a commented safe rollback to the previous state.
- Access scheme — who, from which addresses, and with which key or certificate gets to the servers, where the gateway is, where the trust boundaries are. The scheme is drawn so that it can be shown to an auditor.
- Policies for roles — a set of rules for administrators, on-call staff, contractors, and service accounts: different key lifetimes, different allowed actions, different logging levels.
- Regulation for issuing and revoking access — request, validity period, entry in the user registry, procedure for removing a key upon termination, role change, or completion of contractor work.
- Instructions for the on-call shift — how to read login logs, what to check during mass failures, how to confirm a problem with a live session, where to escalate if compromise is suspected.
- Fallback login path — console access via the provider's panel, so that a configuration error does not cut the team off from the server.
- Map of logs and alerts — which events go to monitoring and at what threshold the on-call engineer raises an alarm.
The kit is designed so that six months later it will be used by a person who did not witness this work.
Case study: how password brute-forcing was closed on a server fleet
The task came from the logs: the share of failed login attempts across the server fleet grew to tens of thousands per day, and successful logins from unfamiliar addresses appeared during non-working hours.
Investigation of login incidents took almost a week — there was no single configuration template, each node lived with its own configuration, and there was nothing to compare the logs with.
What the audit showed
A single access template was on fewer than two-thirds of the servers, on some nodes password login for the administrative account remained allowed, and there was almost no rate limiting anywhere.
Access revocation upon termination took up to two days: keys and accounts were removed manually, for each node separately.
What was done and what the result was
The configuration was brought to a single template and rolled out across the entire fleet: password login is disabled, key login remains, brute-forcing is additionally limited at the level of the service itself and Fail2ban — the address is blocked after a series of failures. Old keys were revoked, access is now granted by role rather than by editing a specific server.
The share of servers with a single template is 100% instead of two-thirds. Failed login attempts dropped by two orders of magnitude, successful logins from foreign addresses stopped.
Access revocation time decreased from two days to 15 minutes, and investigation of login incidents — from a week to half an hour: the logs are comparable because the nodes are configured identically.
How key login differs from password login
The password is checked by the server itself: sshd compares the entered value with the hash in the system database and lets in anyone who knows it.
A key is an asymmetric pair where only the public part is stored on the server in authorized_keys, while the private part never leaves the engineer's workstation and is not transmitted over the network.
An intercepted password can be entered again from a foreign address, but a signature cannot be forged without the private key.
The difference is sharper during revocation. A password is changed centrally, but it is impossible to revoke access for one departed engineer with a shared service password — you have to change it for everyone, including the on-call shift.
A key is removed with a single line from authorized_keys or marked as revoked in a single list, and access is closed within a minute, not according to a regulation.
| Login mode | What is harder to forge | Access revocation | Where the restrictions are |
|---|---|---|---|
| Password | Brute-force and interception are unprotected, a second factor is needed | Changed for everyone at once, selective revocation is impossible | Emergency access, initial setup |
| Key | A signature cannot be reproduced without the private key | The line in authorized_keys is removed selectively | Key inventory and rotation are needed |
| Key and second factor | The token is useless without the second confirmation | The key and token are revoked separately | More actions when issuing to a new engineer |
The second factor applies to both modes differently. With password login, it is mandatory: a brute-forced or spied password would otherwise give full access.
With key login, the second factor is placed on the private part — a hardware token or confirmation in the directory service.
Service tasks of the on-call shift and deployment robots use a separate key with restrictions: a fixed command, allowed addresses, and prohibition of an interactive terminal.
Technical doubts before editing the configuration
Editing sshd_config is one of the few operations where an error cuts off access to the server entirely, not partially.
Therefore, before work we address typical doubts: the fleet is configured inconsistently, automation uses keys and must not stop, shared and inherited accounts exist, and a contractor needs access for a time.
Servers were configured at different times — the configurations differ. What to do about this?
First we capture the actual state: we consolidate the active directives from all nodes into a discrepancy table. Then we move not towards 'rewriting everything' but towards a common baseline plus local exceptions where they are justified.
Each file is checked for syntax before application, so a node with a typo does not drop out of service.
Automation will stop if login rules are changed. How to avoid downtime?
We move the keys and addresses from which build and exchange systems operate into explicit exceptions before edits. We test the rule on one node, then roll it out across the fleet, keeping a fallback login until confirmation.
We do not blindly remove shared and inherited accounts: we transfer them to separate keys with address restrictions, and where an account is required by regulation — we narrow it to a single allowed command.
A contractor needs access for the duration of work — how to issue and close it?
We issue a separate key with an expiration date and an allowed address, without the right to change the server configuration. Upon completion of work, the key is revoked, and the log retains a trace of connections: who, when, and from where logged in.
If access is lost after editing — how to return?
A copy of the original file is kept nearby, the current session is not closed until verification, and the safety login via the provider's console remains open. Rollback returns the previous version and restarts the service — access is restored in minutes, not in emergency mode.
Let's discuss your access configuration and work plan
To make the assessment substantive rather than 'by eye', we need a minimum of input data: a list of servers with roles and the current sshd_config.
The config can be sent anonymized — public keys, addresses, and node names are enough to scrub; for analysis, the structure of the rules is important, not the hosts themselves.
During the review, we will go through each item and record where there is a real risk and where there is a deliberate exception that needs to be preserved.
- List of servers and roles: how many machines, which groups of administrators and services connect, whether there is an intermediate node for entering the internal network.
- Current sshd_config from typical nodes — it shows discrepancies between environments and the 'legacy' from previous settings.
- Access requirements: who needs login and from where, which systems use keys automatically, where a password remains a forced exception.
- Authentication scheme: where keys are stored, whether hardware tokens or certificates are used, or whether key lifetime is limited.
- External requirements: audit rules, login logging, network isolation, contractor access and its duration.
- Change windows: when it is permissible to change the configuration and restart the service, and who confirms verification after edits.
Based on this data, we will return with an assessment, a stage-by-stage work plan, and the order of application: preparation of fallback access, verification on one node, rollout to the rest.
Describe the task and send what you have — even a partial list of servers and one current config already provide a basis for a substantive conversation.