SSH sleutels voor een Linux VPS: maak, installeer en test toegang

Bevestig de echte account, host en recovery methode

Gebruik deze checklist voor een Linux VPS die u bezit of die bevoegd is om te beheren. Begin met de host, accountnaam en SSH-poort die daadwerkelijk aan uw service is toegewezen. Een gebruikersnaam niet raden van een distributienaam. Bevestigen hoe u toegang zou herstellen als een authenticatie verandering mislukt, met behulp van een methode die uw operator echt beschikbaar heeft gesteld.

Houd een bestaande geverifieerde sessie open tijdens het testen van een nieuwe inlogmethode. Als u nog geen werktoegang heeft, los dan eerst de eerste verbindingsgegevens op. Een publieke hostingplan of een betaalde bestelling is zelf geen werkende shell-account; wacht op de werkelijke servicegegevens voordat u serverinstructies toepast.

Evaluatie van software en middelen van Linux VPS

Maak de sleutel aan op het apparaat waarmee verbinding wordt gemaakt

Start ssh-keygen op uw eigen client apparaat, niet in de externe VPS. Voor een OpenSSH client die het ondersteunt, maakt ssh-keygen -t ed25519 een Ed25519 sleutelpaar en prompts voor een bestandslocatie en wachtwoordzin. Kies een nieuwe bestandsnaam als een bestaande sleutel al aanwezig is; overschrijf geen sleutel die een andere server nog steeds gebruikt.

Bescherm de privésleutel met een wachtwoordzin en beveiligde opslag van het apparaat. Gebruik de interactieve prompt in plaats van een wachtwoordzin in een commando dat opgeslagen kan worden in de shellgeschiedenis. Houd het belangrijkste doel en de vingerafdruk van de publieke sleutel bij zodat u later de juiste ingang kunt identificeren bij het herzien of intrekken van toegang.

Installeer de publieke helft voor de beoogde serveraccount

De publieke sleutel heeft normaal dezelfde bestandsnaam met .pub bijvoegd. Voeg die publieke sleutel toe aan de geautoriseerde-sleutel locatie voor het account dat u gebruikt op de VPS. Veel OpenSSH-installaties gebruiken ~/.ssh/authorized_keys voor het externe account, maar de effectieve serverconfiguratie kan een andere locatie specificeren. Controleer de locatie in plaats van te veronderstellen dat elk systeem hetzelfde beleid gebruikt.

Indien beschikbaar kan ssh-copy-id via een bestaande geautoriseerde verbinding een publieke sleutel installeren. Een handmatige installatie moet bestaande sleutels behouden en elke publieke sleutel op één lijn houden. Vervang het hele bestand niet door een enkele nieuwe invoer tenzij u bewust elke toegangshouder hebt bekeken. De privésleutel blijft op je eigen apparaat.

Schuif de tabel horizontaal indien nodig.

Controleer de gastheer en test een nieuwe verbinding

Vergelijk de server host-key vingerafdruk met een betrouwbare waarde verkregen via uw operator of een ander geverifieerd kanaal voordat u een nieuwe host-identiteit accepteert. Als een eerder bekende vingerafdruk onverwacht verandert, onderzoek dan de verandering. Het verwijderen van de client-known-hosts ingang en het accepteren van wat er ook verschijnt, bewijst niet dat u de juiste server bereikt.

Open een tweede terminal en verbind met uw werkelijke account, host en gekozen private-key pad. De optie OpenSSH -i selecteert een identiteitsbestand, en -p selecteert een niet-standaard poort wanneer deze is toegewezen. Bevestig het verwachte account na aanmelding. Een private-key-wachtwoordprompt ontgrendelt uw lokale sleutel; het is anders dan een remote-accountwachtwoordprompt.

Afwijzing diagnosticeren alvorens het inlogbeleid te wijzigen

Als de sleutel wordt geweigerd, controleer dan of u de juiste account hebt gebruikt en of de publieke sleutel overeenkomt met de persoonlijke identiteit die door de klant is geselecteerd. Bekijk de geautoriseerde-sleutel bestand locatie, eigendom en machtigingen. Op een typisch OpenSSH-account voorkomen beperkende machtigingen zoals 700 op .ssh en 600 op authorized_keys dat andere gebruikers authenticatiebestanden kunnen wijzigen; het juiste account moet ze bezitten.

Inspecteer client diagnostics en de server authenticatie logs beschikbaar voor u. Serverbeleid kan gebruikers, sleuteltypen of authenticatiecombinaties beperken. Verbreed de machtigingen niet om een afgewezen sleutelwerk te maken. Deel een geredigeerd foutbericht bij het zoeken naar hulp, in plaats van een private sleutel, wachtwoordzin of volledig gevoelige kenmerkende log.

Aanmeldingsinstellingen alleen wijzigen nadat toegang is bewezen

Een werkende sleutel verandert het wachtwoordbeleid van de server niet automatisch. Als u van plan bent de authenticatieinstellingen te wijzigen, inspecteer dan de belangrijkste OpenSSH-configuratie en alle meegeleverde bestanden die het account beïnvloeden. WachtwoordAuthenticatie en toetsenbordinteractieve authenticatie zijn aparte instellingen, en een operatorbeleid of Match-blok kan het effectieve resultaat wijzigen.

Een back-up van de relevante configuratie en valideren met de geïnstalleerde daemon voordat wijzigingen worden aangebracht; sudo sshd -t is de OpenSSH syntax controle op systemen waar dat commando en privilege van toepassing zijn. Gebruik de service-management methode die is gedocumenteerd voor uw distributie. Houd de oorspronkelijke sessie open en bewijs een nieuwe sleutelverbinding na de wijziging voordat u deze sluit.

Ga verder met de Linux VPS beveiligingschecklist

Toegang draaien en herstel onafhankelijk van één laptop houden

Geef elke beheerder zijn eigen sleutel zodat een toegangsverandering geen privébestand hoeft te delen. Als u een apparaat vervangt, installeer en test u eerst de nieuwe publieke sleutel, verwijder dan de oude publieke sleutel na het identificeren ervan. Een verloren wachtwoordzin kan niet van de versleutelde privésleutel worden hersteld; een vervanging creëren via een werkende erkende toegangsmethode.

Bekijk sleutels wanneer een teamlid vertrekt of een apparaat verloren gaat. Het verwijderen van een publieke-sleutel ingang voorkomt toekomstige sleutel logins door die ingang, maar ook het herzien van actieve sessies en andere toegangsmethoden. Houd een goedgekeurde herstelprocedure met uw service records, zodat toegang niet volledig afhankelijk is van het apparaat dat u vervangt.

• De private sleutel is nooit geüpload of naar ondersteuning gestuurd.
• Een tweede verbinding werkt met de beoogde account en identiteit.
• De host vingerafdruk is gecontroleerd via een vertrouwd kanaal.
• Herstel en intrekking van sleutels worden gedocumenteerd voordat beleidswijzigingen.

Plan onafhankelijke back-ups en herstel · Valideer een Nginx website na het instellen van toegang