09 Systems support · SSH · Linux

SSH access and private-key permissions

The SSH service is reachable, but access fails first with the wrong key and then because the correct key has an unsafe local file mode.

Issue: Port 22 answers, but the session fails. Is the key unauthorized, is the client refusing to use the private key, or is the requested account outside the server rule?
Decisive evidence: Port 22 was reachable while a different valid key was still denied by public-key authentication.E01
Result: A reachable SSH port does not prove that the client can use its key or that the server accepts the requested account.
Boundary: This is one isolated OpenSSH server using synthetic keys and accounts.Full limit

Completion: Complete within stated scope
Execution: Isolated OpenSSH client and server run
Review: Scripted assertions and artifact check
Evidence: Selected evidence on this page

OpenSSH
Alpine Linux
Docker internal network
ARM64

The support question

Port 22 answers, but the session fails. Is the key unauthorized, is the client refusing to use the private key, or is the requested account outside the server rule?

Project record: An isolated SSH server and client, synthetic keys and accounts, two failure states, the private-key mode correction, and a repeated remote file check.

Interactive view

Find where the SSH request stops.

The service remains reachable. The selected state shows whether the request stops at key authorization, local key handling, or the remote session.

Choose a viewDifferent keyUnsafe key modeRetest

TCP 22 answers, but the server does not accept the supplied public key.

01
TCP 22SSH service
02
Private-key modeClient-side check
03
Authorized keyServer-side check
04
Allowed accountsshd boundary
05
Remote commandIdentity and file

Access checks

Separate service reachability, local key handling, server authorization, and account boundaries.

01
Start an OpenSSH server on an internal Docker network with one allowed synthetic account and one authorized public key.
02
Confirm that port 22 is reachable, then try a different valid key and record the public-key denial.
03
Use the authorized key with mode 0644 and record the client-side unsafe-permissions refusal.
04
Copy the key into the disposable client, set mode 0600, and run a remote identity and sentinel-file check.
05
Repeat the successful check in a new client and confirm that an unknown account still fails.

Evidence from the lab

The checks used to reach the conclusion.

Selected outputs from the lab. Sensitive and unnecessary details are omitted.

ssh-server:22 reachable

E01 · Captured lab outputSSH service reachableThe client reaches the server on TCP 22 before any authentication result is interpreted.

View artifact Back to C01

labops@ssh-server: Permission denied (publickey).

E02 · Captured lab outputDifferent key deniedA valid but unauthorized key reaches session authentication and receives the expected public-key denial.

View artifact Back to C01

WARNING: UNPROTECTED PRIVATE KEY FILE!
Permissions 0644 for 'lab_key' are too open.
This private key will be ignored.

E03 · Captured lab outputAuthorized key ignored locallyThe OpenSSH client refuses to use the authorized key while its private file is readable by group or other users.

View artifact Back to C02

Full evidence archive5 additional artifacts

before=0644
after=0600

E04 · Captured lab outputLocal key-mode correctionOnly the disposable client copy changes, from mode 0644 to 0600.

View artifact Back to C02

user=labops
arch=aarch64
sentinel=controlled remote support access

E05 · Captured lab outputRemote identity and file checkAfter the mode correction, the server returns the allowed account, ARM64 architecture, and controlled sentinel line.

View artifact Back to C02

retest-user=labops
retest-sentinel=controlled remote support access

E06 · Captured lab outputNew-client retestA separate disposable client repeats the account and sentinel-file check.

View artifact Back to C03

unknown@ssh-server: Permission denied (publickey).

E07 · Captured lab outputUnknown account stays deniedThe corrected key does not open an account that is outside the server’s allowed-user rule.

View artifact Back to C03

Public package
• service reachability
• key and permission failures
• correction and new-client retest
• negative account boundary
• SHA-256 checksums

E08 · Captured lab outputEvidence checksumsThe checksum list covers service reachability, both failures, the key-mode change, successful sessions, and the account boundary.

View artifact Back to C01

Result and limits

What changed, and what this lab does not prove.

Result

The wrong key reached the server and was denied. The authorized key was ignored at mode 0644, then worked at mode 0600. Two new sessions read the expected sentinel through the allowed account, while an unknown account remained denied.

Limit

This is one isolated OpenSSH server using synthetic keys and accounts. It does not claim production bastion access, directory integration, certificate-based SSH, or enterprise key rotation.

Claims and evidence

What the evidence supports.

Port 22 was reachable while a different valid key was still denied by public-key authentication.

The result covers one isolated server and one unapproved lab key.

EvidenceE01 E02

The client ignored the authorized private key at mode 0644 and used it after the disposable copy was changed to mode 0600.

The mode check uses the OpenSSH client inside one Alpine container.

EvidenceE03 E04 E05

The allowed account read the sentinel in two sessions, while an unknown account remained denied.

The boundary proves command access to one synthetic account and file.

EvidenceE05 E06 E07