SSH-PKA-Servertoegang
Sinds eind 2014 maak ik voor servertoegang, gebruik van secure shell public key authenticatie (SSH-PKA), oftewel secure shell public key encryption (SSH-PKE), secure shell key pair authentication (SSH-KPA), secure shell key pair encryption/authentication (SSH-KPE, SSH-KPA). Sinds 2020 ben ik niet meer de enige met toegang tot deze servers.
Wat?
Uitsluitend SSH
Toegang tot de servers (anders dan als gebruiker of beheerder van websites), gaat uitsluitend via SSH - Dus geen FTP, Telnet, PhpMyAdmin, Plesk, andere webbased-consoles, of wat dan ook. De mogelijkheden om in te breken worden daarmee drastisch beperkt. Oh ja: Sites kunnen daarnaast niet zichzelf updaten, dus dat scheelt ook weer een risico.
Drie niveaus
Authenticatie vindt op drie niveaus plaats:
- Computer-account op de betreffende server
- Publieke sleutel-authenticatie
- Host-fingerprint-authenticatie.
Waarom?
Da's een stuk veiliger dan inloggen middels alleen een inlognaam+wachtwoord:
- Het is veel lastiger om een publieke sleutel en/of een host fingerprint te kraken dan een inlognaam-wachtwoord-combinatie, laat staan alle drie tegelijkertijd
- Minder gevoelig voor DDOS-aanvallen.
Aanpak
We willen een gebruiker toegang geven tot een server, vanaf een bepaalde computer:
- Maak een account aan voor de gebruiker op de server → Accounts (Linux), Mappen, bestanden & rechten - 2020 (WordPress)
- Upload de publieke sleutel van de gebruiker van de betreffende computer naar zijn/haar account op de server
- Creëer aliassen op de client-computer waarvan er wordt ingelogd
- Test.
Sleutelbeheer
Ik doe sleutelbeheer niet al te vaak, vandaar dat dit hoofdstuk vrij uitgebreid is.
Sleutels aanmaken op werkstation
Kijk of er een map ~/.ssh
is met daarin deze bestanden:
id_rsa
Privésleutelid_rsa.pub
- Publieke sleutel
Als deze er niet zijn, genereer ze dan als volgt:
ssh-keygen
Een impressie van een publieke sleutel (id_rsa.pub
):
ssh-rsa 123444NzaC1yc2EAAAADAQABAAABAQC4edJFZI/VPvfdsjlfdsjfdslfjdslwe1e32239874-1231re31232432KBjl EBvpSrA3EQ3/EOUmg9viPHJF6k+myREc++std+lI3Lem2b+miVakInAGj0+nCofX8gLSRWPXOEpL7e/KW8sfXnqOfeHl8paCgJM gJKCXNBTNPEvixV/SDkeVYmaratJxHpqB7rFmA9Vfs0PyZ/haqXtierIkLsopFfHzCGUcV6fO8uOMYh+v2yz2z3qeUrg6oQp1oJ bBV6B999/rIjtLzvOm1h8swqRt89kcCKqurntyddsNQtZ+YXM0AUZ/dtUrmQ6o9fREvAYRfdjfklsfjdks strompf@dell2016
Een impressie van een privé-sleutel (id_rsa
):
-----BEGIN RSA PRIVATE KEY----- Proc-Type: 4,ENCRYPTED x DEK-Info: AES-128-CBC,12121212123442297DF26D3BA8FCABC1 fdjkl29Jlfds893lfdslDXAWGUMLQD+A2OebT1u6f5lL9mG5CjTbs5RBMqW5m7YL i9S16ry2U173TbtZQfdsfdsaqwes1323xSUdi4h5I2ppkfzqx8WM3XYLZl8gIkuB P+vltsCQGRQWbBuGohNtukSxcu3lVnRasZ/DMksoszHPwlUH53TcwN4Cm7IavRtL i9S16ry2U173TbtZQfdsfdsaqwes1323xSUdi4h5I2ppkfzqx8WM3XYLZl8gIkuB fdjkl29Jlfds893lfdslDXAWGUMLQD+A2OebT1u6f5lL9mG5CjTbs5RBMqW5m7YL 6C8/hp0xM/uy0g2Hu7SxNjWNAsRIXgssLKIaJ7B8GFA6ZFgVMoiSu0QJtmlD3IiR i9S16ry2U173TbtZQfdsfdsaqwes1323xSUdi4h5I2ppkfzqx8WM3XYLZl8gIkuB 2EUpvmvc+ra+4v89kJlCAuqce1YdtJxGUt8KR5INFPrE66q2/TcktUkujEy7R7m2 J4ozpYRfDgNZYHz02pE0Ha0ZfcNZhFghlNaU/tplidiFvzrJQ/k/F/qJs8X+R5np fdjkl29Jlfds893lfdslDXAWGUMLQD+A2OebT1u6f5lL9mG5CjTbs5RBMqW5m7YL k3WDLCIWaI6pHOl/ODRkSZBo7GJ1qukt4idTdRXQuCqLCxLjuVw5wlqs2QOcioyO cbOfya5fCmX5BeT5l2Q0YxwXB94Oe0tOftevmEIz6QQ8BzMEIIUU6Jnf72QwYvsn aevbhwrJ5El5YtB7iZLLooHUHQ4E6rVxcXUNCZgLWIng3OXGztd/OMPrIB5fOC6K i9S16ry2U173TbtZQfdsfdsaqwes1323xSUdi4h5I2ppkfzqx8WM3XYLZl8gIkuB fdjkl29Jlfds893lfdslDXAWGUMLQD+A2OebT1u6f5lL9mG5CjTbs5RBMqW5m7YL PtRONqsq5d7nS0s65AILS5ZI294DiLVXFr3vkN9Tb52Zmx/XK8iNo0e0VeUwVlP9 PmACYqctSlcZAHSX/31cyQs6kFqHvrldSZD4hFqVb65RI1aGHD/qmPb3B219mnvx fdjkl29Jlfds893lfdslDXAWGUMLQD+A2OebT1u6f5lL9mG5CjTbs5RBMqW5m7YL fdjkl29Jlfds893lfdslDXAWGUMLQD+A2OebT1u6f5lL9mG5CjTbs5RBMqW5m7YL arnW+u0ddIBub00iuHimydpKIIQWXR6qJh7U/nHZaRL1U/9qO1bxuOAejuT6ghv3 4RcO6NbFE8fIw1Lw9qz9ES/JLQLiv5Mu2bN3KqDMimgtYI3DhRYeRdYJ4PNBCQwb fdjklfdsfdsfdssssdslDXAWGUMLQD+A2OebT1u6f5lL9mG5CjTbs5RBMqW5m7YL fdjkl29Jlfds893lfdslDXAWGUMLQD+A2OebT1u6f5lL9mG5CjTbs5RBMqW5m7YL 5916frBfv649N+cxKWnmIucbkQUXBeedFbz7VM+7xWiDE7Mw+2Fd9v4MHchBB0Sw fdjkl29Jlfds893lfdslDXAWGUMLQD+A2OebT1u6f5lL9mG5CjTbs5RBMqW5m7YL -----END RSA PRIVATE KEY-----
Sleutelbeheer server-sided
Personen die willen inloggen op een server, hebben op die server een computer-account nodig.
In het account van zo'n gebruiker op de server, vind je de volgende SSH/PKE-infrastructuur:
.ssh (map) authorized_keys (tekstbestand) known_hosts (tekstbestand)
In bestand authorized_keys staan alle publieke sleutels achter elkaar. In mijn geval de sleutels vanaf de verschillende computers waarmee ik kan inloggen op de betreffende server. Ongetwijfeld kun je met een teksteditor zelf sleutels toevoegen, maar waarschijnlijk bestaan daar kant-en-klare commando's voor.
Zie iets verderop mbt. de situatie dat je een sleutel van iemand anders wilt toevoegen aan zijn of haar account.
Sleutel uploaden - Automatisch
Uploaden van je publieke sleutel gaat met het commando ssh-copy-id
. Bv ssh-copy-id jeroen@12.34.56.78
of indien ik een alias heb ingesteld, bv. als ssh-copy-id server12
. (Ik neem aan, dat dit alleen gaat als je eerst servertoegang hebt middels regulier inloggen met loginnaam & wachtwoord, toch? - Aug. 2019)
Voorbeeld lente 2018:
ssh-copy-id server12 The authenticity of host 'server12 (12.34.56.78)' can't be established. ECDSA key fingerprint is SHA256:+1223232f2fdsgfdfsdfdsfsdfdsfzs. Are you sure you want to continue connecting (yes/no)? yes /usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed /usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys jeroen@server12's password: Number of key(s) added: 1 Now try logging into the machine, with: "ssh 'server12'" and check to make sure that only the key(s) you wanted were added.
- Ee werd inderdaad om mijn wachtwoord op de server gevraagd
- Sleutels werden toegevoegd aan bestand
.ssh/authorized_keys
. De identificatie van de betreffende computers werden toegevoegd aan bestand.ssh/known_hosts
Eigen sleutel uploaden - Handmatig
Sleutels kun je ook handmatig uploaden:
Upload naar de server
scp ~/.ssh/id_rsa.pub jeroen@12.34.56.78
Log in op de vps en voltooi de configuratie:
mkdir .ssh mv id_rsa.pub .ssh/authorized_keys chown -R inlognaam:inlognaam .ssh chmod 700 .ssh chmod 600 .ssh/authorized_keys
Sleutel voor iemand anders uploaden
Deze situatie kwam ik in de herfst van 2019 tegen met iemand die ik Klaas noem. Hij had zijn sleutel naar mij gemailed en er was al een account voor hem aangemaakt op de betreffende server:
- Kopiëer deze sleutel naar de server
- Log in op de server
- Verplaats deze sleutel naar het account van de gebruiker. Bv.:
sudo mv id_rsa.pub /home/klaas/
- Log in in het account van deze gebruiker:
su klaas
Voltooi het proces met basically dezelfde handelingen als hiervoor:
mkdir .ssh mkdir .ssh/authorized_keys mv id_rsa.pub .ssh/authorized_keys chown -R inlognaam:inlognaam .ssh chmod 700 .ssh chmod 600 .ssh/authorized_keys
Inloggen
Sleutels geüpload? Dan kun je voortaan inloggen via SSH:
ssh -l gebruiker 12.34.56.78
of
ssh gebruiker@12.34.56.78
Indien de gebruikersnaam op de client en de server hetzelfde zijn, kun je de gebruikersnaam weglaten:
ssh 12.34.56.78
DNS-host-alias
Voor servers defineer ik standaard een 'DNS-host-alias' in bestand /etc/hosts
.
srv1 12.34.56.78 srv5 23.45.67.78 tll7 45.67.89.01"
Daardoor kan ik de naam van die hosts gebruiken in commando's. Bv.:
scp dit_bestand_txt srv5:/var/www/example.com/upload-map/
Die host-aliassen kan ik overigens ook gebruiken voor inloggen middels SSH, al heb ik daar een betere oplossing voor (zie volgende paragraaf):
ssh -l gebruiker srv1
of
ssh srv1
.bashrc-alias
Standaard defineer ik in bestand ~/.bashrc
aliassen voor SSH-servertoegang. Bv.:
alias srv1="ssh 12.34.56.78" alias srv5="ssh 23.45.67.78" alias tll7="ssh 45.67.89.01"
Ik kan daardoor zonder inlognaam of wachtwoord inloggen op servers, door alleen de naam van de alias te hoeven op te geven - Heel erg prettig!
Instellingen ssh-configuratiebestand
Bewerk het sshd-configuratiebestand:
sudo vim /etc/ssh/sshd_config
Alle eigen instellingen voeg ik toe aan het eind van het bestand. Bv.:
#################################################### # All configuration settings - Strompf - April 2018 #################################################### # PermitRootLogin no PasswordAuthentication no PubkeyAuthentication yes
Herstart de ssh-deamon middels
sudo service ssh restart
Activeer loginnaam/wachtwoord-authenticatie
Als ik een computer wil toevoegen aan een bestaande PKA-configuratie, zijn er in ieder geval twee aanpakken mogelijk:
- Enable loginnaam/wachtwoord-authenticatie → voeg nieuwe sleutels toe → disable loginnaam/wachtwoord-authenticatie
- Voeg de sleutel toe via een computer die al onderdeel uitmaakt van de PKA-configuratie.
Hoe je inlognaam/wachtwoord-authenticatie activeert:
- Log in op de server. Indien dat niet kan via een geauthenticeerd device, kan het meestal nog via de provider (is trouwens een serieus beveiligings-issue, lijkt me)
- Bewerk
/etc/ssh/sshd_config
- Herstart ssh-server middels
sudo service ssh restart
- Verifiëer dat je middels loginnaam/wachtwoord kunt inloggen.
Instellingen /etc/ssh/sshd_config
:
######################################################### # Strompf ######################################################### # PermitRootLogin no PasswordAuthentication yes # TEMPORARY ← Only change this PubkeyAuthentication yes # ← Just leave this as it is
Extra SSH-sleutels toevoegen
- Inloggen via loginnaam/wachtwoord activeren
- Sleutels toevoegen op dezelfde manier als wanneer je dit voor de eerste keer doet
- Inloggen via loginnaam/wachtwoord deactiveren
- Testen dat je inderdaad alleen via PKA kunt inloggen - Dit is de belangrijkste stap.
Verifiëren dat je alleen met PKA kunt inloggen
En nu de essentie: Controleren of je inderdaad niet meer kunt inloggen mbv. loginnaam/wachtwoord...
- Op m'n werkstation:
mv .ssh .ssh_temp
- Zodat PKA niet meer werkt - Inloggen middels
ssh -l jeroen server12
- Resultaat:
The authenticity of host 'server12 (12.34.56.78)' can't be established. ECDSA key fingerprint is SHA256:+skjfslewljdsldjaslduasodjasldjsalduasidasajl. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'server12,12.34.56.78' (ECDSA) to the list of known hosts. Permission denied (publickey).
En de regel Permission denied (publickkey). geeft aan dat het gelukt is.
Laatste stappen:
rm -rf .ssh
- Er was al een nieuwe map .ssh aangemaakt met daarin de known_host-identificatie van server12mv .ssh_tmp .ssh
Enter passphrase for key ...
- Helaas kan ik regelmatig niet zomaar inloggen op m'n servers zonder iets van credentials te moeten invullen: Ik word regelmatig om de zogenaamde passphrase gevraagd. Dat is iets dat speelt op m'n werkstation, niet op servers
- Ik heb de oorzaak tot op heden niet kunnen vinden.
Zie ook
- Installatie webserver
- Mappen, bestanden & rechten - 2020 (WordPress)
- Public Key Encryption (PKE)
- SSH