SSH-PKA-Servertoegang: verschil tussen versies

Versie van 4 dec 2020 11:27

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:

De gebruiker moet een computer-account hebben op de betreffende server
Publieke sleutel-authenticatie
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:

Server-account aanmaken
Publieke sleutel uploaden
Aliassen aanmaken op de client-computer
Testen.

Server-account aanmaken

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. www-admin.

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):

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:

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)
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:

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

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

https://www.linode.com/docs/security/securing-your-server/
http://askubuntu.com/questions/46424/adding-ssh-keys-to-authorized-keys - Fantastisch artikel!

@@ Regel 356: / Regel 356: @@
 Een paar dingen rondom passphrases:
-=== Enter passphrase for key... ==
+=== 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: