SSH-PKA-Servertoegang

Sinds eind 2014 maak ik gebruik van key pair authentication om in te loggen op servers. Da's een stuk veiliger dan inloggen middels een inlognaam+wachtwoord:

Het is veel lastiger om een publieke sleutel en/of een host fingerprint te kraken dan een inlognaam-wachtwoord-combinatie
Authenticatie vindt plaats op account-niveau (PKA) en ik geloof ook op computer-niveau (host fingerprint)
Vermoedelijk is een DDOS-aanval via brute force SSH-inlogpogingen, een stuk lastiger, omdat de SSH-deamon gemakkelijk kan zien dat iemand probeert in te loggen vanaf een onjuiste host.

Sleutels & sleutels aanmaken

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

Sleutels server-sided

Op de server heb je in het account van elke gebruiker deze bestandsstructuur:

.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 iemands 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. middels 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
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.

Met gebruikersnaam & ip-adres

icm. loginnaam/wachtwoord-authenticatie:

ssh -l gebruiker 12.34.56.78

of

ssh gebruiker@12.34.56.78

Inloggen via SSH icm. PKA:

ssh 12.34.56.78

Met gebruikersnaam & alias

Meestal heb ik een alias gedefinered voor servers in /etc/hosts. Een voorbeeld van zo'n alias:

12.34.56.78   server12

Dan wordt inloggen bv.

ssh -l gebruiker server12

of

ssh server12

Met .bashrc-alias

In bestand ~/.bashrc heb ik aliassen gedefineerd voor inloggen op servers. Bv.:

alias srv1="ssh 12.34.56.78"
alias srv5="ssh 23.45.67.78"
alias srv5="ssh 34.56.78.90"
alias tll7="ssh 45.67.89.01"

Ik kan dus inloggen met commando's zoals srv1 - Helemaal te gek!

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 server12
mv .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

Bronnen

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