SSH sleutels

Een SSH-sleutel is een toegangscredential in het SSH-protocol. De functie is vergelijkbaar met die van gebruikersnamen en wachtwoorden, maar de sleutels worden vooral gebruikt voor geautomatiseerde processen en voor het implementeren van single sign-on door systeembeheerders en power users.

SSH sleutels zijn authenticatiecredentials

SSH (Secure Shell) wordt gebruikt voor het beheren van netwerken, besturingssystemen en configuraties. Het zit ook in veel bestandsoverdracht tools en configuratie management tools. Elk groot bedrijf gebruikt het, in elk datacenter.

SSH keys maken de automatisering mogelijk die moderne cloud services en andere computer-afhankelijke diensten mogelijk en kosten-effectief maakt. Ze bieden gemak en betere beveiliging als ze goed worden beheerd.

Functioneel lijken SSH-sleutels op wachtwoorden. Ze geven toegang en controleren wie toegang heeft tot wat. Voor identiteits- en toegangsbeheer hebben ze een vergelijkbaar beleid, provisionering en beëindiging nodig als gebruikersaccounts en wachtwoorden. Vertrouwelijkheid, integriteit, of garanties voor continue beschikbaarheid van systemen zijn niet mogelijk zonder controle over SSH-sleutels.

Technisch gezien zijn de sleutels cryptografische sleutels die gebruik maken van een public key cryptosysteem. Functioneel gezien zijn het echter authenticatiegegevens en ze moeten als zodanig worden beheerd.

Geautoriseerde sleutels bepalen wie toegang heeft tot elk systeem

Geautoriseerde sleutels zijn publieke sleutels die toegang verlenen. Ze zijn analoog aan sloten die de corresponderende private sleutel kan openen.

Voor meer informatie, zie de speciale pagina over authorized keys.

Identity keys identificeren gebruikers en geven toegang

Identity keys zijn private sleutels die een SSH client gebruikt om zichzelf te authenticeren bij het inloggen op een SSH server. Ze zijn analoog aan fysieke sleutels die een of meer sloten kunnen openen.

Geautoriseerde sleutels en identiteitssleutels worden samen gebruikerssleutels genoemd. Ze hebben betrekking op gebruikersauthenticatie, in tegenstelling tot hostsleutels die worden gebruikt voor hostauthenticatie.

Voor meer informatie, zie de speciale pagina over identiteitssleutels.

Gebaseerde gebruikersauthenticatie op basis van certificaten

PKI-certificaten kunnen ook worden gebruikt voor authenticatie. In dit geval heeft de gebruiker nog steeds een private sleutel, maar ook een certificaat dat aan de sleutel is gekoppeld. Deze technologie wordt ondersteund in zowel Tectia SSH als OpenSSH, met enkele verschillen. Zie voor meer informatie de speciale pagina over authenticatie op basis van certificaten in SSH.

Authenticatiesleutels

Hostsleutels authenticeren servers

Hostsleutels worden gebruikt voor het authenticeren van hosts, d.w.z. computers. Het doel is om man-in-the-middle aanvallen te voorkomen. Zie de aparte pagina over host keys voor meer informatie.

Host-authenticatie op basis van een certificaat kan een zeer aantrekkelijk alternatief zijn in grote organisaties. Hiermee kunnen sleutels voor apparaatauthenticatie gemakkelijk worden geroteerd en beheerd en kan elke verbinding worden beveiligd.

Bekende hostsleutels

Eén van de unieke eigenschappen van SSH is dat het standaard de sleutel van de host vertrouwt en onthoudt wanneer er voor het eerst verbinding mee wordt gemaakt. Dit was een belangrijke onderscheidende factor die het mogelijk maakte SSH van onderaf in te zetten, omdat er in 1995 geen gecentraliseerde sleutelinfrastructuur voor hosts was, en die is er vandaag de dag (2017) nog steeds niet, met uitzondering van SSL-certificaten voor webservers. Het daaruit voortvloeiende gemak van implementatie was een van de belangrijkste redenen waarom SSH succesvol werd.

De gememoriseerde host sleutels worden bekende host sleutels genoemd en ze worden opgeslagen in een bestand genaamd known_hosts in OpenSSH. Zolang de host keys niet veranderen, is deze aanpak heel gemakkelijk te gebruiken en biedt hij redelijk goede beveiliging. Echter, in grote organisaties en wanneer de sleutels veranderen, kan het onderhouden van bekende hosts-bestanden erg tijdrovend worden. Het gebruik van certificaten voor hostsleutels wordt in dat geval aangeraden. Tectia SSH ondersteunt standaard X.509 certificaten voor hosts. OpenSSH heeft zijn eigen propriëtaire certificaatformaat. Het voordeel van standaardgebaseerde certificaten is dat ze kunnen worden uitgegeven door elke certificaatautoriteit (CA), terwijl er geen betrouwbare CA’s bestaan voor OpenSSH-sleutels. Zie de speciale pagina over certificaten met SSH voor meer informatie.

Session keys

Een sessie sleutel in SSH is een encryptie sleutel die wordt gebruikt voor het versleutelen van het grootste deel van de data in een verbinding. De sessiesleutel wordt onderhandeld tijdens de verbinding en wordt dan gebruikt met een symmetrisch encryptie algoritme en een bericht authenticatie code algoritme om de gegevens te beschermen. Voor meer informatie, zie de aparte pagina over sessie sleutels.

Hoe stel je sleutel-gebaseerde authenticatie in

Sleutel-gebaseerde authenticatie in SSH wordt publieke sleutel-authenticatie genoemd. Het is eenvoudig te configureren door eindgebruikers in de standaard configuratie. Aan de andere kant moeten beveiligingsbewuste organisaties een duidelijk beleid opstellen voor het verlenen en beëindigen van sleutel-gebaseerde toegang.

Hoe publieke sleutelauthenticatie voor OpenSSH in te stellen

SSH-sleutels worden gewoonlijk geconfigureerd in een authorized_keys bestand in .ssh subdirectory in de homedirectory van de gebruiker. Typisch zou een systeembeheerder eerst een sleutel aanmaken met ssh-keygen en deze dan installeren als een geauthoriseerde sleutel op een server met het ssh-copy-id gereedschap. Zie ook de speciale pagina over het configureren van geautoriseerde sleutels voor OpenSSH.

We raden aan om passphrases te gebruiken voor alle identiteitssleutels die worden gebruikt voor interactieve toegang. In principe raden we aan om ook passphrases te gebruiken voor geautomatiseerde toegang, maar dit is vaak niet praktisch.

Sleutels opslaan in ssh-agent voor single sign-on

SSH wordt geleverd met een programma genaamd ssh-agent, dat de gedecodeerde private sleutels van gebruikers in het geheugen kan bewaren en ze kan gebruiken om logins te authenticeren. De agent kan ook worden gebruikt om toegang te krijgen tot sleutels op een smartcard of in een Hardware Security Module (HSM). Zie de documentatie voor ssh-agent over hoe het in te stellen.

De verbinding met de SSH-agent kan worden doorgestuurd naar een server, zodat single sign-on ook vanaf die server werkt. Deze functie moet voorzichtig worden gebruikt, omdat het een gecompromitteerde server in staat stelt om de gebruikersgegevens van de oorspronkelijke agent te gebruiken. Agent forwarding kan echter een belangrijke gemaksfunctie zijn voor power users in minder veiligheidskritische omgevingen.

Om agent forwarding in te schakelen, stel AllowAgentForwarding in op yes in /etc/ssh/sshd_config op de server en ForwardAgent op yes in het client configuratie bestand /etc/ssh/ssh_config.

Aanbevolen sleutelgroottes

We raden aan sleutelgroottes te kiezen volgens NIST SP 800-57. De standaard sleutelgroottes die door het ssh-keygen gereedschap worden gebruikt zijn over het algemeen van acceptabele sterkte. Omdat het protocol nooit de openbare sleutels onthult die acceptabel zijn voor gebruikersauthenticatie, zijn de algoritmen die voor de sleutels worden gebruikt niet zo kritisch als ze zijn in bijvoorbeeld PKI-certificaten.

Voor RSA-sleutels is 2048 bits vandaag de dag (2017) waarschijnlijk een goede keuze. Veel cryptografen raden nu echter aan over te stappen op ECDSA-sleutels en denken dat de vooruitgang in het ontbinden van grote gehele getallen RSA-sleutels op korte of middellange termijn kwetsbaar kan maken. Voor ECDSA raden we aan om 521 bit (sic!) sleutels te gebruiken, ook al zouden 384 of zelfs 256 bit sleutels waarschijnlijk veilig zijn. Er is gewoon geen praktisch voordeel van het gebruik van kleinere sleutels.

Identiteitssleutel locatie

Identiteitssleutels worden meestal opgeslagen in de .ssh directory van een gebruiker, bijvoorbeeld, .ssh/ssh_id_rsa. De standaard bestandsnaam van de identiteitssleutel begint met id_<algorithm>. Het is echter mogelijk om gelijk welke bestandsnaam en gelijk welke locatie op te geven bij het aanmaken van een private sleutel, en de padnaam mee te geven met de -i optie aan de SSH client. Bijvoorbeeld, ssh -i /home/ylo/secure/my-key [email protected] zou een private sleutel uit het bestand my-key voor authenticatie gebruiken.

De standaard locatie van de identiteitssleutel kan ook worden geconfigureerd in /etc/ssh/ssh_config of in het .ssh/config bestand van de gebruiker met de IdentityFile optie.

Geautoriseerde sleutel locatie

Wanneer een gebruiker probeert in te loggen met sleutel-gebaseerde authenticatie, zoekt de OpenSSH server naar geautoriseerde sleutels in een directory die is opgegeven in de server configuratie met de AuthorizedKeysFile optie. De standaard is .ssh/authorized_keys in de home directory van de gebruiker.

Het hebben van de geauthoriseerde sleutels in de home directory van de gebruiker betekent echter dat de gebruiker nieuwe sleutels kan toevoegen die logins voor zijn/haar account autoriseren. Dit is handig, maar de gebruiker kan deze sleutels dan aan vrienden of collega’s geven, of zelfs verkopen voor Bitcoins (dit is echt gebeurd). SSH-sleutels zijn bovendien permanent en blijven geldig totdat ze uitdrukkelijk worden verwijderd.

Als geautoriseerde sleutels worden toegevoegd voor root- of service-accounts, blijven ze gemakkelijk geldig, zelfs nadat de persoon die ze heeft geïnstalleerd de organisatie heeft verlaten. Ze zijn ook een gemakkelijke manier voor hackers om permanent aanwezig te zijn op een systeem als er geen detectie en waarschuwingen zijn over ongeautoriseerde nieuwe sleutels.

Om deze redenen willen de meeste grotere organisaties geautoriseerde sleutels verplaatsen naar een locatie die eigendom is van de root en een gecontroleerd provisionerings- en beëindigingsproces voor ze instellen.

SH-sleutels naar een root-locatie verplaatsen

In principe is het verplaatsen van SSH-sleutels naar een root-locatie eenvoudig:

Maak een geschikte root-directory aan, bijv, /etc/ssh/keys, waarin geautoriseerde sleutels worden opgeslagen.
Maak onder deze directory een subdirectory aan voor elke gebruiker, en verplaats het authorized_keys-bestand van elke gebruiker naar /etc/ssh/keys/<user>/authorized_keys.
Ten slotte wijzigt u de set AuthorizedKeysFile /etc/ssh/keys/%u/authorized_keys in /etc/ssh/sshd_config.

In de praktijk is dit echter niet altijd zo eenvoudig, vooral niet in grotere omgevingen. Gebruikersnamen kunnen afkomstig zijn uit directories (bijv. Active Directory of LDAP). Veel organisaties hebben verschillende versies van OpenSSH, waaronder zeer oude systemen of aangepaste SSH-bouwsels die niet-standaard ingebouwde paden hebben. Wij raden aan sleutelbeheerprogramma’s zoals Universal SSH Key Manager te gebruiken om deze complexiteit in grotere omgevingen te verbergen. Deze tools kunnen ook een provisioning, beëindiging en goedkeuringsworkflow voor sleutels implementeren en waarschuwen over ongeautoriseerde wijzigingen door root-gebruikers.

OpenSSH’s beperking op het aantal private keys

De OpenSSH server heeft een eigenschap (ik zou het een bug noemen) dat het testen of een bepaalde sleutel gebruikt kan worden voor authenticatie meetelt als een authenticatiepoging. Dit heeft tot gevolg dat als de gebruiker meer dan vijf sleutels heeft in .ssh, slechts enkele ervan werken. Dit zorgt er vaak voor dat sleutel-gebaseerde authenticatie mislukt en is voor gebruikers vaak moeilijk te achterhalen. De manier om dit te omzeilen is om expliciet de te gebruiken private sleutel op te geven met de -i optie. Een alternatief is om de MaxAuthTries sessie op de server aan te passen, maar dit is geen volledige oplossing en het is onwenselijk om het aantal pogingen voor wachtwoord authenticatie te verhogen.

Hoe zien SSH-sleutels eruit

Een geautoriseerde sleutel kan er als volgt uitzien:

ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBN+Mh3U/3We4VYtV1QmWUFIzFLTUeegl1Ao5/QGtCRGAZn8bxX9KlCrrWISIjSYAwCajIEGSPEZwPNMBoK8XD8Q= ylo@klar

Een identiteitssleutel kan er als volgt uitzien:

Hoe werkt authenticatie in SSH?

Het initialiseren van een verbinding in SSH bestaat uit:

Onderhandelen over de versie van het protocol die moet worden gebruikt
Onderhandelen over cryptografische algoritmen en andere opties die moeten worden gebruikt
Onderhandelen over een één-eenmalige sessiesleutel voor het versleutelen van de rest van de sessie
Authenticatie van de serverhost met behulp van zijn hostsleutel
Authenticatie van de gebruiker met behulp van een wachtwoord, openbare-sleutelauthenticatie of andere middelen.

Daarna kunnen gegevens worden uitgewisseld, waaronder terminalgegevens, afbeeldingen en bestanden.

SSH Key - Authenticatie met behulp van SSH-sleutels

Authenticatie met behulp van een openbare sleutel

Het op sleutels gebaseerde authenticatiemechanisme in SSH wordt authenticatie met een openbare sleutel genoemd. In essentie worden sessie-specifieke gegevens ondertekend met de private identiteitssleutel. De handtekening wordt dan naar de server gestuurd die controleert of de sleutel die gebruikt is voor het ondertekenen is geconfigureerd als een geautoriseerde sleutel. De server verifieert dan de digitale handtekening met de openbare sleutel in de geautoriseerde sleutel. De identiteitssleutel wordt nooit naar de server gestuurd.

Het essentiële van publieke-sleutelauthenticatie is dat het een server toegang geeft tot een andere server zonder een wachtwoord te hoeven intypen. Deze krachtige eigenschap is de reden waarom het zo wijdverbreid wordt gebruikt voor bestandsoverdracht (met behulp van het SFTP-protocol) en configuratiebeheer. Het wordt ook veel gebruikt door systeembeheerders voor single sign-on.

Hoe gebruikelijk zijn SSH-sleutels en wat is het risico

SSH-sleutels blijken uiterst gebruikelijk en wijdverbreid te zijn. Veel grote organisaties hebben ze twintig jaar lang verzameld zonder enige controle. Een typische Fortune 500 onderneming heeft enkele miljoenen sleutels die toegang verlenen tot hun servers. Bij een klant onderzochten we 500 applicaties en 15.000 servers, en vonden we 3.000.000 geautoriseerde sleutels en 750.000 unieke sleutelparen. Deze organisatie had ook meer dan vijf miljoen dagelijkse logins met sleutels. De sleutels werden gebruikt voor het uitvoeren van financiële transacties, het bijwerken van configuraties, het verplaatsen van loggegevens, bestandsoverdrachten, interactieve logins door systeembeheerders, en vele andere doeleinden.

Het blijkt dat de meeste grote ondernemingen over honderdduizenden of zelfs miljoenen sleutels beschikken. Deze sleutels vormen toegang die niet kan worden verantwoord, en kunnen de hele onderneming in gevaar brengen.

Hoe SSH-sleutels volledig te elimineren

De PrivX On-Demand Access Manager kan worden gebruikt om SSH-sleutels volledig van servers te elimineren en op beleid gebaseerde toegangscontrole en sessie-logging in de hele onderneming in te stellen. Het elimineert ook het grootste deel van de administratieve last bij het beheren van sleutels, terwijl het nog steeds de voordelen biedt: automatisering en single sign-on.