SSH-PKA-Servertoegang

Uit De Vliegende Brigade
Ga naar: navigatie, zoeken

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:

  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 bestand ~/.ssh/authorised_keys, dan kan hij/zij inloggen. Je hoeft dus de gebruikersnaam 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. 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

Uiteraard kun je sleutels handmatig uploaden, en toevoegen aan bestand ~/.ssh/authorised_keys van de betreffende gebruiker.

Voor extra veiligheid, stel de bestandsrechten op de map </code>~/.ssh</code> 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

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

Bronnen