SSH access without shared passwords using short-lived logins

Why shared bastion passwords cause trouble

A shared bastion password feels practical when a server goes down at 2 a.m. One person posts it in chat, everyone gets in, and the issue gets fixed.

The trouble starts as soon as that password leaves one controlled place. It spreads fast, and nobody fully controls where it ends up. Teams copy it into chat threads, ticket comments, personal notes, browser vaults, and old runbooks. Months later, people still have the same secret on laptops and phones they no longer use for work.

That creates two problems at once. First, access becomes hard to shut off. When someone leaves the team, nobody can say for sure that access really ended. Rotating the password helps, but teams often put it off because they worry about breaking scripts or locking out the next person on call.

Second, a shared password destroys accountability. If five people log in through one bastion account, the logs only show that the shared account connected. They do not show who ran a command, who copied data, or who changed a config file during an outage. After an incident, that gap hurts.

The usual failures are familiar. Someone stores the password in a chat message that never expires. A former contractor still knows it months after the project ends. Several engineers log in at once under the same name during an emergency. Later, nobody can rebuild the chain of actions with confidence.

This is the trade-off many teams accept without meaning to. They want emergency server access to stay fast, so they keep a permanent secret ready at all times. That makes rare emergencies easier, but it creates daily risk.

A better goal is simple: keep access fast during a failure, but stop handing the whole team a password that lives forever. SSH access without shared passwords gives each person their own identity, a short access window, and a clear record of what happened.

What short-lived access changes

With SSH access without shared passwords, each person gets their own login, certificate, or token, and it expires on its own. That might mean 20 minutes for an urgent fix, a few hours for planned maintenance, or one day for a migration. Nobody needs to keep a permanent secret in chat, a wiki, or an old password vault entry.

That expiry changes risk in a very practical way. If someone copies a credential by mistake, leaves it on a laptop, or pastes it into the wrong place, the damage window stays small. The credential stops working soon, so it cannot sit quietly for weeks or months.

Named access matters just as much. A shared bastion password hides people behind one account. Individual access ties each session to a real person. When a contractor leaves, you remove that one person. You do not rotate a password that half the team used for years.

It also makes approvals less messy. If one engineer needs admin access at 2:10 a.m., they request it under their own name, get it for a limited time, and work inside that session. The next morning, nobody has to guess who logged in or whether the old password is still floating around.

A useful bastion host audit trail should answer plain questions: who requested access, who approved it, when the session started, when it ended, and which server they reached. That record helps teams reconstruct incidents, confirm that offboarding worked, and prove that emergency server access stayed under control.

What a safer SSH setup needs

A safer setup starts with identity, not with a password everyone knows. Each person needs to sign in as themselves first. In practice, that usually means SSO, MFA, or a hardware-backed login, so the system can tell who asked for access and when.

Four parts matter most: an identity check, an approval step for sensitive systems, a temporary credential that expires on its own, and logs that record what happened.

The bastion host sits in the middle like a controlled front desk. Engineers do not connect straight to production servers from their laptops. They go through the bastion, which checks identity, applies policy, and issues a short-lived SSH certificate or token for a specific server and a specific time window.

That time limit does a lot of the work. If someone gets approval for 30 minutes, access ends 30 minutes later without anyone needing to remember cleanup. That is a lot better than a shared secret that stays valid for months because nobody wants to rotate it during a busy week.

Teams also need one clear place to manage access rules. Some keep them in an identity provider, some in infrastructure code, and some in an internal policy repository. The tool matters less than the consistency. People should know who can request production access, who can approve it, which systems need extra checks, and how after-hours access works.

Logs need the same care. A bastion host audit trail should capture the request, the approval, the issued credential, and the session itself. For higher-risk systems, session recording can help a lot. After an incident, you can review commands, confirm what changed, and avoid guessing.

If one part is missing, the whole plan weakens. Temporary admin access without logs leaves you blind. Logs without strong identity leave you with usernames nobody trusts. The pieces have to work together.

How emergency access should work

When a server breaks at 2 a.m., people need a fast way in. They do not need a shared password that five people know and nobody rotates.

Emergency access should start with one named person asking for access. Every session needs a clear owner from the first minute. That request should include two simple details: why access is needed and how long it should last.

A clean flow is usually straightforward. One engineer requests access with their own identity, names the server, gives a reason, and asks for a time limit. The system issues a short-lived login or certificate. The bastion records the login, the session activity, and the logout time. Then access expires on its own, even if nobody remembers to remove it.

This matters most when people are stressed. During an outage, customers are waiting and someone will eventually say, "just give me the password." A safer process removes that pressure because the fast path already exists.

The time limit should stay short by default. If the fix takes longer, the person can request another window and explain why. That creates a better audit trail than one long session that covers several unrelated changes.

Logging should also be specific. You want to know who connected, when they connected, which server they touched, which commands they ran, and when the session ended. If something goes wrong later, the team can review facts instead of trying to remember a stressful night.

Automatic removal is the part many teams skip. It is also the part that keeps temporary admin access from turning into permanent access by accident. Once the window closes, the login should stop working without a human cleanup step.

When SSH access without shared passwords works well, emergency access feels boring. One person asks, gets a short window, fixes the issue, and loses access when the job is done.

How to roll this out step by step

If you want SSH access without shared passwords, rollout order matters more than the tool. Teams get into trouble when they change login rules before they understand who can reach which server.

Start with a plain inventory. List every server, bastion, local admin account, service account, and person who still uses them. Most teams find stale accounts, old vendor logins, or scripts that still depend on a shared password.

Then stop the problem from growing. For new access requests, do not hand out the bastion password in chat, email, or a wiki. Keep the old path alive only during the transition, and make the new path the default right away.

Next, choose a temporary access method. Short-lived SSH credentials often work well, and one-time credentials can fit smaller teams. Set different approval rules for routine work and urgent incidents. Normal access can wait for review. Emergency server access needs a faster path, but it still needs a named approver and a written reason.

Test the full cycle before you trust it. Log in, confirm the session is recorded, wait for expiry, and make sure the user cannot reconnect after time runs out. Then remove old accounts in batches. Cut over a few servers first, fix what breaks, and expand from there.

Do not skip account removal. A system with temporary admin access on paper still carries permanent risk if local fallback accounts stay active forever. Disable or rotate those accounts as each server moves to the new model.

Write a short runbook for the on-call team. One page is enough. It should answer five things quickly: who approves access, how staff request it, how access gets issued, where logs live, and what to do when the incident ends.

A good test is simple. Try the process during a quiet afternoon and see whether someone can get access in ten minutes, do the job, and lose access automatically later.

A simple example from a small team

A three-person startup makes this easy to picture. One founder handles product and ops. Two contractors handle backend and frontend work. They share a few production servers and need emergency server access at night, but they do not want a permanent password sitting in chat.

At 11:40 p.m., customers start seeing failed checkout requests. Alerts hit the founder's phone. The backend contractor is awake and can help, but he does not keep standing SSH access to production. That adds one small step during an incident, but it removes a bigger risk the rest of the time.

He posts a short request in the team's ops channel. He names the server, explains the problem, and asks for 30 minutes of access. The founder checks the alert, confirms the issue, and approves the request. The access system creates a short-lived SSH credential tied to the contractor's own account. No one shares a password. No one pastes a secret into chat.

He connects through the bastion, checks logs, finds a stuck worker process, and rolls back a bad config change. The bastion host audit trail records who logged in, which server he reached, when approval happened, and when the session closed. If he needs to reconnect after the 30 minutes ends, he cannot reuse the old login. He has to ask again.

By 12:05 a.m., errors drop back to normal. The contractor adds a short note in the incident thread with what he changed and why. Five minutes later, his access expires on its own. The team does not need to rotate a shared password or wonder who still knows it.

The next morning, the founder reviews the audit log with both contractors. They compare the alert time, the approval record, the bastion log, and the fix note from the incident thread. Everything matches. The review takes about ten minutes, and it answers the questions shared passwords rarely answer well: who got in, who approved it, what changed, and when access ended.

For a small team, that is reason enough to switch.

Mistakes that weaken the plan

Most failures come from one bad habit: keeping the old shortcut alive in the background. A team sets up temporary logins, then leaves one hidden break-glass password on the bastion host "just in case." Months later, people forget who knows it, nobody rotates it, and it becomes the easiest way in.

That single password pulls the whole access model backward. If an emergency path exists, it needs the same controls as everything else. Limit who can trigger it, record every use, and rotate it after every incident.

Another common mistake is giving people access for too long because the process feels annoying. If a task takes 20 minutes, the login should not stay valid for a week. Long windows create quiet exposure. People reopen old sessions, reuse old commands, or forget they still have admin rights.

Short-lived SSH credentials only help when they are actually short-lived. If the request flow feels slow, fix the process instead of stretching the access window.

Teams also weaken the plan when they stop logging trusted people. Senior engineers, founders, and long-term contractors often get exceptions because "we know them." That is exactly how gaps appear. During an outage, nobody remembers who ran what, from where, or why.

An audit trail should cover every person under the same rules. Trust does not replace records.

Generic accounts create another mess. If three people log in as "admin," personal responsibility disappears right away. One engineer may restart a service, another may edit a config, and the logs show the same username for both.

Use named access for every human. Shared accounts save a few minutes and cost hours during review.

The last mistake is simple and very common: nobody tests the process until a real outage hits. Then the token service is misconfigured, the approval step goes to the wrong person, or the bastion rules block the one server that matters.

Run a drill before you need one. Ask someone with no special context to request access, connect, run a safe command, and exit. If that small test feels confusing, a 2 a.m. incident will feel much worse.

A quick checklist before you trust it

A safer SSH setup should answer one question under stress: can your team get in fast, and can you prove who did what later? If either answer is no, the setup still needs work.

Before you trust it, check a few basics:

• Each person signs in with their own identity. No team login, no reused "admin" user, and no mystery session that nobody can trace later.
• Access ends by itself. A short-lived SSH certificate or temporary login should expire on time, even if someone forgets cleanup.
• The audit trail is complete. You should see who asked for access, who approved it, when it started, when it ended, and what happened during the session.
• The team can still reach servers during an outage. If the main identity system goes down, the backup path should still keep names, time limits, and logs.
• The runbook fits on one page. During a 2 a.m. incident, nobody wants a long policy document.

The runbook matters more than most teams expect. It should say where to request access, who can approve it, how long access lasts, how to confirm the session was logged, and what to do if the normal approval path is unavailable.

Run one simple drill. Ask an engineer who did not help design the system to get temporary admin access to a test server. Time the process. If they get stuck, open three tabs, or ask in chat which button to press, the plan is too hard.

Good security often looks boring. Named identities, automatic expiry, clear logs, and a short runbook do not sound fancy, but they hold up when pressure is real.

What to do next

Start small. Pick one environment where the risk is real but the impact stays limited, such as staging or one internal service. Replace the shared login there first. A narrow test teaches more than a long policy document, and your team can fix mistakes before they spread.

Then run one emergency drill this month. Make it feel real. One person requests access, one person approves it, and the person who gets access completes an actual admin task under time pressure. That is usually where weak approval rules, confusing alerts, and bad logging show up.

Review the result right away while people still remember it. Measure the time from request to shell access. Check whether the audit trail shows who asked, who approved, which server they touched, and why. Confirm that the temporary account or certificate expired on time. Then ask someone else to read the log and explain what happened. If they cannot, the record is too weak.

After one or two clean tests, move to the next environment. Do not switch every server at once. Teams usually trip over access names, approval paths, and missing alerts before they trip over SSH itself.

If you want a second opinion, Oleg Sotnikov at oleg.is works as a fractional CTO and startup advisor and helps companies tighten infrastructure, access rules, and operational processes. A short review can expose places where the system still depends on trust instead of clear evidence.

A solid 30-day plan fits on one page: the first environment to change, who can approve access, how long temporary access lasts, and when the next drill happens. Put one owner next to each item, and run it.