Vraag Is het goed om een ​​wachtwoordloze `sudo` in te stellen op een cloudserver?


Ik hou van het idee om servers via sleutels te gebruiken, zodat ik niet telkens mijn wachtwoord hoef in te tikken ssh in een doos, ik vergrendel zelfs mijn gebruiker's (niet root) wachtwoord (passwd -l username) dus het is onmogelijk om in te loggen zonder een sleutel.

Maar dit breekt allemaal als ik verplicht een wachtwoord moet invoeren sudo commando's. Dus ik ben in de verleiding om op te zetten wachtwoordloze sudo om dingen in overeenstemming te brengen met inloggen zonder wachtwoord.

Ik heb echter nog steeds het gevoel dat het op een onverwachte manier averechts kan werken, het lijkt gewoon onzeker. Zijn er voorbehouden met zo'n opzet? Zou je aanbevelen / niet aanraden om dit te doen voor een gebruikersaccount op een server?

verduidelijkingen

  1. Ik heb het over het gebruik van sudo in een interactieve gebruikerssessie hier, niet voor services of beheerdersscripts
  2. Ik heb het over het gebruik van een cloudserver (dus ik heb geen fysieke lokale toegang tot een machine en kan alleen op afstand inloggen)
  3. ik weet dat sudo heeft een time-out waarbij ik mijn wachtwoord niet opnieuw hoeft in te voeren. Maar mijn concert gaat niet echt over het verspillen van de extra tijd om een ​​wachtwoord fysiek in te typen. Mijn idee was echter om helemaal geen wachtwoord te hoeven behandelen, omdat ik veronderstel dat:
    • Als ik het helemaal moet onthouden, is het waarschijnlijk te kort om veilig te zijn of opnieuw te gebruiken
    • Als ik een lang en uniek wachtwoord genereer voor mijn externe account, moet ik het ergens opslaan (een lokaal wachtwoordbeheerprogramma of een cloudservice) en het elke keer ophalen als ik het wil gebruiken sudo. Ik hoopte dat ik dat kon vermijden.

Dus met deze vraag wilde ik de risico's, kantelingen en compromissen van de ene mogelijke configuratie beter begrijpen dan de andere.

Follow-up 1

Alle antwoorden zeggen dat zonder wachtwoord sudo is onveilig omdat het een "makkelijke" escalatie van privileges toestaat als mijn persoonlijke gebruikersaccount in gevaar wordt gebracht. Ik begrijp dat. Maar aan de andere kant, als ik een wachtwoord gebruik, lopen we alle klassieke risico's op met wachtwoorden (te kort of veel voorkomend, herhaald over verschillende diensten, enz.). Maar ik denk dat als ik wachtwoordverificatie in gebruik /etc/ssh/sshd_config zodat je nog steeds een sleutel moet hebben om in te loggen, kan ik een eenvoudiger wachtwoord gebruiken sudo dat is gemakkelijker om in te typen? Is dat een geldige strategie?

Follow-up 2

Als ik ook een sleutel heb om in te loggen als root via ssh, als iemand toegang krijgt tot mijn computer en mijn sleutels steelt (ze zijn nog steeds beschermd door het sleutelhangerwachtwoord van OS!), kunnen ze net zo goed rechtstreeks toegang krijgen tot de computer. root account, voorbijgaand aan de sudo pad. Wat moet het beleid zijn om toegang te krijgen tot de root account dan?


56
2018-03-09 21:40


oorsprong


Zou het helemaal niet aanbevelen, omdat er vaak manieren zijn om een ​​shell als gebruiker te krijgen (aangezien alle services onderhevig zijn aan beveiligingsinbreuken, maar meestal als gebruiker worden uitgevoerd om volledige toegang tot het systeem te voorkomen), maar met een wachtwoord om in te loggen als root voorkomt dat onbevoegde personen root-toegang krijgen. Als dit niet het geval is, denkt iedereen die op enigerlei manier toegang heeft tot uw gebruikersaccount, volledige toegang tot de server. Een wachtwoord instellen is misschien niet veel, maar het helpt. - piernov
Zie mijn vervolgvragen - Dmitry Pashkevich
sudo mag nooit zonder wachtwoord zijn. root moet worden uitgeschakeld door inloggen op afstand via SSH, ssh-poort zou niet standaard moeten zijn (om de dumb-bots te dumpen), en elke account die sudo nodig heeft, moet ofwel worden beperkt tot alleen de absolute minimum sudo-bevoegdheden voor wat ze nodig hebben (herstart een service alleen, enz.), en hebben ook zeer sterke wachtwoorden. - SnakeDoc
@SnakeDoc Bedankt, dat is een soort antwoord dat ik verwachtte. Wil je een gedetailleerd antwoord schrijven? Ik ben blij om te leren! - Dmitry Pashkevich
@EEAA het is eigenlijk vrij gemakkelijk in Linux. De enige accounts die in sudo met een wachtwoord mogen werken, zijn systeemaccounts waarvan men zich niet kan aanmelden en die daarom niet naar dat account kunnen worden verplaatst en die machtigingen tegen u kunnen gebruiken. Stel een valse shell in voor het account /etc/passwd zoals nologin, stel geen wachtwoord in en stel wachtwoordloos in visudo in. Als je dit doet, moet je er ook voor zorgen dat de visudo-instelling alleen voor datgene is wat dat systeemaccount absoluut nodig heeft, dat wil zeggen dat het wordt geblokkeerd tot de enige opdrachten die het ooit zou moeten uitvoeren. - SnakeDoc


antwoorden:


Ik hou van het idee om servers via sleutels te gebruiken, zodat ik dat niet moet doen   typ mijn wachtwoord elke keer dat ik in een doos schuif, ik vergrendel zelfs mijn gebruikers   (geen root) wachtwoord (passwd -l gebruikersnaam) dus het is onmogelijk om in te loggen   zonder sleutel ... Zou je aanraden / niet aanraden dit voor een te doen   gebruikersaccount op een server?

U gaat op de verkeerde manier het op een wachtwoord gebaseerde inloggen uitschakelen. Probeer in plaats van het account van een gebruiker te vergrendelen PasswordAuthentication no in uw /etc/ssh/sshd_config.

Met die set is wachtwoordverificatie uitgeschakeld voor ssh, maar je kunt nog steeds een wachtwoord gebruiken voor sudo.

De enkel en alleen tijd raad ik aan om in te stellen NOPASSWD in sudo gaat het om serviceaccounts, waarbij processen via sudo programmatisch opdrachten moeten kunnen uitvoeren. Zorg er in die omstandigheden voor dat u alleen expliciet de witte lijst opneemt specifiek opdrachten die het account moet uitvoeren. Voor interactieve accounts zou u dat moeten doen altijd laat wachtwoorden ingeschakeld.

Antwoorden op uw vervolgvragen:

Maar ik denk dat als ik wachtwoordverificatie in gebruik   / etc / ssh / sshd_config zodat je nog steeds een sleutel moet hebben om in te loggen, I   kan een eenvoudiger wachtwoord gebruiken, alleen voor sudo, dat is gemakkelijker om in te typen? is   dat een geldige strategie?

Ja dat is correct. Ik raad nog steeds aan om relatief sterke lokale accountwachtwoorden te gebruiken, maar niet belachelijk-sterk. ~ 8 tekens, willekeurig gegenereerd is voldoende.

Als ik ook een sleutel heb om in te loggen als root via ssh, als iemand dat krijgt   toegang tot mijn computer en mijn sleutels stelen (ze worden nog steeds beschermd door   OS 'sleutelring wachtwoord!), Ze kunnen net zo goed een directe toegang krijgen   naar het root-account, het sudo-pad omzeilen.

Root-toegang via ssh moet worden uitgeschakeld. Periode. set PermitRootLogin no in uw sshd_config.

Wat moet dan het beleid zijn om toegang te krijgen tot het root-account?

U moet altijd over middelen beschikken om out-of-band toegang tot de console van uw server te krijgen. Verschillende VPS-leveranciers bieden dit, net als leveranciers van speciale hardware. Als uw provider geen echte consoletoegang verleent (bijvoorbeeld EC2), kunt u doorgaans nog steeds toegang herstellen met behulp van een proces zoals wat ik in dit antwoord.


46
2018-03-09 21:48



1 moeten wachtwoorden achterlaten ... - Chris S
+1 het sudo-wachtwoord is dat niet werkelijk er voor secutiry (voor zover ik kan zien) maar meer als een idioot check. Als je daar niet zou zijn, zou je ongekende havok kunnen veroorzaken. - Boris the Spider
als je je sleutel kwijtraakt, ben je klaar, tenzij je een achterdeur hebt, maar een aanvaller ook. de enige manier om een ​​verloren sleutel te herstellen als deze goed wordt gedaan, zou zijn om fysiek aan de eigenlijke terminal te zitten. Als je het soort bescherming nodig hebt dat ssh-sleutels bieden, moet je je bewust zijn van de valkuilen en gewoon ... gewoon je sleutels niet verliezen. - SnakeDoc
Een opmerking over je laatste paragraaf, en over het verliezen van toegang in het algemeen voor een VPS ... sommige VPS-providers zullen je echt helpen als je buitengesloten raakt. Ik heb mijn VM opgestart in de Single User-modus en een aantal dingen voor me gedaan toen ik mezelf buitensloot (het gebeurt ... slechte firewallregel lol.) Afhankelijk van je host kunnen ze je kosten aanrekenen voor de service. tenslotte, speciale aandacht aan u besteedend. Ook zullen sommigen back-up / snapshots maken voor een kleine prijs of soms gratis, wat de moeite waard kan zijn als u op het punt staat een grote, mogelijk ontwrichtende verandering te plegen. - SnakeDoc
@DmitryPashkevich - betreffende PasswordAuthentication van invloed op alle gebruikers, kunt u altijd gebruiken Match sshs in sshd_config om het weer in te schakelen voor bepaalde gebruikers of groepen. - Matt Thomason


Ik beperk over het algemeen het gebruik van NOPASSWORD opdrachten die worden uitgevoerd door een geautomatiseerd proces. Het verdient de voorkeur om een ​​serviceaccount te hebben voor deze opdrachten en het gebruik van sudo tot de vereiste opdrachten te beperken.

Het toestaan NOPASSWORD voor algemene commando's, staat iedereen die toegang krijgt tot jouw userid om commando's uit te voeren. Dit kan het gevolg zijn van een compromis van uw inloggegevens, maar het kan net zo eenvoudig zijn als iemand die aan uw bureau zit als u even weggaat.

Ik merk dat ik mijn wachtwoord niet vaak hoef in te voeren. Nadat u uw wachtwoord hebt ingevoerd, kunt u verschillende opdrachten uitvoeren als u niet te lang wacht. De time-out is configureerbaar.


10
2018-03-10 00:18





Ik zou dit alleen in twee omstandigheden gebruiken:

  • Wanneer is het Absoluut vereist voor een geautomatiseerd script dat wordt uitgevoerd als een specifieke gebruiker
  • Voor specifieke beheertaken (alleen beheertaken lezen, niet die welke actie ondernemen om het systeem te wijzigen) en dan alleen voor specifieke gebruikers

Standaard de meeste sudo configuraties vragen u niet een tijdje in dezelfde sessie (als u een nieuwe shell opent die geen effect heeft). U kunt dit gedrag tot op zekere hoogte besturen met de timestamp_timeoutsetting.

Password-less sudo is lang niet zo gevaarlijk als passphrase-minder ssh sleutels, omdat een externe aanvaller je inloggegevens nodig heeft om in de eerste plaats binnen te geraken, maar als ze zijn binnengekomen door op een of andere manier je privésleutel in gevaar te brengen (of als ze fysiek lokaal voor je zijn en je jezelf hebt ingelogd en ontgrendeld terwijl je weg bent van de machine), dan is het wachtwoordverzoek een waardevolle extra verdediging tussen hen en geprivilegieerde toegang.

Betreffende follow-up 2:

Als ik ook een sleutel heb om in te loggen als root via ssh

Dit wordt ook het best vermeden, precies om de reden die u beschrijft. Als een externe verbinding een geprivilegieerde toegang moet hebben, moet deze inloggen via een serviceaccount en dat net voldoende controle geven om zijn werk te doen via sudo. Dit is meer faf om te configureren, natuurlijk doen zoveel mensen er geen moeite mee (wat in je voordeel werkt als je het doet, omdat er veel lager hangend fruit is dan dat je voor aanvallers daar kunt doorbrengen!), Dus het komt neer op de eeuwenoud compromis tussen veiligheid en gemak (pro tip: kies veiligheid!).


8
2018-03-10 09:47



Bedankt voor het beantwoorden van mijn follow-up # 2. Ik ben echter nog steeds in de war: ik probeer te voorkomen dat ik inlog als root direct, maar ik heb WELKE manier nodig om toegang te krijgen tot het account, toch? Dus hoe doe ik het dan? Met een wachtwoord, geen SSH-sleutel? Maar zijn sleutels niet beter dan wachtwoorden? - Dmitry Pashkevich
Je kunt altijd lokaal inloggen als root, maar het is aan te raden dat directe aanmeldingen om root te zijn van externe hosts (via ssh of vergelijkbaar) volledig worden uitgeschakeld. Als je een account hebt dat root kan worden via sudo (met natuurlijk een wachtwoord), dan verlies je nooit alle toegang tot het account. - David Spillett


U kunt het beste van beide werelden hebben: SSH-authenticatie voor zowel aanmelding als voor sudo. Als u de pam_ssh_agent_auth module die je kunt gebruiken SSH-sleutels om te authenticeren zonder een wachtwoord te geven als je sudo.

Ik gebruik dit al meer dan vijf jaar in de productie.

Configureer de PAM-module en voeg vervolgens een regel toe aan /etc/pam.d/sudo of het equivalent van uw systeem:

auth    sufficient     pam_ssh_agent_auth.so file=~/.ssh/authorized_keys

Als u dit doet, moet u uw sleutels op uw computer beveiligen met een wachtwoordzin. Op die manier zou iemand in je computer moeten inbraken en de sleutels moeten stelen om binnen te komen. Ze zouden dat kunnen doen door ze uit het hoofd te halen terwijl ze ontgrendeld waren als ze toegang hadden tot je account, door je wachtwoordzin te kraken of je wachtwoordzin te stelen door een keylogger of schouder surfing terwijl je het typt (kijk achter je!).

U kunt dezelfde SSH-sleutel gebruiken als om in te loggen, of u kunt een afzonderlijke sleutel instellen die u alleen toevoegt aan uw agent wanneer u sudo. Dus als u extra voorzichtig wilt zijn, kunt u een apart bestand authorized_keys onderhouden dat een afzonderlijke SSH-sleutel heeft die u alleen toevoegt aan uw agent wanneer u moet opschonen:

auth    sufficient     pam_ssh_agent_auth.so file=~/.ssh/authorized_keys_sudo

7
2018-03-12 12:34



Wauw, dat klinkt geweldig! Dus ik genereer een aparte sleutel voor het uitvoeren sudo commando's of gebruik ik dezelfde die werd gebruikt voor SSH-authenticatie? - Dmitry Pashkevich
Dit is geweldig. Ik zou je meerdere keren overstemmen als ik kon. - nyuszika7h
U kunt dezelfde sleutel gebruiken als voor normale SSH-authenticatie, of voor extra beveiliging kunt u tijdelijk een sleutel toevoegen die u gebruikt om naar uw SSH-authenticatie-agent te gaan. Hiervoor moet u een ander bestand opgeven dan ~/.ssh/authorized_keys, je zou een ander bestand kunnen beheren, ~/.ssh/authorized_keys_sudo bijvoorbeeld, of /etc/ssh/authorized_keys_sudo. - obscurerichard


Sinds je hier hebt gevraagd, hier is mijn algemene advies over hoe je de sudo kwestie.

Sudo was niet ontworpen om meer veiligheid te bieden (hoewel het in sommige opzichten mogelijk is) ... maar eerder een goed controlespoor te geven van wie wat doet op uw systeem met welke privileges.

Een goed ingestelde Sudo zal de ALL=(ALL) ALL instelling, maar eerder iets meer beperkt tot wat het specifiek is dat de gebruiker nodig heeft. Als u bijvoorbeeld een gebruiker nodig heeft om in te loggen en een vastgelopen service opnieuw te starten, hebben deze waarschijnlijk niet de mogelijkheid nodig om nieuwe software te installeren of uw server uit te schakelen, firewallregels te wijzigen, enzovoort.

Het komt soms vaak voor dat mensen sudo gebruiken om zichzelf naar het root-account te brengen, dat wil zeggen. sudo su -. Zodra ze dat doen, zie je niet meer wie wat doet vanuit het root-account (root kan meerdere keren gelijktijdig worden ingelogd). Dus soms willen mensen de. Uitschakelen sudo su -commando ook. Maar, om praktische redenen, als je een volledig root-gepriviligeerde account nodig hebt voor administratie, op zijn minst iemand die het sudo su - commando zou loggen wie verheven is om te rooten en wanneer.

Hoe ik mijn dozen beveilig:

Verander de SSH-poort in iets anders dan de standaard. Dit is om te voorkomen dat de domme bots die naar poortnummers zoeken, dan wegstampen totdat ze binnenkomen (of niet).

Geen root-aanmelding toestaan ​​via SSH met de AllowRootLogin no instellen in uw sshd_config. Hiermee wordt voorkomen dat iemand brute forceren in uw root-account. Het is over het algemeen een goede gewoonte om nooit iemand toe te staan ​​om zowel om controleredenen als voor beveiliging rechtstreeks in te loggen op het root- / beheerdersaccount. Als u rootaanmeldingen direct toestaat, weet u niet wie er is ingelogd, van wie zij het wachtwoord hebben gekregen, enz. Maar als iemand zich aanmeldt bij het account van Jimmy en vervolgens hun rechten verhoogt naar root, heeft u een beter idee waar u uw audit zoeken (en wie zijn account moet opnieuw instellen).

Sta gebruikers alleen toe aan SSH die dit vereisen Gebruik de AllowUsers instelling en expliciteit specificeer welke accounts SSH-toegang nodig hebben. Dit blokkeert standaard alle andere accounts van SSH.

Bewerk Sudoers via visudo en laat alleen de opdrachten toe die de gebruiker nodig heeft. Er zijn veel gedetailleerde handleidingen over hoe je dit moet doen, dus ik zal hier niet in detail beschrijven. Hier is een starter: http://ubuntuforums.org/showthread.php?t=1132821

De essentie hiervan is om te voorkomen dat een gecompromitteerd account uw machine in gevaar brengt. d.w.z. als Sally's account wordt ingebroken en Sally alleen sudo kan gebruiken om de webserver opnieuw te starten, heeft de aanvaller misschien lol met het opnieuw opstarten van uw webserver in een lus, maar ze kunnen in elk geval niet rm -rf /your/webserver/directory of open al uw firewallpoorten, enz.

Stel goede firewallregels in die alleen de poorten toestaan ​​die nodig zijn om uw box te laten werken. Over het algemeen wil je alles laten vallen en alleen expliciet toestaan ​​wat je nodig hebt. Er zijn voldoende fatsoenlijke iptables en andere firewalls beginnen online, hier is er een die ik gebruik (het is een basisstart):

# Generated by iptables-save v1.4.7 on Mon Mar  3 17:55:02 2014
*filter
:INPUT DROP [4528:192078]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [39845:27914520]
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -m state --state NEW -j DROP
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 4254 -m state --state NEW -j ACCEPT
-A INPUT -p tcp -m tcp --dport 8080 -m state --state NEW -j ACCEPT
-A INPUT -p tcp -m tcp --dport 8443 -m state --state NEW -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 11 -j ACCEPT
-A OUTPUT -o lo -j ACCEPT
COMMIT
# Completed on Mon Mar  3 17:55:02 2014

Een sterk wachtwoord is ook de sleutel. Zelfs als je SSH-sleutels gebruikt voor je externe toegang, moet je nog steeds een wachtwoord voor Sudo-gebruik nodig hebben. Dit is een geval waarin sudo wat meer veiligheid zou kunnen bieden. Als iemand je ssh-sleutels zou stelen, zou het hem nog steeds worden belet om iets belangrijks op je kist te doen als ze je wachtwoord nog steeds bruut moeten forceren om sudo te gebruiken. Wachtwoorden mogen geen woord zijn, maar eerder een wachtwoordzin. Denk aan een zin en gebruik die. Hierdoor krijg je meestal iets meer dan acht tekens lang, waardoor je veel entropie krijgt, maar het is ook makkelijker te onthouden dan een willekeurig wachtwoord. Natuurlijk zeggen goede wachtwoordpraktijken dat je een door een machine gegenereerd willekeurig wachtwoord gebruikt om gekraakprogramma's zoals John the Ripper voor de gek te houden, die door de meeste wachtzinnen en wachtwoorden gaan. Nee, het veranderen van E met 3 werkt niet, John krijgt die permutaties ook.


5
2018-03-10 19:54



Bedankt voor een uitgebreid antwoord! Ik moet absoluut al deze adviezen gebruiken om mijn dozen te beveiligen. Ik accepteer nog steeds het antwoord van EEAA, omdat het wat specifieker is voor wat ik vroeg. - Dmitry Pashkevich
@DmitryPashkevich dat is OK, EEAA heeft een goed en passend antwoord. Je vroeg me om mijn opmerking hierboven te beschrijven, dus dat deed ik. Maak je geen zorgen :) - SnakeDoc
Wat betreft sudo su - en variaties, sudoreplay kan van pas komen. - nyuszika7h


In sommige gevallen is het noodzakelijk om dit te doen. bijv. sommige hypervisor-API's hebben wachtwoordloze login en wachtwoordloos nodig sudo. Maar je kunt dat nog steeds beperken zonder te breken.

Voor wat je probeert te bereiken. Ik zou zeggen, wen er aan om een ​​wachtwoord in te typen. Beveiliging is handiger dan gemak hier. Trouwens, als je echt root-toegang nodig hebt die je kunt gebruiken sudo en het zal de referenties voor een korte tijd in de cache opslaan, zodat als je meerdere sudo-commando's achter elkaar uitvoert, het de eerste keer alleen om het wachtwoord vraagt. Het is dus niet zo'n groot ongemak als je denkt.

Ook als je veel root-gepriviligeerde commando's invoert en niet de hele tijd sudo op de voorgrond wilt zetten, kun je su of sudo -s om een ​​rootshell te krijgen. U zult één keer uw wachtwoord invoeren en dan is dat het.


3
2018-03-10 03:18





Ik ben een keer gebeten door een wachtwoordloze sudo. Het was een shellscript, een installatieprogramma dat genaamd sudo namens mij in tegenstelling tot, weet je, gewoon sudo of fouten nodig hebben.

Imaging typ 'make' en het script doet het 'sudo make install'-gedeelte voor u, zonder het basistraject in te stellen of weer te geven, en het script is zo braindead in de eerste plaats dat u niet zeker weet of ze over / usr / local weten en dus begin je / usr te controleren op wijzigingen ...

Ik beloofde om NOPASSWD nooit meer te gebruiken en veranderde die time-outinstelling ook in 0.


2
2017-10-17 00:05





Hoewel u uw vraag niet strikt beantwoordt, is een andere optie wellicht om een ​​langere periode in te stellen timestamp_timeout u hoeft dus niet zo vaak uw wachtwoord in te typen. Hiermee wordt voorkomen dat alleen iemand beheerdersrechten krijgt, maar uw ergernis vermindert.

Van de sudoers man pagina:

timestamp_timeout

Aantal minuten dat kan verstrijken voordat sudo opnieuw om een ​​passwd vraagt. De time-out kan een fractionele component omvatten als de minutieuze granulariteit onvoldoende is,   bijvoorbeeld 2,5. De standaardinstelling is 5. Stel dit in op 0 om altijd om een ​​wachtwoord te vragen. Als deze is ingesteld op een waarde van minder dan 0, verloopt de tijdstempel van de gebruiker nooit. Deze   kan worden gebruikt om gebruikers toe te staan ​​hun eigen tijdstempels te creëren of te verwijderen via respectievelijk "sudo -v" en "sudo -k".

Dit blogbericht toont enkele voorbeelden gebruik makend van visudo om de time-out in minuten in te stellen, zoals:

Defaults timestamp_timeout=60

Misschien is dit een gelukkige middenweg tussen veiligheid en gebruiksgemak?


1
2017-09-05 03:52



Bedankt voor de input! Mijn oorspronkelijke vraag was dat ik helemaal geen wachtwoord hoefde te gebruiken (en niet hoef te onthouden), omdat je sleutels kunt gebruiken om op de machine te sshennen, en niet hoe vaak ik het moet invoeren. Andere mensen hebben duidelijk gemaakt dat dat een slecht idee is. - Dmitry Pashkevich