SSH-PKA-Servertoegang: verschil tussen versies

Uit De Vliegende Brigade
Naar navigatie springen Naar zoeken springen
 
(47 tussenliggende versies door dezelfde gebruiker niet weergegeven)
Regel 5: Regel 5:
 
=== Uitsluitend SSH ===
 
=== 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.
+
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.
  
 
=== Drie niveaus ===
 
=== Drie niveaus ===
Regel 11: Regel 11:
 
Authenticatie vindt op drie niveaus plaats:
 
Authenticatie vindt op drie niveaus plaats:
  
−
# Computer-account op de betreffende server
+
# De gebruiker moet een computer-account hebben op de betreffende server
 
# Publieke sleutel-authenticatie
 
# Publieke sleutel-authenticatie
−
# Host-fingerprint-authenticatie.
+
# Publieke sleutel is computer-gebonden.
  
 
== Waarom? ==
 
== Waarom? ==
  
−
Da's een stuk veiliger dan inloggen middels alleen een inlognaam+wachtwoord:
+
=== Veiliger ===
  
−
* 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
+
* Het is veel lastiger om een publieke sleutel en een inlognaam te kraken dan een inlognaam-wachtwoord-combinatie
−
* Minder gevoelig voor DDOS-aanvallen.
+
* Toegang is computer-gebonden. Dat maakt toegangscontrole beter: Je hebt de computer nodig + inloggegevens op die computer.
 +
 
 +
=== Gemakkelijker? ===
 +
 
 +
Is inloggen op deze manier gemakkelijker dan inloggen middels een inlognaam-wachtwoord-combinatie? Waarschijnlijk maakt dat niet uit: Ook voor inloggen middels inlognaam en wachtwoord, kun je de gegevens opslaan, zodat je deze niet steeds opnieuw hoeft in te tikken. Dat is wat ik bv. doe voor MySQL.
  
 
== Aanpak ==
 
== Aanpak ==
  
−
We willen een gebruiker toegang geven tot een server, vanaf een bepaalde computer:
+
Vier stappen om een gebruiker vanaf een bepaalde client-computer toegang te geven tot een server:
 +
 
 +
# Server-account aanmaken
 +
# Publieke sleutel uploaden
 +
# Aliassen aanmaken op de client-computer
 +
# Testen.
  
−
# Maak een account aan voor de gebruiker op de server → [[Accounts (Linux)]], [[Mappen, bestanden & rechten - 2020 (WordPress)]]
+
== Server-account aanmaken ==
−
# 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 ==
+
Maak een account aan voor de gebruiker op de server:
 +
 
 +
* Handig als de gebruikersnaam dezelfde is als op de client-machine vanwaar hij/zij gaat inloggen
 +
* Zie [[Accounts (Linux)]], [[Mappen, bestanden & rechten - 2020 (WordPress)]]
 +
* Eventueel: Zorg dat hij/zij lid is van de juiste groep, bv. <code>www-admin</code>.
 +
 
 +
== Publieke sleutel uploaden ==
 +
 
 +
Op het moment dat de nieuwe gebruiker een account heeft op de betreffende server, en zijn/haar publieke sleutel is toegevoegd aan het serverbestand <code>~/.ssh/authorised_keys</code>, dan kan hij/zij inloggen. Je hoeft de gebruikersnaam dus niet alsnog ergens toe te voegen aan een lijst van bv. gebruikers.
  
 
Ik doe sleutelbeheer niet al te vaak, vandaar dat dit hoofdstuk vrij uitgebreid is.
 
Ik doe sleutelbeheer niet al te vaak, vandaar dat dit hoofdstuk vrij uitgebreid is.
  
−
=== Sleutels aanmaken op werkstation ===
+
=== Sleutels aanmaken op client-computer ===
  
 
[[file:20170106-1348.png|thumb|Dit is m'n werkstation. Sleutels zijn aangemaakt]]
 
[[file:20170106-1348.png|thumb|Dit is m'n werkstation. Sleutels zijn aangemaakt]]
Regel 104: Regel 118:
 
</pre>
 
</pre>
  
−
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.
+
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. Een artistieke impressie van dit bestand:
  
−
Zie iets verderop mbt. de situatie dat je een sleutel van iemand anders wilt toevoegen aan zijn of haar account.
+
<pre>
 +
sah-rsa AAAAB3NDb1234567889Db1234567889Db1234567889Db1234567889EAAAADAQABAAABAQDb1234567889ahI5HRyGmPjSuh+PjDb1234567889Db1234567889/DvabfTSM0PECC5Ssz0xnrlXy9rISA4ZdgWoz2hg/5Zc9T9C0Ql0QIUcyxXtoYUR5C2kNDkfD7G1HHEK5C4SnzUjNvhg3bZ+n95//+G+eIbE9U4RH8y1098dZzTnk7P0NyVsuxEmfy6sFbE7Pd0J strompf@Katwijk
 +
ssh-rsa AAAAB3NzDb1234567889Db1234567889Db1234567889Db1234567889EAAAADAQABAAABAQDb1234567889aNC6jvZ34567889EAAAADAQABAAABAQDb1234567889aNC6jvZ34567889EAAAADAQABAAABAQDb1234567889aNC6jvZ34567889EAAAADAQABAAABAQDb1234567889aNC6jvZ34567889EAAAADAQABAAABAQDb1234567889aNC6jvZBAAABAQDb1234567889a strompf@blackbox-2014
 +
ssh-rsa AAAAB3NzaDb1234567889Db1234567889Db134567889EAAAADAQABAAABAQDb1234567889aNC6jvZ34567889EAAAADAQABAAABAQDb1234567889aNC6jvZ234567889DbBIqx8MLJd3YXY9NOc1zO3IkvDb1234567889Db1234567889Db1234567889Db1234567889EAAAADAQABAAABAQDb1234567889a strompf@Dell2017
 +
ssh-rsa AAAAB3NzDb1234567889Db1234567889Db1234567889Db1234567889EAAAADAQABAAABAQDb1234567889aiSslE9FMx1x7WTJTn3tdx3wd8zaLnKBjlEBvpSrA3EQ3/EOUmg9viPHJF6k+myREc++std+lI3Lem2b+miVakInAGj0+nCofX8gLSRWPXOEpL7e/KW8sfXnqOfeHl8paCgJMgJKCXNBTNPEvixV/SDkeVYmaratJxHpqB7rFmA9Vf7889Db1234567889EAAAADAQABAAABAQDb1234567889a strompf@dell2016
 +
</pre>
  
 
=== Sleutel uploaden - Automatisch ===
 
=== Sleutel uploaden - Automatisch ===
  
−
Uploaden van je publieke sleutel gaat met het commando <code>ssh-copy-id</code>. Bv <code>ssh-copy-id jeroen@12.34.56.78</code> of indien ik een alias heb ingesteld, bv. als <code>ssh-copy-id server12</code>. (Ik neem aan, dat dit alleen gaat als je eerst servertoegang hebt middels regulier inloggen met loginnaam & wachtwoord, toch? - Aug. 2019)
+
Uploaden van je publieke sleutel gaat met het commando <code>ssh-copy-id</code>. Bv <code>ssh-copy-id jeroen@12.34.56.78</code> of indien ik een alias heb ingesteld, bv. als <code>ssh-copy-id server12</code>. Dit werkt uiteraard alleen, als je al op een andere manier toegang hebt. In de praktijk betekent dat, dat ik op een server tijdelijk inloggen-middels-loginnaam-en-wachtwoord activeer (iets wat ik lastig vind, want ik doe dit niet al te vaak).  
  
 
Voorbeeld lente 2018:
 
Voorbeeld lente 2018:
Regel 129: Regel 148:
 
</pre>
 
</pre>
  
−
* Ee werd inderdaad om mijn wachtwoord op de server gevraagd
+
* Er werd inderdaad om mijn wachtwoord op de server gevraagd
−
* Sleutels werden toegevoegd aan bestand <code>.ssh/authorized_keys</code>. De identificatie van de betreffende computers werden toegevoegd aan bestand <code>.ssh/known_hosts</code>
+
* De sleutel werd inderdaad toegevoegd aan bestand <code>.ssh/authorized_keys</code>. De identificatie van de betreffende computer werd toegevoegd aan bestand <code>.ssh/known_hosts</code>.
−
 
 
−
=== Eigen sleutel uploaden - Handmatig ===
 
−
 
 
−
Sleutels kun je ook handmatig uploaden:
 
−
 
 
−
Upload naar de server
 
  
−
scp ~/.ssh/id_rsa.pub jeroen@12.34.56.78
+
=== Sleutels handmatig uploaden ===
  
−
Log in op de vps en voltooi de configuratie:
+
Je kunt sleutels ook handmatig uploaden en toevoegen aan bestand <code>~/.ssh/authorised_keys</code> van de betreffende gebruiker. Ik doe dit niet al te vaak, maar vermoedelijk is dit voor mij de gemakkelijkste manier. Twee varianten hierop:
  
−
mkdir .ssh
+
# Log in via de console binnen m'n TransIP-account. Kopiëer de sleutel middels kopiëren-en-plakken (de TransIP-console heeft daar een menu-item voor)
−
mv id_rsa.pub .ssh/authorized_keys
+
# Kopiëer de sleutel via Dropbox naar een werkstation waarmee ik al kan inloggen op de server. Log via dat werkstation in, en voeg de sleutel via kopiëren-en-plakken toen
−
chown -R inlognaam:inlognaam .ssh
 
−
chmod 700 .ssh
 
−
chmod 600 .ssh/authorized_keys
 
  
−
== Sleutel voor iemand anders uploaden ==
+
=== Map .ssh beveiligen ===
  
−
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:
+
Voor extra veiligheid, stel de bestandsrechten op de map </code>~/.ssh</code> als volgt in:
−
 
 
−
* Kopiëer deze sleutel naar de server
 
−
* Log in op de server
 
−
* Verplaats deze sleutel naar het account van de gebruiker. Bv.: <code>sudo mv id_rsa.pub /home/klaas/</code>
 
−
* Log in in het account van deze gebruiker: <code>su klaas</code>
 
−
 
 
−
Voltooi het proces met basically dezelfde handelingen als hiervoor:
 
  
 
<pre>
 
<pre>
−
mkdir .ssh
+
chown -R inlognaam:inlognaam .ssh   # Indien je dit doet voor iemand anders
−
mkdir .ssh/authorized_keys
 
−
mv id_rsa.pub .ssh/authorized_keys
 
−
chown -R inlognaam:inlognaam .ssh
 
 
chmod 700 .ssh
 
chmod 700 .ssh
 
chmod 600 .ssh/authorized_keys
 
chmod 600 .ssh/authorized_keys
 
</pre>
 
</pre>
  
−
== Inloggen ==
+
== Aliassen aanmaken op de client-computer ==
  
−
Sleutels geüpload? Dan kun je voortaan inloggen via SSH:
+
Handig om dit gelijk vanaf het begin te doen: Dat maakt testen namelijk minder verwarrend.
−
 
 
−
<pre>
 
−
ssh -l gebruiker 12.34.56.78
 
−
</pre>
 
−
of
 
−
<pre>
 
−
ssh gebruiker@12.34.56.78
 
−
</pre>
 
−
 
 
−
Indien de gebruikersnaam op de client en de server hetzelfde zijn, kun je de gebruikersnaam weglaten:
 
−
 
 
−
<pre>
 
−
ssh 12.34.56.78
 
−
</pre>
 
  
 
=== DNS-host-alias ===
 
=== DNS-host-alias ===
Regel 216: Regel 202:
 
=== .bashrc-alias ===
 
=== .bashrc-alias ===
  
−
Standaard defineer ik in bestand <code>~/.bashrc</code> aliassen voor SSH-servertoegang. Bv.:
+
Standaard defineer ik in bestand <code>~/.bashrc</code> aliassen voor SSH-servertoegang naar alle servers. Bv.:
  
 
<pre>
 
<pre>
Regel 226: Regel 212:
 
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!
 
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 ==
+
== Testen ==
 +
 
 +
Opzetten van SSH-PKA-servertoegang, vind ik vaak taaie materie, vooral omdat ik dit niet elke dag doe. Vandaar dit uitgebreide hoofdstuk ''Testen''.
 +
 
 +
=== Inloggen ===
 +
 
 +
Hele procedure doorlopen? Dan kun je inloggen met alleen de namen uit <code>~/.bashrc</code>:
 +
 
 +
<pre>
 +
srv5
 +
</pre>
 +
 
 +
=== Inloggen zonder alias ===
 +
 
 +
Storingen? Uiteraard kun je ook inloggen zonder aliassen te gebruiken. Dat kan handig zijn om te testen waar de fout zit:
 +
 
 +
<pre>
 +
ssh -l gebruiker 12.34.56.78
 +
</pre>
 +
 
 +
of
 +
 
 +
<pre>
 +
ssh gebruiker@12.34.56.78
 +
</pre>
 +
 
 +
Indien de gebruikersnaam op de client en de server hetzelfde zijn, kun je de gebruikersnaam weglaten:
 +
 
 +
<pre>
 +
ssh 12.34.56.78
 +
</pre>
 +
 
 +
=== Er gebeurt niets? ===
 +
 
 +
Normaal krijg je ''altijd'' een reactie van de server, al is het maar:
 +
 
 +
<pre>
 +
Permission denied (publickey)
 +
</pre>
 +
 
 +
Geen enkele reactie?
 +
 
 +
* In mei 2020 had ik een situatie, waarbij na het inlogcommando, er niets gebeurde. Dat bleek te komen door een firewall in een router, die dit verkeer blokkeerde
 +
* Gebruik je wel het goede IP-adres?
 +
* Doet internet het wel?
 +
 
 +
=== Toegang blijft geweigerd ===
 +
 
 +
* Heeft de gebruiker op de betreffende server, een account?
 +
* Gebruik je de correcte inlognaam om in te loggen op de server?
 +
* In het account op de server van de betreffende server, staat daar bestand <code>~/.ssh/authorized_keys</code>?
 +
* Is de publieke sleutel toegevoegd aan dat bestand? (zie voorbeeld eerder in dit artikel).
 +
 
 +
=== Verifiëer dat je alleen met PKA kunt inloggen ===
 +
 
 +
Verifiëer dat je niet meer kunt inloggen mbv. loginnaam/wachtwoord:
 +
 
 +
* Client-computer: <code>mv .ssh .ssh_temp</code> - Zodat PKA niet meer werkt
 +
* Log in
 +
 
 +
Verwachte resultaat:
 +
 
 +
<pre>
 +
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).
 +
</pre>
 +
 
 +
De regel ''Permission denied (publickey).'' geeft aan, dat je alleen met PKA kunt inloggen.
 +
 
 +
=== Verbose ===
 +
 
 +
De ''verbose''-switch geeft een hoop informatie (maar helaas niet waar op de doellocatie een bestand is geplaatst). Bv.:
 +
 
 +
<pre>
 +
scp -v ./bestand.txt srv5:
 +
</pre>
 +
 
 +
of
 +
 
 +
<pre>
 +
scp -v ./bestand.txt 12.34.56.78:/home/strompf/bestand.txt
 +
</pre>
 +
 
 +
== Server-sided: SSH-PKA configureren ==
 +
 
 +
Nu de andere kant van het verhaal: Hoe configureer je op een server SSH-PKA-servertoegang? Dit artikel is ietwat incompleet.
 +
 
 +
=== PKA activeren ===
  
 
Bewerk het sshd-configuratiebestand:
 
Bewerk het sshd-configuratiebestand:
Regel 248: Regel 326:
 
  sudo service ssh restart
 
  sudo service ssh restart
  
−
== Activeer loginnaam/wachtwoord-authenticatie ==
+
=== Loginnaam/wachtwoord-authenticatie opnieuw activeren ===
  
 
Als ik een computer wil toevoegen aan een bestaande PKA-configuratie, zijn er in ieder geval twee aanpakken mogelijk:
 
Als ik een computer wil toevoegen aan een bestaande PKA-configuratie, zijn er in ieder geval twee aanpakken mogelijk:
Regel 255: Regel 333:
 
* Voeg de sleutel toe via een computer die al onderdeel uitmaakt van de PKA-configuratie.
 
* Voeg de sleutel toe via een computer die al onderdeel uitmaakt van de PKA-configuratie.
  
−
Hoe je inlognaam/wachtwoord-authenticatie activeert:
+
Hoe je inlognaam/wachtwoord-authenticatie opnieuw 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)
 
# 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)
Regel 274: Regel 352:
 
</pre>
 
</pre>
  
−
== Extra SSH-sleutels toevoegen ==
+
== Passphrase ==
  
−
* Inloggen via loginnaam/wachtwoord activeren
+
Een paar dingen rondom passphrases:
−
* 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 ==
+
=== Enter passphrase for key... ===
  
−
En nu de essentie: Controleren of je inderdaad niet meer kunt inloggen mbv. loginnaam/wachtwoord...
+
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:
  
−
* Op m'n werkstation: <code>mv .ssh .ssh_temp</code> - Zodat PKA niet meer werkt
+
* Dit speelt zich af op het betreffende werkstation, niet op de server
−
* Inloggen middels <code>ssh -l jeroen server12</code>
+
* Met de passphrase wordt gecontroleerd of de ''remote public key'' overeenkomt met de ''local private key''
−
* Resultaat:
+
* Je kunt dit vaak uitzetten. Dan wordt de passphrase toegevoegd aan de ''keychain''.
  
−
<pre>
+
Bronnen:
−
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.
+
* https://superuser.com/questions/156647/ssh-key-asking-me-for-a-passphrase
 +
* https://serverfault.com/questions/613756/how-to-stop-ssh-passphrase-prompt
  
−
Permission denied (publickey).
+
=== Passphrase verifiëren ===
−
</pre>
 
  
−
En de regel ''Permission denied (publickkey).'' geeft aan dat het gelukt is.
+
Niet zeker of ik je je passphrase corrrect hebt opgeschreven? Dat kun je gemakkelijk testen middels <code>ssh-keygen</code>:
  
−
Laatste stappen:
+
Verkeerde passphrase:
  
−
* <code>rm -rf .ssh</code> - Er was al een nieuwe map ''.ssh'' aangemaakt met daarin de ''known_host''-identificatie van ''server12''
+
<pre>
−
* <code>mv .ssh_tmp .ssh</code>
+
ssh-keygen -y
 +
Enter file in which the key is (/home/jeroen/.ssh/id_rsa):
 +
Enter passphrase:
 +
Load key "/home/jeroen/.ssh/id_rsa": incorrect passphrase supplied to decrypt private key
 +
</pre>
  
−
== Enter passphrase for key ... ==
+
Correcte passphrase:
  
−
* 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
+
<pre>
−
* Ik heb de oorzaak tot op heden niet kunnen vinden.
+
strompf:~$ ssh-keygen -y
 +
Enter file in which the key is (/home/jeroen/.ssh/id_rsa):  
 +
Enter passphrase:
 +
ssh-rsa AAAfdsfdsfdsfdfdsfdsfdsfdsfdsfdsfdsfdsfsdfsdfdsfdsfds (hier staat de hele sleutel) etc.  
 +
</pre>
  
 
== Zie ook ==
 
== Zie ook ==
Regel 315: Regel 395:
 
* [[Installatie webserver]]
 
* [[Installatie webserver]]
 
* [[Mappen, bestanden & rechten - 2020 (WordPress)]]
 
* [[Mappen, bestanden & rechten - 2020 (WordPress)]]
 +
* [[MySQL Workbench - Remote connection]]
 
* [[Public Key Encryption (PKE)]]
 
* [[Public Key Encryption (PKE)]]
−
* [[SSH]]
+
* [[SSH (algemeen)]]
  
 
== Bronnen ==
 
== Bronnen ==

Huidige versie van 29 sep 2021 om 11:32

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.

Drie niveaus

Authenticatie vindt op drie niveaus plaats:

  1. De gebruiker moet een computer-account hebben op de betreffende server
  2. Publieke sleutel-authenticatie
  3. Publieke sleutel is computer-gebonden.

Waarom?

Veiliger

  • Het is veel lastiger om een publieke sleutel en een inlognaam te kraken dan een inlognaam-wachtwoord-combinatie
  • Toegang is computer-gebonden. Dat maakt toegangscontrole beter: Je hebt de computer nodig + inloggegevens op die computer.

Gemakkelijker?

Is inloggen op deze manier gemakkelijker dan inloggen middels een inlognaam-wachtwoord-combinatie? Waarschijnlijk maakt dat niet uit: Ook voor inloggen middels inlognaam en wachtwoord, kun je de gegevens opslaan, zodat je deze niet steeds opnieuw hoeft in te tikken. Dat is wat ik bv. doe voor MySQL.

Aanpak

Vier stappen om een gebruiker vanaf een bepaalde client-computer toegang te geven tot een server:

  1. Server-account aanmaken
  2. Publieke sleutel uploaden
  3. Aliassen aanmaken op de client-computer
  4. Testen.

Server-account aanmaken

Maak een account aan voor de gebruiker op de server:

Publieke sleutel uploaden

Op het moment dat de nieuwe gebruiker een account heeft op de betreffende server, en zijn/haar publieke sleutel is toegevoegd aan het serverbestand ~/.ssh/authorised_keys, dan kan hij/zij inloggen. Je hoeft de gebruikersnaam dus niet alsnog ergens toe te voegen aan een lijst van bv. gebruikers.

Ik doe sleutelbeheer niet al te vaak, vandaar dat dit hoofdstuk vrij uitgebreid is.

Sleutels aanmaken op client-computer

Dit is m'n werkstation. Sleutels zijn aangemaakt

Kijk of er een map ~/.ssh is met daarin deze bestanden:

  • id_rsa Privésleutel
  • id_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. Een artistieke impressie van dit bestand: 

sah-rsa AAAAB3NDb1234567889Db1234567889Db1234567889Db1234567889EAAAADAQABAAABAQDb1234567889ahI5HRyGmPjSuh+PjDb1234567889Db1234567889/DvabfTSM0PECC5Ssz0xnrlXy9rISA4ZdgWoz2hg/5Zc9T9C0Ql0QIUcyxXtoYUR5C2kNDkfD7G1HHEK5C4SnzUjNvhg3bZ+n95//+G+eIbE9U4RH8y1098dZzTnk7P0NyVsuxEmfy6sFbE7Pd0J strompf@Katwijk
ssh-rsa AAAAB3NzDb1234567889Db1234567889Db1234567889Db1234567889EAAAADAQABAAABAQDb1234567889aNC6jvZ34567889EAAAADAQABAAABAQDb1234567889aNC6jvZ34567889EAAAADAQABAAABAQDb1234567889aNC6jvZ34567889EAAAADAQABAAABAQDb1234567889aNC6jvZ34567889EAAAADAQABAAABAQDb1234567889aNC6jvZBAAABAQDb1234567889a strompf@blackbox-2014
ssh-rsa AAAAB3NzaDb1234567889Db1234567889Db134567889EAAAADAQABAAABAQDb1234567889aNC6jvZ34567889EAAAADAQABAAABAQDb1234567889aNC6jvZ234567889DbBIqx8MLJd3YXY9NOc1zO3IkvDb1234567889Db1234567889Db1234567889Db1234567889EAAAADAQABAAABAQDb1234567889a strompf@Dell2017
ssh-rsa AAAAB3NzDb1234567889Db1234567889Db1234567889Db1234567889EAAAADAQABAAABAQDb1234567889aiSslE9FMx1x7WTJTn3tdx3wd8zaLnKBjlEBvpSrA3EQ3/EOUmg9viPHJF6k+myREc++std+lI3Lem2b+miVakInAGj0+nCofX8gLSRWPXOEpL7e/KW8sfXnqOfeHl8paCgJMgJKCXNBTNPEvixV/SDkeVYmaratJxHpqB7rFmA9Vf7889Db1234567889EAAAADAQABAAABAQDb1234567889a strompf@dell2016

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. Dit werkt uiteraard alleen, als je al op een andere manier toegang hebt. In de praktijk betekent dat, dat ik op een server tijdelijk inloggen-middels-loginnaam-en-wachtwoord activeer (iets wat ik lastig vind, want ik doe dit niet al te vaak).

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.
  • Er werd inderdaad om mijn wachtwoord op de server gevraagd
  • De sleutel werd inderdaad toegevoegd aan bestand .ssh/authorized_keys. De identificatie van de betreffende computer werd toegevoegd aan bestand .ssh/known_hosts.

Sleutels handmatig uploaden

Je kunt sleutels ook handmatig uploaden en toevoegen aan bestand ~/.ssh/authorised_keys van de betreffende gebruiker. Ik doe dit niet al te vaak, maar vermoedelijk is dit voor mij de gemakkelijkste manier. Twee varianten hierop:

  1. Log in via de console binnen m'n TransIP-account. Kopiëer de sleutel middels kopiëren-en-plakken (de TransIP-console heeft daar een menu-item voor)
  2. Kopiëer de sleutel via Dropbox naar een werkstation waarmee ik al kan inloggen op de server. Log via dat werkstation in, en voeg de sleutel via kopiëren-en-plakken toen

Map .ssh beveiligen

Voor extra veiligheid, stel de bestandsrechten op de map ~/.ssh als volgt in: 

chown -R inlognaam:inlognaam .ssh   # Indien je dit doet voor iemand anders
chmod 700 .ssh
chmod 600 .ssh/authorized_keys

Aliassen aanmaken op de client-computer

Handig om dit gelijk vanaf het begin te doen: Dat maakt testen namelijk minder verwarrend.

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 naar alle servers. 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!

Testen

Opzetten van SSH-PKA-servertoegang, vind ik vaak taaie materie, vooral omdat ik dit niet elke dag doe. Vandaar dit uitgebreide hoofdstuk Testen.

Inloggen

Hele procedure doorlopen? Dan kun je inloggen met alleen de namen uit ~/.bashrc: 

srv5

Inloggen zonder alias

Storingen? Uiteraard kun je ook inloggen zonder aliassen te gebruiken. Dat kan handig zijn om te testen waar de fout zit: 

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

Er gebeurt niets?

Normaal krijg je altijd een reactie van de server, al is het maar: 

Permission denied (publickey)

Geen enkele reactie?

  • In mei 2020 had ik een situatie, waarbij na het inlogcommando, er niets gebeurde. Dat bleek te komen door een firewall in een router, die dit verkeer blokkeerde
  • Gebruik je wel het goede IP-adres?
  • Doet internet het wel?

Toegang blijft geweigerd

  • Heeft de gebruiker op de betreffende server, een account?
  • Gebruik je de correcte inlognaam om in te loggen op de server?
  • In het account op de server van de betreffende server, staat daar bestand ~/.ssh/authorized_keys?
  • Is de publieke sleutel toegevoegd aan dat bestand? (zie voorbeeld eerder in dit artikel).

Verifiëer dat je alleen met PKA kunt inloggen

Verifiëer dat je niet meer kunt inloggen mbv. loginnaam/wachtwoord:

  • Client-computer: mv .ssh .ssh_temp - Zodat PKA niet meer werkt
  • Log in

Verwachte 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).

De regel Permission denied (publickey). geeft aan, dat je alleen met PKA kunt inloggen.

Verbose

De verbose-switch geeft een hoop informatie (maar helaas niet waar op de doellocatie een bestand is geplaatst). Bv.: 

scp -v ./bestand.txt srv5:

of 

scp -v ./bestand.txt 12.34.56.78:/home/strompf/bestand.txt

Server-sided: SSH-PKA configureren

Nu de andere kant van het verhaal: Hoe configureer je op een server SSH-PKA-servertoegang? Dit artikel is ietwat incompleet.

PKA activeren

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

Loginnaam/wachtwoord-authenticatie opnieuw activeren

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 opnieuw activeert:

  1. 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)
  2. Bewerk /etc/ssh/sshd_config
  3. Herstart ssh-server middels sudo service ssh restart
  4. 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

Passphrase

Een paar dingen rondom passphrases:

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:

  • Dit speelt zich af op het betreffende werkstation, niet op de server
  • Met de passphrase wordt gecontroleerd of de remote public key overeenkomt met de local private key
  • Je kunt dit vaak uitzetten. Dan wordt de passphrase toegevoegd aan de keychain.

Bronnen:

Passphrase verifiëren

Niet zeker of ik je je passphrase corrrect hebt opgeschreven? Dat kun je gemakkelijk testen middels ssh-keygen:

Verkeerde passphrase: 

ssh-keygen -y
Enter file in which the key is (/home/jeroen/.ssh/id_rsa): 
Enter passphrase: 
Load key "/home/jeroen/.ssh/id_rsa": incorrect passphrase supplied to decrypt private key

Correcte passphrase: 

strompf:~$ ssh-keygen -y
Enter file in which the key is (/home/jeroen/.ssh/id_rsa): 
Enter passphrase: 
ssh-rsa AAAfdsfdsfdsfdfdsfdsfdsfdsfdsfdsfdsfdsfsdfsdfdsfdsfds (hier staat de hele sleutel) etc.

Zie ook

Bronnen

Overgenomen van "https://wiki.devliegendebrigade.nl/index.php?title=SSH-PKA-Servertoegang&oldid=27630"