Vraag Waarom is SSH-wachtwoordverificatie een beveiligingsrisico?


De meeste handleidingen voor OpenSSH-configuratie adviseren om wachtwoordverificatie uit te schakelen ten gunste van op sleutels gebaseerde verificatie. Maar naar mijn mening heeft wachtwoordverificatie een aanzienlijk voordeel: een mogelijkheid om overal zonder sleutel verbinding te maken. Als dit altijd met een sterk wachtwoord wordt gebruikt, mag dit geen beveiligingsrisico vormen. Of zou het moeten?


63
2017-11-24 12:12


oorsprong


Wachtwoorden zijn een-factor authenticatie die kan worden gesnoven, geraden en opnieuw worden afgespeeld. Sleutels zijn (mogelijk) twee factoren. Het is op sommige systemen onacceptabel om overal met slechts één factor in te kunnen loggen. - Alex Holst


antwoorden:


Er zijn voor- en nadelen voor zowel pw als op sleutels gebaseerde authenticatie.

In sommige gevallen is key-based authenticatie bijvoorbeeld minder beveiligd dan wachtwoordverificatie. In andere gevallen is de op pW gebaseerde basis minder veilig. In sommige gevallen is de ene handiger, in de andere minder.

Het komt er allemaal op neer: wanneer u key-based authenticatie doet, u moet beveilig uw sleutel met een wachtwoordzin. Tenzij u niet over een ssh-agent beschikt die u bevrijdt van het elke keer invoeren van uw wachtwoordzin, heeft u niets gewonnen qua gemak. Beveiliging is discutabel: de aanvalsvector verschoof nu van de server naar U, of uw account, of uw persoonlijke machine, (...) - die kunnen al dan niet eenvoudiger te doorbreken zijn.

Denk out of the box wanneer u dit beslist. Of u wint of verliest in termen van veiligheid, hangt af van de rest van uw omgeving en andere maatregelen.

edit: Oh, heb net gezien dat je het hebt over een homeserver. Ik zat altijd bij mij in dezelfde situatie, "wachtwoord" of "USB-stick met sleutel erop"? Ik ging voor de eerste maar veranderde de SSH luisterpoort in iets anders dan 22. Dat stopt al die lame scriptkiddies die brute hele netwerkbereiken forceren.


23
2017-11-24 13:22



Het veranderen van de SSH-poort van 22 is in veel gevallen misschien helemaal geen goed idee. adayinthelifeof.nl/2012/03/12/... - Tymek


Het gebruik van ssh-sleutels heeft één unieke functie in vergelijking met wachtwoordaanmelding: u kunt de toegestane opdrachten opgeven. Dit kan gedaan worden door te modificeren ~/.ssh/authorized_keys bestand op de server.

Bijvoorbeeld,

command="/usr/local/bin/your_backup_script.sh", ssh-rsa auiosfSAFfAFDFJL1234214DFAfDFa...

zou alleen het commando `/usr/local/bin/your_backup_script.sh" met die bepaalde sleutel toestaan.

U kunt ook de toegestane hosts voor de sleutel opgeven:

from="yourclient,yourotherclient", ssh-rsa auiosfSAFfAFDFJL1234214DFAfDFa...

Of combineer de twee:

from="yourbackupserver", command="/usr/local/bin/your_backup_script.sh", ssh-rsa auiosfSAFfAFDFJL1234214DFAfDFa...

Met sleutels kunt u ook tijdelijke toegang verlenen aan een bepaalde gebruiker (bijvoorbeeld een consultant) aan een server zonder het wachtwoord voor dat specifieke account te onthullen. Nadat de consultant zijn / haar werk heeft voltooid, kan de tijdelijke sleutel worden verwijderd.


73
2017-11-24 13:32



Zeer nuttige tip. - Sachin Divekar
Verder is het gebruik van Keys hetzelfde als het hebben van een lang wachtwoord van 2000 tekens (technisch gezien is het nog meer sterkte) in vergelijking met wat je handmatig in een terminal kunt intoetsen: D - Abhishek Dujari
Twee zeer nuttige tips over SSH-authenticatie, maar echt geen antwoord op de vraag voor mij ... - MikeMurko
Als u een met een wachtwoord geverifieerde gebruiker wilt dwingen een specifiek commando te doorlopen, wijzigt u zijn login-shell. Ook "een tijdelijke toegang verlenen zonder het wachtwoord te onthullen" is een heel slecht idee. Er zijn honderden verschillende manieren om de toegang voor later te behouden. - b0fh
Alleen de laatste paragraaf geeft antwoord op de vraag IMO-keys maken granulaire intrekking mogelijk, terwijl je met wachtwoorden iedereen moet laten weten dat je hem aan het veranderen bent. - Riking


U kunt het beste van beide werelden behalen door alleen wachtwoordverificatie vanuit uw netwerk toe te staan. Voeg het volgende toe aan het einde van uw sshd_config:

PasswordAuthentication no
Match Address 10.0.0.0/8,172.16.0.0/12,192.168.0.0/16
    PasswordAuthentication yes

45
2017-11-24 13:31



dat is een superhandige tip. ik heb een paar servers waar ik dit mee kan doen. - Sirex


Je hebt gedeeltelijk op je vraag gereageerd - hoe meer plaatsen aanvaller kan verbinden, hoe meer mogelijkheden hij heeft om in te breken in je server door bruteforcing (overweeg DDoS).

Vergelijk ook de lengte van uw wachtwoord met de sleutelgrootte (meestal duizenden bits).


6
2017-11-24 12:15



96-bits van entropie betekent een wachtwoord van 80 tekens, als het Engels is geschreven; 15 tekens als het willekeurige gebrabbel is van de afdrukbare tekenset. ben je er vrij zeker van dat je ssh-wachtwoorden zo lang / sterk zijn? - MadHatter
Als je meerdere wachtwoorden hebt met 96-bits entropie die niet kwetsbaar zijn voor woordenboekaanvallen, zul je sowieso waarschijnlijk een soort wachtwoordbeheersoftware moeten gebruiken, dus verlies je effectief het overal toegankelijke element van het gebruik van wachtwoorden . - Nick Downton
@SachinDivekar dat is 96 bits van entropie alleen als willekeurige wachtwoorden uit de set [a-zA-Z] worden gebruikt, niet als het Engelse woorden zijn. - Jaap Eldering
@NickDownton - Je kunt een mooi lang wachtwoord hebben zonder gebruik te maken van keypass-software. Zoiets als mywifesnameisangelaandshehasanicebutt is oncontroleerbaar voor woordenboekaanvallen, is erg sterk en heel eenvoudig te onthouden, maar onmogelijk te raden. En het komt met de bonus als brownie punten als je ooit je wachtwoord aan je vrouw moet geven. - Mark Henderson♦
Sorry, Mark, maar dat is verkeerd. De wachtwoordzin die u geeft, heeft 37 tekens en daarom ongeveer 44 bits entropie, die zwakker is dan 7 willekeurige afdrukbare tekens en bij uitstek kwetsbaar is. Lees het artikel van Wikipedia over het werk van Claude Shannon voor meer informatie, maar het gevolg is dat geschreven Engels zeer voorspelbaar is - bijv. Na "mijnvrouwnaam" is het woord "is" bijna gegarandeerd. Voor sterke wachtwoorden met woorden, vier willekeurig woorden die samengebonden zijn uit een woordenboek, geven je 10 ** 23 mogelijkheden, wat ongeveer 77 stukjes entropie is; nog steeds niet geweldig, maar niet slecht. - MadHatter


Wanneer u zich aanmeldt met een wachtwoord, verzendt u uw wachtwoord naar de server. Dit betekent dat de operator van de server de SSHD kan wijzigen om toegang te krijgen tot uw wachtwoord. Met openbare-sleutelauthenticatie kunnen ze uw privésleutel niet verkrijgen, omdat alleen uw openbare sleutel naar de server gaat.


6
2017-07-09 08:10



Dit is met name van belang wanneer u verbinding maakt met de verkeerde server vanwege een typfout. Op een gegeven moment was .cg bijvoorbeeld een joker die naar een enkele machine wees met ssh ingeschakeld. Telkens wanneer u .cg verkeerd zou typen voor .ch, zou u uiteindelijk verbinding maken met die box en uw wachtwoord lekken ... - b0fh


Het is een trade-off, zoals @MartinVejmelka zegt.

De reden dat u key-based auth gebruikt, is dat de sleutel zo ver boven de huidige staat of in de nabije toekomst brute dwingend dat je moet komen van je eigen pc, of de sleutel op een USB-stick of iets dergelijks moet hebben.

Een wachtwoord heeft de volgende problemen:

  • Als het kort is, kan het bruut geforceerd zijn
  • Als het lang is, wordt het gemakkelijk vergeten
  • Het kan op de schouder worden gesurfd

Een sleutel is ordes van grootte langer, en wordt op geen enkel moment getoond, dus het vermijdt deze drie problemen.


5
2017-11-24 12:43



maar het gebruik van een sleutelbestand voegt het probleem toe van het verliezen van de pen drive, of welke opslag je ook gebruikt. - João Portela
op welk punt de verloren sleutel kan worden verwijderd en een nieuwe sleutel kan worden toegevoegd. Met wachtwoorden (vooral gedeelde wachtwoorden) kan dit me een GROTE pijn bezorgen, en er is veel gekreun. - SplinterReality
Een van mijn (recent gepensioneerde) wachtwoorden: 08Forging2?seminal*^Rajas-(Posed/|. Het wordt willekeurig gegenereerd, maar ik heb geen problemen om het te onthouden. En veel geluk schouder-surfen of brute dwingen. - finnw
@finnw Correct Horse Battery Staple :-) security.stackexchange.com/q/6095/485 - Rory Alsop


SSH-sleutels voorkomen dat de man in het midden gebaseerd aanvallen op uw wachtwoord.

wanneer u probeert in te loggen met een sleutel, zal de server een uitdaging bouwen op basis van uw openbare sleutel en deze naar uw klant verzenden. die het zal ontsleutelen en een gepast antwoord zal opstellen om te verzenden.

Uw privésleutel wordt nooit naar de server verzonden en iedereen die luistert, kan niets doen behalve die enkele sessie onderscheppen.

met een wachtwoord zouden ze uw inloggegevens hebben.

Mijn oplossing is om een ​​draagbare ssh-sleutel in geschikte formaten op een gecodeerde partitie op een usb-sleutel te hebben. dit laat mij toe om:
trek die sleutel gemakkelijk terug in het geval dat hij verloren gaat.
beperken welke servers het mij toegang geeft
en draag het nog steeds rond

hoewel het installeren van de mount-software lastig is (truecrypt)


5
2017-11-25 11:04



Dit is fout. Zodra je de publieke sleutel van de server kent (wat je doet als je hem aan je cache hebt toegevoegd en niet MITM hebt gekregen bij de eerste verbinding) ben je immuun voor MITM-aanvallen. Sleutel- / wachtwoordgebaseerde authenticatie heeft hier niets mee te maken. Het wachtwoord is nooit verzonden over de draad heen, een beveiligde verbinding op machine-niveau authenticatie (wat is je / mijn publieke sleutel) is altijd ingesteld voor authenticatie op gebruikersniveau (wat is je wachtwoord / bewijs me dat deze publieke sleutel van jou is). - Thomas
Thomas, in werkelijkheid negeren veel mensen de waarschuwing over een verandering van vingerafdruk. Pubkey auth garandeert MITM-beveiliging zelfs als de privésleutel van de server op een of andere manier op de een of andere manier wordt gehackt of een mensentype "ja" afwezig: de aanvaller moet kiezen tussen het niet kunnen zien van het verkeer en het verzenden van een openbare sleutel die niet inlogt, wat een winnen. - Score_Under
En voor de antwoordgever: u hoeft geen truecrypt te gebruiken, openssh privésleutels worden geleverd met hun eigen optionele codering op basis van wachtwoord. - Score_Under


Goede punten die hier al zijn genoemd.

Wat ik als het grootste risico beschouw, gezien het feit dat je met een sterk wachtwoord voor de basis hebt gezorgd, is dat veel computers keyloggers hebben geïnstalleerd zonder dat de gebruiker het beseft. Er zijn zelfs mensen die hele sites maken met handige hulpprogramma's die trojaanse paarden bevatten, dus het kan de beste van ons overkomen. Een keylogger mailt bijvoorbeeld de inloggegevens naar een hacker die dan gemakkelijk toegang tot de server kan krijgen.

Ik heb onlangs door Norton gewaarschuwd voor het downloaden van het Zombee Mod-installatieprogramma (niet de pot, het installatieprogramma) voor het toevoegen van vlucht aan de Minecraft-pot. Ik heb de details bekeken en Norton heeft een heleboel hulpprogramma's op deze site vermeld die waren gemarkeerd als een trojan. Ik weet niet of dit klopt of niet, maar het was behoorlijk specifiek met bestandsnamen. Het is ook een bekend feit dat Trojaanse paarden in (sommige) warez worden geplaatst voordat ze worden verspreid.


2
2017-11-24 19:28





Een mogelijk voordeel van SSH ten opzichte van wachtwoorden is dat als u geen SSH-wachtwoordzin opgeeft, u nooit meer een wachtwoord hoeft in te voeren ... uw computer intrinsiek vertrouwd is op de server omdat deze de sleutel heeft. Dat gezegd hebbende, gebruik ik meestal altijd een SSH-wachtwoordzin, dus ik beslis dat voordeel.

Ik vind het beste antwoord waarom gebruikershandleidingen SSH vaak aanbevelen bij wachtwoordverificatie afkomstig is van de Ubuntu-handleiding voor SSHOpenSSHKeys. Ik citeer,

Als je het niet belangrijk vindt, probeer dan alle kwaadwillende inlogpogingen die je krijgt voor de volgende week te loggen. Mijn computer - een heel gewone desktop-pc - had meer dan 4000 pogingen om mijn wachtwoord te raden en bijna 2.500 inbraakpogingen in de laatste week alleen. Hoeveel duizend willekeurige gissingen denk je dat het zal duren voordat een aanvaller je wachtwoord tegenkomt?

In wezen als je een solide, lang wachtwoord hebt met interpunctie, hoofdletters en kleine letters en cijfers ... zul je waarschijnlijk in orde zijn met wachtwoordverificatie. Ook als u van plan bent om uw logboeken te controleren en geen "superveilige" dingen doet in het hele netwerk ... d.w.z. het gebruiken voor een thuisserver. In elk geval werkt een wachtwoord goed.


2
2017-11-24 23:48





Passwd authenticatiemethode is echt onveilig (imho). Met dit mechanisme wordt het wachtwoord naar de sshd-server verzonden (zoals @ramon al heeft gezegd). Dit betekent dat sommige personen de sshd-server kunnen aanpassen om het wachtwoord op te halen. Met een Man-in-The-Middle-aanval is dit heel gemakkelijk te bereiken binnen een lokaal netwerk.

U kunt de sshd-server gewoon patchen door deze patch te installeren (https://github.com/jtesta/ssh-mitm). Gebruik arpspoof en iptables om je gepatchte server tussen de client en de authentieke sshd-server te plaatsen.

Schakel alstublieft wachtwoord auth uit: open het configuratiebestand /etc/ssh/ssh_config en voeg de regel toe PasswordAuthentication no.


1
2018-05-20 14:17



Controleert de SSH-client de server niet op RSA-vingerafdrukken? Nadat je ten minste één keer naar deze server hebt verwezen, wordt de vingerafdruk onthouden, dus in het geval van mogelijke MITM-aanvallen zou SSH een waarschuwing laten oplichten, toch? - Septagram
Ja. De waarschuwing verschijnt maar omdat 99% van de tijd dit wordt veroorzaakt door os herinstallatie, configuratie veranderd ecc, zullen de meeste gebruikers de waarschuwing negeren en doorgaan. - Pioz
@Septagram Veel shell-accountproviders hebben niet de gewoonte om de huidige vingerafdruk van de server te plaatsen voor nieuwe abonnees, voor de migratie van gebruikersaccounts naar nieuwe servers, enz. - Damian Yerrick