SSH-sleutelauthenticatie instellen: Ed25519, ssh-agent en serverbeveiliging

AI_Manager

SSH-sleutelauthenticatie. Dit is geen truc om wachtwoorden te elimineren, maar een vertrouwensprocedure die bestaat uit het verifiëren van de serveridentiteit, het beschermen van de privésleutel, het distribueren van de openbare sleutel, het verifiëren van nieuwe sessies en het versterken van het inlogbeleid. De privésleutel wordt nooit buiten de client gekopieerd en wordt beschermd door een wachtwoordzin en ssh-agent.

Deze handleiding legt de operationele volgorde uit voor het instellen van SSH-sleutelauthenticatie op basis van Ed25519, inclusief RSA-alternatieven voor de FIPS-modus, known_hosts-verificatie, machtigingen voor authorized_keys, controle van de sshd-configuratie, sleutelintrekking en herstel bij fouten.

SSH-sleutelauthenticatie: onderscheid tussen twee verificaties

Alleen authenticatie met een openbare sleutel is niet veilig genoeg. De vingerafdruk van de host-sleutel van de server moet worden gecontroleerd via een betrouwbare console, een assetbeheersysteem of een afzonderlijk kanaal om aanvallen waarbij de doelserver is vervangen te detecteren.

Een sleutel met een wachtwoordzin genereren op de client

Voor algemene omgevingen is Ed25519 de beknopte en veilige standaard. Omdat Ed25519 echter mogelijk niet is toegestaan in de FIPS-modus, moet in dat beleid een RSA-sleutel van voldoende lengte worden gebruikt. Geef bestandsnamen op per doel om te voorkomen dat bestaande sleutelbestanden worden overschreven.

install -d -m 0700 ~/.ssh
ssh-keygen -t ed25519 -a 100   -f ~/.ssh/id_ed25519_ops   -C 'ops-admin@client'
chmod 0600 ~/.ssh/id_ed25519_ops
chmod 0644 ~/.ssh/id_ed25519_ops.pub

RSA-alternatieven voor FIPS-beleid

ssh-keygen -t rsa -b 3072 -o -a 100   -f ~/.ssh/id_rsa_ops   -C 'ops-admin@client'

Het privésleutelbestand mag niet worden gekopieerd naar servers, tickets, messengers of Git-repositories. Het enige dat naar de server wordt gedistribueerd, is de regel met de openbare sleutel met de extensie .pub.

Beheer de ontgrendelde status van sleutels met ssh-agent

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519_ops
ssh-add -l

Verifieer de vingerafdruk van de host-sleutel van de server via een afzonderlijk kanaal

Druk de vingerafdruk van de openbare host-sleutel af op de serverconsole en vergelijk deze met de vingerafdruk die de client voor het eerst ziet. ssh-keyscan verzamelt alleen sleutels en bewijst niet dat de sleutel van de echte server is, dus vertrouw de resultaten niet zonder verificatie.

sudo ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub
sudo ssh-keygen -lf /etc/ssh/ssh_host_rsa_key.pub

ssh-keyscan -t ed25519 server.example.com > /tmp/server.hostkey
ssh-keygen -lf /tmp/server.hostkey
install -m 0600 /tmp/server.hostkey ~/.ssh/known_hosts.ops
rm -f /tmp/server.hostkey

Gebruik het known_hosts-bestand alleen als de SHA256-vingerafdruk van de bovenstaande twee uitvoeren exact overeenkomt met de waarde die via een afzonderlijk kanaal is bevestigd. Als er een discrepantie is, stop dan de verbinding en onderzoek DNS, IP en installatiegeschiedenis.

SSH-sleutelauthenticatie: de publieke sleutel distribueren naar authorized_keys

Wanneer u SSH-sleutelauthenticatie voor het eerst instelt, maakt u eenmalig verbinding via het momenteel toegestane wachtwoord of de console om de publieke sleutel toe te voegen. Als u ssh-copy-id kunt gebruiken, zijn duplicatie en rechtenbeheer eenvoudig.

ssh-copy-id -i ~/.ssh/id_ed25519_ops.pub ops@server.example.com

Handmatige distributie wanneer ssh-copy-id niet beschikbaar is

cat ~/.ssh/id_ed25519_ops.pub   | ssh ops@server.example.com     'umask 077; mkdir -p ~/.ssh; cat >> ~/.ssh/authorized_keys'

# Vanaf hier uitvoeren in de ops-gebruikerssessie van de server.
chmod 0700 ~/.ssh
chmod 0600 ~/.ssh/authorized_keys
restorecon -RFv ~/.ssh

In RHEL-gebaseerde systemen waar SELinux is ingeschakeld, moeten niet alleen de bestandsrechten, maar ook de context correct zijn. Controleer ook of de thuismap niet schrijfbaar is voor andere gebruikers.

Clientaliassen en expliciete sleutelselectie

Host prod-app-01
    HostName server.example.com
    User ops
    IdentityFile ~/.ssh/id_ed25519_ops
    IdentitiesOnly yes
    UserKnownHostsFile ~/.ssh/known_hosts.ops

chmod 0600 ~/.ssh/config
ssh -v prod-app-01

SSH-sleutelauthenticatie: verificatie voordat wachtwoordaanmelding wordt uitgeschakeld

Controleer de aanmelding met de publieke sleutel in een aparte terminal zonder de huidige beheerderssessie te sluiten. Schakel PasswordAuthentication niet uit voordat u de herstelmethode via de console en de sudo-rechten hebt geverifieerd.

ssh -o PreferredAuthentications=publickey   -o PasswordAuthentication=no   prod-app-01
sudo -v
whoami

sshd-configuratiesyntaxis en verificatie van de werkelijk toegepaste waarden

sudo sshd -t
sudo sshd -T   | grep -E '^(pubkeyauthentication|passwordauthentication|kbdinteractiveauthentication|permitrootlogin) '

Nadat de sleutelauthenticatie is geverifieerd, scheidt u het beleid in een drop-in bestand. Omdat de uiteindelijke waarden kunnen variëren afhankelijk van de include-volgorde van de distributie en Match-blokken, moet u dit controleren met de uitvoer van sshd -T in plaats van alleen naar de bestandsinhoud te kijken.

sudo install -d -m 0755 /etc/ssh/sshd_config.d
sudo tee /etc/ssh/sshd_config.d/20-key-auth.conf >/dev/null <<'CONF'
PubkeyAuthentication yes
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
CONF

sudo sshd -t
sudo sshd -T | grep -E "^(pubkeyauthentication|passwordauthentication|kbdinteractiveauthentication|permitrootlogin) "
sudo systemctl reload sshd

ssh -o PreferredAuthentications=publickey prod-app-01
sudo journalctl -u sshd --since '-10 minutes' --no-pager

SSH-sleutelauthenticatie: beperking van sleutelbereik en intrekking

Scheid automatiseringssleutels van algemene beheerderssleutels en beperk indien nodig de bron of functionaliteit met authorized_keys-opties. Test deze beperkingsopties eerst in een testomgeving, aangezien ze tunneling- of PTY-acties die de service daadwerkelijk nodig heeft, kunnen blokkeren.

from="198.51.100.0/24",restrict ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAA... deploy-key

Als een sleutel is gelekt of een gebruiker vertrekt, verwijdert u de betreffende regel met de publieke sleutel. Als centrale intrekking vereist is, kunt u een OpenSSH KRL aanmaken en deze koppelen aan RevokedKeys in sshd. Als er al een KRL bestaat, gebruikt u -u om de bestaande intrekkingslijst te behouden tijdens het bijwerken, en vervangt u deze atomair nadat u deze in een tijdelijk bestand op hetzelfde bestandssysteem hebt voltooid. Als sshd de KRL niet kan lezen, kan alle authenticatie via publieke sleutels worden geweigerd, dus behoud de bestaande beheerderssessie en de herstelconsole. Voor servers die Match-blokken gebruiken, specificeert u de werkelijke verbindingsvoorwaarden, zoals sshd -T -C user=ops,host=client.example.com,addr=198.51.100.10, om dit te verifiëren.

KRL_STAGE_DIR=$(sudo mktemp -d /etc/ssh/krl-stage.XXXXXX)
if sudo test -f /etc/ssh/revoked.krl; then
  sudo cp -p /etc/ssh/revoked.krl "$KRL_STAGE_DIR/revoked.krl"
  sudo ssh-keygen -k -u -f "$KRL_STAGE_DIR/revoked.krl" compromised_key.pub
else
  sudo ssh-keygen -k -f "$KRL_STAGE_DIR/revoked.krl" compromised_key.pub
fi
sudo chown root:root "$KRL_STAGE_DIR/revoked.krl"
sudo chmod 0644 "$KRL_STAGE_DIR/revoked.krl"
sudo mv "$KRL_STAGE_DIR/revoked.krl" /etc/ssh/revoked.krl
sudo rmdir "$KRL_STAGE_DIR"
sudo restorecon /etc/ssh/revoked.krl
sudoedit /etc/ssh/sshd_config.d/20-key-auth.conf
# Voeg de volgende regel toe aan de globale instellingen in het bovenstaande bestand.
# RevokedKeys /etc/ssh/revoked.krl
sudo sshd -t
sudo sshd -T | grep "^revokedkeys "
sudo systemctl reload sshd

SSH-sleutelauthenticatie: probleemoplossing

ssh -vvv prod-app-01
ssh-add -l
ssh-keygen -lf ~/.ssh/id_ed25519_ops.pub
sudo journalctl -u sshd -b --no-pager
sudo namei -l /home/ops/.ssh/authorized_keys
sudo ls -ldZ /home/ops /home/ops/.ssh /home/ops/.ssh/authorized_keys
sudo sshd -T

• Als er na ‘Offering public key’ een weigering volgt, controleer dan de gebruiker, de regel met de publieke sleutel, de rechten en de SELinux-context.
• Bij ‘Too many authentication failures’, specificeert u IdentitiesOnly en IdentityFile.
• Verwijder bij ‘REMOTE HOST IDENTIFICATION HAS CHANGED’ niet zomaar de sleutel, maar verifieer of de server opnieuw is geïnstalleerd of dat de DNS is gewijzigd.
• Als u na een configuratiewijziging geen verbinding meer kunt maken, draai de wijzigingen in de drop-in dan terug via een bestaande sessie of console en voer sshd -t uit.

Officiële documentatie en gerelateerde operationele handleidingen

• Red Hat: Veilige communicatie configureren met OpenSSH
• OpenSSH sshd_config handleiding
• OpenSSH ssh-keygen handleiding
• Ansible-playbooks en SSH-automatiseringsbeveiliging
• Beheerdersaccounts en host-sleutelverificatie in Kubespray

Bij SSH-sleutelauthenticatie is het beheer van de operationele levenscyclus belangrijker dan het genereren van de sleutel zelf. Wachtwoordloze toegang leidt pas tot een daadwerkelijke beveiligingsverbetering als u de privésleutel alleen op de client bewaart, de server-fingerprint verifieert, nieuwe sessies controleert voordat u het beleid aanscherpt en gelekte sleutels onmiddellijk kunt intrekken.