SSH key-pair-authenticatie: verschil tussen versies

Uit De Vliegende Brigade
Ga naar: navigatie, zoeken
(Sleutel uploaden)
(Sleutel voor iemands uploaden)
 
(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>
  
== Sleutel uploaden - Handmatig ==
+
== 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
  
Dit is vermoedelijk de aanpak als je de sleutel van iemand anders wilt uploaden.
+
== 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 ==

Huidige versie van 12 sep 2019 om 17: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

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

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:

  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

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