The Default Home-Directory Key Path Was Not Writable
The original ZimaOS question, posted in December 2024, concerned the usual ~/.ssh/authorized_keys workflow. The system's read-only layout prevented the author from creating that file normally. Early experiments in the topic did not produce a confirmed durable workaround, so they should not be presented as a finished solution.
A Later ZimaOS 1.7 Report Used an /etc Key File
In August 2026, another community member reported a working approach on ZimaOS 1.7. They placed public keys in /etc/ssh/authorized_keys and pointed the SSH daemon to that file. The essential configuration was:
AuthorizedKeysFile /etc/ssh/authorized_keysCreate the file with administrative privileges, add one complete public key per line, and set permissions that prevent other users from modifying it. Then update the SSH server configuration and restart the SSH daemon. Because the post is a community result rather than an official compatibility statement, confirm the actual configuration file and service name on the installed ZimaOS version before changing them.
Test Key Login Before Disabling Password Authentication
Keep the current SSH session open and retain access to the ZimaOS web terminal while testing. Open a second terminal and prove that the public key creates a new session successfully. Only after that test should optional hardening settings be considered.
PasswordAuthentication no
KbdInteractiveAuthentication no
UsePAM no
PermitRootLogin no
PermitEmptyPasswords noThese settings have broader effects than changing the key path. Applying them before a successful key-login test can lock out remote administration. They also may not suit every deployment, especially if the system deliberately relies on PAM or a controlled root-login workflow.
Treat the Procedure as Version-Specific
The discussion spans nearly two years, and the confirmed report names ZimaOS 1.7 specifically. It does not demonstrate that the same files survive upgrades or behave identically on earlier releases. Record the change and retest SSH access after an operating-system update.
FAQ
Why can’t I create ~/.ssh/authorized_keys on ZimaOS?
In the original case, that part of the filesystem was read-only. The later workaround changed the daemon's key location instead of trying to force the normal home path to become writable.
Where did the working ZimaOS 1.7 method store public keys?
It used /etc/ssh/authorized_keys and configured AuthorizedKeysFile to point there.
Should password authentication be disabled immediately?
No. First keep a recovery session available and verify a fresh key-authenticated login. Disable other authentication methods only after that test and only if they fit the system's access policy.
