SSH-PKA-Servertoegang: verschil tussen versies
(5 tussenliggende versies door dezelfde gebruiker niet weergegeven) | |||
Regel 61: | Regel 61: | ||
-----END RSA PRIVATE KEY----- | -----END RSA PRIVATE KEY----- | ||
</pre> | </pre> | ||
+ | |||
+ | == Sleutels server-sided == | ||
+ | |||
+ | Op de server heb je in het account van elke gebruiker deze bestandsstructuur: | ||
+ | |||
+ | <pre> | ||
+ | .ssh (map) | ||
+ | authorized_keys (tekstbestand) | ||
+ | known_hosts (tekstbestand) | ||
+ | </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. | ||
+ | |||
+ | Zie iets verderop mbt. de situatie dat je een sleutel van iemand anders wilt toevoegen aan zijn of haar account. | ||
== Sleutel uploaden - Automatisch == | == Sleutel uploaden - Automatisch == | ||
Regel 86: | Regel 100: | ||
* 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> | * 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> | ||
− | == | + | == Eigen sleutel uploaden - Handmatig == |
Sleutels kun je ook handmatig uploaden: | Sleutels kun je ook handmatig uploaden: | ||
Regel 102: | Regel 116: | ||
chmod 600 .ssh/authorized_keys | 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 <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> | ||
+ | mkdir .ssh | ||
+ | mv id_rsa.pub .ssh/authorized_keys | ||
+ | chown -R inlognaam:inlognaam .ssh | ||
+ | chmod 700 .ssh | ||
+ | chmod 600 .ssh/authorized_keys | ||
+ | </pre> | ||
== Inloggen == | == Inloggen == |
Versie van 12 sep 2019 18:37
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
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-----
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 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.