Meerfactorauthenticatie instellen voor SSH op CentOS 7

Inleiding

Een authenticatiefactor is een enkel stukje informatie dat wordt gebruikt om te bewijzen dat u de rechten hebt om een actie uit te voeren, zoals inloggen op een systeem. Een authenticatiekanaal is de manier waarop een authenticatiesysteem een factor aan de gebruiker levert of de gebruiker vraagt te antwoorden. Wachtwoorden en beveiligingstokens zijn voorbeelden van authenticatiefactoren; computers en telefoons zijn voorbeelden van kanalen.

SSH gebruikt standaard wachtwoorden voor authenticatie, en de meeste SSH-verhardingsinstructies raden aan om in plaats daarvan een SSH-sleutel te gebruiken. Dit is echter nog steeds slechts een enkele factor. Als een slechte actor uw computer heeft gecompromitteerd, dan kunnen ze uw sleutel gebruiken om ook uw servers te compromitteren.

In deze handleiding zullen we multi-factor authenticatie instellen om dat tegen te gaan. Multi-factor authenticatie (MFA) vereist meer dan een factor om te authenticeren, of in te loggen. Dit betekent dat een slechte actor meerdere dingen zou moeten compromitteren, zoals zowel uw computer als uw telefoon, om binnen te geraken. De verschillende soorten factoren worden vaak als volgt samengevat:

1. Iets wat u weet, zoals een wachtwoord of beveiligingsvraag
2. Iets wat u heeft, zoals een authenticatie-app of beveiligingstoken
3. Iets wat u bent, zoals uw vingerafdruk of stem

Eén gemeenschappelijke factor is een OATH-TOTP-app, zoals Google Authenticator. OATH-TOTP (Open Authentication Time-Based One-Time Password) is een open protocol dat een eenmalig te gebruiken wachtwoord genereert, meestal een 6-cijferig getal dat elke 30 seconden wordt gerecycled.

Dit artikel zal ingaan op hoe SSH-authenticatie mogelijk te maken met behulp van een OATH-TOTP-app in aanvulling op een SSH-sleutel. Inloggen op uw server via SSH vereist dan twee factoren over twee kanalen, waardoor het veiliger is dan een wachtwoord of SSH-sleutel alleen. Daarnaast zullen we enkele aanvullende gebruikssituaties voor MFA en enkele handige tips en trucs bespreken.

Voorvereisten

Om deze tutorial te volgen, heb je nodig:

• Een CentOS 7 server met een sudo non-root gebruiker en SSH sleutel, die je kunt instellen door deze Initial Server Setup tutorial te volgen.
• Een smartphone of tablet met een OATH-TOTP app geïnstalleerd, zoals Google Authenticator (iOS, Android).

Stap 1 – Google’s PAM installeren

In deze stap installeren en configureren we Google’s PAM.

PAM, wat staat voor Pluggable Authentication Module, is een authenticatie-infrastructuur die op Linux-systemen wordt gebruikt om een gebruiker te authenticeren. Omdat Google een OATH-TOTP-app heeft gemaakt, hebben ze ook een PAM gemaakt die TOTP’s genereert en volledig compatibel is met elke OATH-TOTP-app, zoals Google Authenticator of Authy.

Eerst moeten we de EPEL (Extra Packages for Enterprise Linux) repo toevoegen.

sudo yum install https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm

Volgende, installeer de PAM. U kunt gevraagd worden om de EPEL sleutel te accepteren als dit de eerste keer is dat u de repo gebruikt. Eenmaal geaccepteerd zal u niet meer worden gevraagd om de sleutel te accepteren.

sudo yum install google-authenticator

Met de PAM geïnstalleerd, zullen we een helper app gebruiken die met de PAM wordt meegeleverd om een TOTP sleutel te genereren voor de gebruiker aan wie u een tweede factor wilt toevoegen. Deze sleutel wordt per gebruiker gegenereerd, niet voor het hele systeem. Dit betekent dat iedere gebruiker die een TOTP auth app wil gebruiken, moet inloggen en de helper app moet draaien om zijn eigen sleutel te krijgen; je kunt het niet één keer draaien om het voor iedereen in te schakelen (maar er zijn wat tips aan het eind van deze tutorial om MFA voor veel gebruikers in te stellen of te verplichten).

Draai de initialisatie app.

google-authenticator

Nadat je het commando hebt gedraaid, worden je een paar vragen gesteld. De eerste vraagt of de authenticatie tokens op tijd gebaseerd moeten zijn.

Output
Do you want authentication tokens to be time-based (y/n) y

Deze PAM staat tijdgebaseerde of sequentiegebaseerde tokens toe. Het gebruik van sequentieel-gebaseerde tokens betekent dat de code op een bepaald punt begint en dan de code na elk gebruik verhoogt. Tijd-gebaseerde tokens betekent dat de code willekeurig verandert nadat een bepaalde tijd verstreken is. We houden het bij tijdgebaseerd omdat dat is waar apps zoals Google Authenticator op anticiperen, dus antwoord y voor ja.

Na het beantwoorden van deze vraag, zal er een heleboel output voorbij scrollen, inclusief een grote QR code. Gebruik op dit punt uw authenticator app op uw telefoon om de QR code te scannen of typ handmatig de geheime sleutel in. Als de QR-code te groot is om te scannen, kun je de URL boven de QR-code gebruiken om een kleinere versie te krijgen. Zodra het is toegevoegd, ziet u een zes-cijferige code die elke 30 seconden verandert in uw app.

Note: Zorg ervoor dat u de geheime sleutel, verificatie code, en de herstelcodes op een veilige plaats opslaat, zoals een wachtwoord manager. De herstelcodes zijn de enige manier om weer toegang te krijgen als u bijvoorbeeld de toegang tot uw TOTP app verliest.

De resterende vragen vertellen de PAM hoe te functioneren. We zullen ze een voor een doornemen.

Output
Do you want me to update your "/home/sammy/.google_authenticator" file (y/n) y

Dit schrijft de sleutel en opties naar het .google_authenticator bestand. Als u nee zegt, stopt het programma en wordt er niets geschreven, wat betekent dat de authenticator niet zal werken.

Output
Do you want to disallow multiple uses of the same authenticationtoken? This restricts you to one login about every 30s, but it increasesyour chances to notice or even prevent man-in-the-middle attacks (y/n) y

Door hier ja te antwoorden, voorkomt u een replay-aanval door elke code onmiddellijk na gebruik te laten verlopen. Dit voorkomt dat een aanvaller een zojuist gebruikte code kan bemachtigen en daarmee kan inloggen.

Output
By default, tokens are good for 30 seconds. In order to compensate forpossible time-skew between the client and the server, we allow an extratoken before and after the current time. If you experience problems withpoor time synchronization, you can increase the window from its defaultsize of +-1min (window size of 3) to about +-4min (window size of 17 acceptable tokens). Do you want to do so? (y/n) n

Als u hier ja antwoordt, kunt u maximaal 8 geldige codes in een bewegend venster van vier minuten gebruiken. Door nee te antwoorden, beperkt u het tot 3 geldige codes in een voortschrijdend venster van 1:30 minuten. Tenzij u problemen ondervindt met het venster van 1:30 minuten, is nee de veiligste keuze.

Output
If the computer that you are logging into isn't hardened against brute-forcelogin attempts, you can enable rate-limiting for the authentication module.By default, this limits attackers to no more than 3 login attempts every 30s.Do you want to enable rate-limiting (y/n) y

Rate limiting betekent dat een aanvaller op afstand slechts een bepaald aantal pogingen kan doen voordat hij geblokkeerd wordt. Als u nog niet eerder snelheidslimieten direct in SSH heeft ingesteld, dan is dat nu doen een goede beveiligingstechniek.

Note: Als u klaar bent met deze instelling en u wilt een back-up van uw geheime sleutel maken, dan kunt u het ~/.google-authenticator bestand naar een vertrouwde locatie kopiëren. Vanaf daar kunt u het op additionele systemen implementeren of opnieuw implementeren na een backup.

Nu dat Google’s PAM is geïnstalleerd en geconfigureerd, is de volgende stap het configureren van SSH om uw TOTP sleutel te gebruiken. We moeten SSH vertellen over de PAM en dan configureren dat SSH hem gebruikt.

Step 2 – OpenSSH configureren

Omdat we SSH wijzigingen over SSH zullen maken, is het belangrijk om nooit uw initiële SSH verbinding te sluiten. Open in plaats daarvan een tweede SSH-sessie om te testen. Dit is om te vermijden dat je jezelf uitsluit van je server als er een fout is gemaakt in je SSH configuratie. Als alles eenmaal werkt, dan kunt u veilig alle sessies afsluiten.

Om te beginnen gaan we het sshd configuratie bestand bewerken. Hier gebruiken we nano, dat standaard niet geïnstalleerd is op CentOS. U kunt het installeren met sudo yum install nano, of uw favoriete alternatieve tekst editor gebruiken.

sudo nano /etc/pam.d/sshd

Voeg de volgende regel toe aan de onderkant van het bestand.

. . .# Used with polkit to reauthorize users in remote sessions-session optional pam_reauthorize.so prepareauth required pam_google_authenticator.so nullok

Het nullok woord aan het eind van de laatste regel vertelt de PAM dat deze authenticatie methode optioneel is. Hierdoor kunnen gebruikers zonder een OATH-TOTP token toch inloggen met hun SSH sleutel. Zodra alle gebruikers een OATH-TOTP token hebben, kunt u nullok van deze regel verwijderen om MFA verplicht te maken.

Bewaar en sluit het bestand.

Volgende, we zullen SSH configureren om deze vorm van authenticatie te ondersteunen. Open het SSH configuratie bestand om het te bewerken.

sudo nano /etc/ssh/sshd_config

Zoek naar ChallengeResponseAuthentication regels. Commentarieer de no regel uit en maak het commentaar op de no regel ongedaan.

. . .# Change to no to disable s/key passwordsChallengeResponseAuthentication yes#ChallengeResponseAuthentication no. . .

Bewaar en sluit het bestand, herstart dan SSH om de configuratie bestanden opnieuw te laden. Het herstarten van de sshd service zal geen open verbindingen sluiten, dus u loopt niet het risico om uzelf buiten te sluiten met dit commando.

sudo systemctl restart sshd.service

Om te testen of alles tot nu toe werkt, opent u een andere terminal en probeert u in te loggen over SSH. Als je eerder een SSH sleutel hebt aangemaakt en deze gebruikt, zul je merken dat je het wachtwoord van je gebruiker of de MFA verificatie code niet hoeft in te typen. Dit komt omdat een SSH sleutel standaard alle andere authenticatie opties opheft. Anders had je een wachtwoord en verificatie code prompt moeten krijgen.

Als je zeker wilt weten dat wat je tot nu toe hebt gedaan werkt, navigeer dan in je open SSH sessie naar ~/.ssh/ en hernoem het bestand authorized_keys, tijdelijk, en open een nieuwe sessie en log in met ons wachtwoord en verificatie code.

 
cd ~/.ssh
 
mv authorized_keys authorized_keys.bak
 

Als je eenmaal hebt geverifieerd dat je TOTP token werkt, hernoem dan het bestand ‘authorized_keys.bak’ bestand terug naar wat het was.

mv authorized_keys.bak authorized_keys

Volgende, we moeten een SSH sleutel inschakelen als een factor en de verificatie code als een tweede en SSH vertellen welke factoren te gebruiken en voorkomen dat de SSH sleutel alle andere types overruled.

Step 3 – SSH bewust maken van MFA

Open het sshd configuratie bestand.

sudo nano /etc/ssh/sshd_config

Voeg de volgende regel toe onderaan het bestand. Dit vertelt SSH welke authenticatie methoden nodig zijn. Deze regel vertelt SSH dat we een SSH sleutel nodig hebben en of een wachtwoord of een verificatie code (of alle drie).

. . .# Added by DigitalOcean build processClientAliveInterval 120ClientAliveCountMax 2AuthenticationMethods publickey,password publickey,keyboard-interactive

Bewaar en sluit het bestand.

Volgende, open het PAM sshd configuratie bestand opnieuw.

sudo nano /etc/pam.d/sshd

Zoek de regel auth substack password-auth bovenin het bestand. Commentarieer deze door een # karakter toe te voegen als het eerste karakter op de lijn. Dit vertelt PAM om niet om een wachtwoord te vragen.

. . .#auth substack password-auth. . .

Bewaar en sluit het bestand, herstart dan SSH.

sudo systemctl restart sshd.service

Probeer nu opnieuw in te loggen op de server met een andere sessie. In tegenstelling tot de vorige keer, zou SSH om uw verificatie code moeten vragen. Als u die invoert, bent u ingelogd. Ook al zie je geen indicatie dat je SSH sleutel is gebruikt, je login poging heeft twee factoren gebruikt. Als u dit wilt verifiëren, kunt u -v (voor verbose) toevoegen na het SSH commando:

Example SSH output\
. . .debug1: Authentications that can continue: publickeydebug1: Next authentication method: publickeydebug1: Offering RSA public key: /Users/sammy/.ssh/id_rsadebug1: Server accepts key: pkalg ssh-rsa blen 279Authenticated with partial success.debug1: Authentications that can continue: keyboard-interactivedebug1: Next authentication method: keyboard-interactiveVerification code:

Tegen het einde van de uitvoer, zult u zien dat SSH uw SSH sleutel gebruikt en dan om de verificatie code vraagt. U kunt nu inloggen over SSH met een SSH sleutel en een eenmalig wachtwoord. Als u alle drie de authenticatie types wilt afdwingen, kunt u de volgende stap volgen.

Stap 4 – Een derde factor toevoegen (optioneel)

In stap 3 hebben we in het sshd_config bestand de toegestane typen authenticatie opgesomd:

1. publickey (SSH-sleutel)
2. password publickey (wachtwoord)
3. keyboard-interactive (verificatiecode)

Hoewel we drie verschillende factoren hebben vermeld, met de opties die we tot nu toe hebben gekozen, laten ze alleen een SSH-sleutel en de verificatiecode toe. Als u alle drie de factoren wilt hebben (SSH-sleutel, wachtwoord en verificatiecode), kunt u ze met een snelle wijziging alle drie inschakelen.

Open het PAM sshd configuratiebestand.

sudo nano /etc/pam.d/sshd

Localiseer de regel die u eerder hebt uitgecommentarieerd, #auth substack password-auth, en maak het commentaar ongedaan door het # teken te verwijderen. Sla het bestand op en sluit het. Start nu SSH opnieuw op.

sudo systemctl restart sshd.service

Door de optie auth substack password-auth aan te zetten, zal PAM nu om een wachtwoord vragen in aanvulling op het controleren op een SSH sleutel en het vragen om een verificatie code, die we eerder werkten. Nu kunnen we iets gebruiken dat we weten (wachtwoord) en twee verschillende soorten dingen die we hebben (SSH-sleutel en verificatiecode) over twee verschillende kanalen.

Dit artikel heeft tot nu toe beschreven hoe u MFA kunt inschakelen met een SSH-sleutel en een tijd-gebaseerd eenmalig wachtwoord. Als dit alles is wat u nodig heeft, kunt u hier stoppen. Echter, dit is niet de enige manier om multi-factor authenticatie te doen. Hieronder staan een paar extra manieren om deze PAM module te gebruiken voor multi-factor authenticatie en wat tips en trucs voor herstel, geautomatiseerd gebruik, en meer.

Tip 1 – Toegang herstellen

Zoals met elk systeem dat u verhardt en beveiligt, wordt u verantwoordelijk voor het beheer van die beveiliging. In dit geval betekent dat het niet verliezen van je SSH sleutel of je TOTP geheime sleutel en ervoor zorgen dat je toegang hebt tot je TOTP app. Maar soms gebeuren er dingen, en kun je de controle verliezen over de sleutels of apps die je nodig hebt om binnen te komen.

Verlies van een SSH sleutel of TOTP geheime sleutel

Als je je SSH sleutel of TOTP geheime sleutel verliest, kan het herstel worden opgesplitst in een paar stappen. De eerste is om weer in te loggen zonder de verificatiecode te kennen en de tweede is het vinden van de geheime sleutel of het regenereren ervan voor normale MFA login.

Om in te loggen na het verlies van de geheime sleutel die de verificatiecode genereert op een DigitalOcean Droplet, kunt u gewoon de virtuele console van uw dashboard gebruiken om in te loggen met uw gebruikersnaam en wachtwoord.

Of anders hebt u een administratieve gebruiker nodig die sudo-toegang heeft; zorg ervoor dat u MFA niet inschakelt voor deze gebruiker, maar gebruik alleen een SSH-sleutel. Als jij of een andere gebruiker zijn geheime sleutel verliest en niet kan inloggen, dan kan de administratieve gebruiker inloggen en helpen met het herstellen of regenereren van de sleutel voor elke gebruiker die sudo gebruikt.

Als u eenmaal bent ingelogd, zijn er twee manieren om te helpen het TOTP geheim te krijgen:

1. De bestaande sleutel herstellen
2. Een nieuwe sleutel genereren

In de homedirectory van elke gebruiker worden de geheime sleutel en de Google Authenticator instellingen opgeslagen in ~/.google-authenticator. De allereerste regel van dit bestand is een geheime sleutel. Een snelle manier om de sleutel te achterhalen is door het volgende commando uit te voeren, dat de eerste regel van het bestand google-authenticator weergeeft (d.w.z. de geheime sleutel). Neem vervolgens die geheime sleutel en typ hem handmatig in een TOTP app.

head -n 1 /home/sammy/.google_authenticator

Als er een reden is om de bestaande sleutel niet te gebruiken (bijvoorbeeld omdat het niet mogelijk is om de geheime sleutel op een veilige manier te delen met de gebruiker of omdat de bestaande sleutel gecompromitteerd is), kunt u het ~/.google-authenticator bestand volledig verwijderen. Dit zal de gebruiker toelaten om opnieuw in te loggen met slechts één factor, in de veronderstelling dat je MFA niet hebt afgedwongen door ‘nullok’ te verwijderen in het ‘/etc/pam.d/sshd’ bestand. Ze kunnen dan google-authenticator uitvoeren om een nieuwe sleutel te genereren.

Toegang tot de TOTP App

Als u moet inloggen op uw server maar geen toegang hebt tot uw TOTP app om uw verificatiecode te krijgen, kunt u nog steeds inloggen met de herstelcodes die werden weergegeven toen u uw geheime sleutel voor het eerst aanmaakte. Let op: deze herstelcodes zijn eenmalig te gebruiken. Eenmaal gebruikt om in te loggen, kan het niet opnieuw worden gebruikt als verificatie code.

Tip 2 – Veranderen van Authenticatie Instellingen

Als u uw MFA instellingen wilt veranderen na de initiële configuratie, in plaats van het genereren van een nieuwe configuratie met de bijgewerkte instellingen, kunt u gewoon het ~/.google-authenticator bestand bewerken. Dit bestand is op de volgende manier ingedeeld:

<secret key><options><recovery codes>

Opties die in dit bestand zijn ingesteld, hebben een regel in de sectie opties; als u tijdens de eerste installatie “nee” hebt geantwoord op een bepaalde optie, wordt de bijbehorende regel uit het bestand geweerd.

Dit zijn de wijzigingen die u in dit bestand kunt aanbrengen:

• Om sequentiële codes in plaats van tijdgebaseerde codes in te schakelen, wijzigt u de regel " TOTP_AUTH in " HOTP_COUNTER 1.
• Om meerdere keren gebruik van een enkele code toe te staan, verwijdert u de regel " DISALLOW_REUSE.
• Om de codevervaltijd te verlengen tot 4 minuten, voegt u de regel " WINDOW_SIZE 17 toe.
• Om meervoudig mislukte aanmeldingen (rate limiting) uit te schakelen, verwijdert u de regel " RATE_LIMIT 3 30.
• Om de drempel van rate limiting te wijzigen, zoekt u de regel " RATE_LIMIT 3 30 en past u de getallen aan. De 3 in het origineel geeft het aantal pogingen aan over een periode van tijd, en de 30 geeft de periode aan in seconden.
• Om het gebruik van herstel codes uit te schakelen, verwijdert u de vijf 8 cijferige codes onderaan het bestand.

Tip 3 – MFA vermijden voor sommige accounts

Er kan zich een situatie voordoen waarin een enkele gebruiker of een paar serviceaccounts (d.w.z. accounts die door applicaties worden gebruikt, niet door mensen) SSH-toegang nodig hebben zonder dat MFA is ingeschakeld. Bijvoorbeeld, sommige toepassingen die SSH gebruiken, zoals sommige FTP clients, ondersteunen geen MFA. Als een applicatie geen manier heeft om de verificatie code te vragen, kan het verzoek blijven hangen totdat de SSH verbinding time out.

Zolang een paar opties in /etc/pam.d/sshd correct zijn ingesteld, kunt u bepalen welke factoren worden gebruikt op een gebruiker-per-gebruiker basis.

Om MFA voor sommige accounts toe te staan en alleen SSH-sleutels voor anderen, moet u ervoor zorgen dat de volgende instellingen in /etc/pam.d/sshd actief zijn.

#%PAM-1.0auth required pam_sepermit.so#auth substack password-auth. . .# Used with polkit to reauthorize users in remote sessions-session optional pam_reauthorize.so prepareauth required pam_google_authenticator.so nullok

Hier is auth substack password-auth uitgecommentarieerd omdat wachtwoorden moeten worden uitgeschakeld. MFA kan niet worden geforceerd als sommige accounts bedoeld zijn om MFA uitgeschakeld te hebben, dus laat de nullok optie op de laatste regel staan.

Nadat u deze configuratie hebt ingesteld, voert u google-authenticator gewoon uit voor alle gebruikers die MFA nodig hebben, en voert u het niet uit voor gebruikers waar alleen SSH-sleutels zullen worden gebruikt.

Tip 4 – Setup automatiseren met Configuratie Management

Veel systeembeheerders gebruiken configuratie management tools, zoals Puppet, Chef, of Ansible, om hun systemen te beheren. Als u zo’n systeem wilt gebruiken om een geheime sleutel in te stellen wanneer een nieuwe gebruikersaccount wordt aangemaakt, is er een methode om dat te doen.

google-authenticator ondersteunt opdrachtregel-switches om alle opties in te stellen in een enkele, niet-interactieve opdracht. Om alle opties te zien, kunt u google-authenticator --help typen. Hieronder staat het commando dat alles zou instellen zoals beschreven in stap 1:

google-authenticator -t -d -f -r 3 -R 30 -W

Dit beantwoordt alle vragen die we handmatig hebben beantwoord, slaat het op in een bestand, en geeft vervolgens de geheime sleutel, QR-code en herstelcodes. (Als u de vlag -q toevoegt, dan zal er geen uitvoer zijn.) Als u dit commando op een geautomatiseerde manier gebruikt, zorg er dan voor dat u de geheime sleutel en/of herstelcodes vastlegt en beschikbaar stelt aan de gebruiker.

Tip 5 – MFA forceren voor alle gebruikers

Als u MFA voor alle gebruikers wilt forceren, zelfs bij de eerste login, of als u er liever niet op vertrouwt dat uw gebruikers hun eigen sleutels genereren, dan is er een eenvoudige manier om dit te doen. U kunt eenvoudigweg hetzelfde .google-authenticator bestand voor iedere gebruiker gebruiken, aangezien er geen gebruiker-specifieke gegevens in het bestand zijn opgeslagen.

Om dit te doen, nadat het configuratiebestand initieel is aangemaakt, moet een bevoorrechte gebruiker het bestand naar de root van iedere thuismap kopiëren en de rechten ervan wijzigen naar de juiste gebruiker. Het bestand kan ook naar /etc/skel/ worden gekopieerd, zodat het automatisch naar de thuismap van een nieuwe gebruiker wordt gekopieerd als deze wordt aangemaakt.

Waarschuwing: Dit kan een veiligheidsrisico zijn omdat iedereen dezelfde tweede factor deelt. Dit betekent dat als het uitlekt, het net is alsof iedere gebruiker maar één factor heeft. Houd hier rekening mee als u deze aanpak wilt gebruiken.

Een andere methode om het aanmaken van de geheime sleutel van een gebruiker te forceren, is het gebruik van een bash-script dat:

1. Een TOTP-token aanmaakt,
2. Draagt hen op om de Google Authenticator-app te downloaden en de QR-code te scannen die wordt weergegeven, en
3. Draait de google-authenticator-applicatie voor hen nadat is gecontroleerd of het .google-authenticator-bestand al bestaat.

Om ervoor te zorgen dat het script wordt uitgevoerd wanneer een gebruiker inlogt, kunt u het .bash_login noemen en het in de root van hun home directory plaatsen.

Conclusie

Dat gezegd hebbende, door twee factoren te hebben (een SSH sleutel + MFA token) over twee kanalen (uw computer + uw telefoon), hebt u het erg moeilijk gemaakt voor een externe agent om met brute kracht uw machine binnen te dringen via SSH en hebt u de veiligheid van uw machine enorm verhoogd.