Het standaardpad naar de thuismap was niet schrijfbaar
De oorspronkelijke ZimaOS-vraag, geplaatst in december 2024, ging over de gebruikelijke workflow met ~/.ssh/authorized_keys. Door de alleen-lezenindeling van het systeem kon de auteur dat bestand niet op de normale manier maken. Vroege experimenten in het onderwerp leverden geen bevestigde, blijvende workaround op en mogen daarom niet als een afgeronde oplossing worden gepresenteerd.
Een later rapport over ZimaOS 1.7 gebruikte een sleutelbestand in /etc
In augustus 2026 meldde een ander communitylid een werkende aanpak voor ZimaOS 1.7. Die persoon plaatste openbare sleutels in /etc/ssh/authorized_keys en verwees de SSH-daemon naar dat bestand. De essentiële configuratie was:
AuthorizedKeysFile /etc/ssh/authorized_keysMaak het bestand met beheerdersrechten, voeg per regel één volledige openbare sleutel toe en stel machtigingen in die voorkomen dat andere gebruikers het bestand kunnen wijzigen. Werk vervolgens de configuratie van de SSH-server bij en start de SSH-daemon opnieuw. Omdat het bericht een resultaat uit de community is en geen officiële compatibiliteitsverklaring, moet je vóór wijzigingen controleren welk configuratiebestand en welke servicenaam worden gebruikt in de geïnstalleerde versie van ZimaOS.
Test het aanmelden met een sleutel voordat je wachtwoordauthenticatie uitschakelt
Houd de huidige SSH-sessie open en behoud tijdens het testen toegang tot de webterminal van ZimaOS. Open een tweede terminal en controleer of de openbare sleutel succesvol een nieuwe sessie tot stand brengt. Pas na die test kun je optionele beveiligingsinstellingen overwegen.
PasswordAuthentication no
KbdInteractiveAuthentication no
UsePAM no
PermitRootLogin no
PermitEmptyPasswords noDeze instellingen hebben bredere gevolgen dan alleen het wijzigen van het sleutelpad. Als je ze toepast voordat je het aanmelden met een sleutel succesvol hebt getest, kun je externe beheertoegang blokkeren. Bovendien zijn ze niet voor elke implementatie geschikt, vooral niet als het systeem bewust afhankelijk is van PAM of van een gecontroleerde workflow voor root-aanmeldingen.
Beschouw deze procedure als versieafhankelijk
De discussie beslaat bijna twee jaar en het bevestigde rapport noemt specifiek ZimaOS 1.7. Er wordt niet aangetoond dat dezelfde bestanden upgrades overleven of zich op eerdere releases identiek gedragen. Leg de wijziging vast en test de SSH-toegang opnieuw na een update van het besturingssysteem.
Veelgestelde vragen
Waarom kan ik ~/.ssh/authorized_keys niet aanmaken op ZimaOS?
In het oorspronkelijke geval was dat deel van het bestandssysteem alleen-lezen. De latere workaround wijzigde de locatie van de sleutels voor de daemon, in plaats van te proberen het normale thuismappad schrijfbaar te maken.
Waar bewaarde de werkende methode voor ZimaOS 1.7 de openbare sleutels?
De methode gebruikte /etc/ssh/authorized_keys en configureerde AuthorizedKeysFile om daarheen te verwijzen.
Moet wachtwoordauthenticatie onmiddellijk worden uitgeschakeld?
Nee. Zorg eerst dat je een herstelsessie beschikbaar houdt en controleer of een nieuwe aanmelding met sleutelverificatie werkt. Schakel andere authenticatiemethoden pas na die test uit en alleen als ze passen binnen het toegangsbeleid van het systeem.
