Computerbeveiliging
- Hoe je bad guys buiten de deur houdt
SSH keys in de handen van een andere wat dan?
11-10-2019, 17:33 door Anoniem, 17 reacties
Stel je voor meerdere mensen hebben toegang tot mijn computer en komen zo bij mij SSH keys (private en public)
Hoe kan de server nog identificeren dat de juiste persoon gebruik maakt van de SSH keys wanneer deze persoon ook mijn wachtwoord zou weten?
(Niet dat dit het geval is maar vraag dit uit intresse)
Hoe kan de server nog identificeren dat de juiste persoon gebruik maakt van de SSH keys wanneer deze persoon ook mijn wachtwoord zou weten?
(Niet dat dit het geval is maar vraag dit uit intresse)
Reacties (17)
Door Anoniem:
Hoe kan de server nog identificeren dat de juiste persoon gebruik maakt van de SSH keys wanneer deze persoon ook mijn wachtwoord zou weten?
Hoe kan de server nog identificeren dat de juiste persoon gebruik maakt van de SSH keys wanneer deze persoon ook mijn wachtwoord zou weten?
Niet natuurlijk.. Keys intrekken en nieuwe keys aanmaken en wachtwoord wijzigen in geval van compromise.
Simpel: Gooi jouw gecompromitteerde sleutels uit de authorized_keys op de server en vervang met nieuwe sleutels. En ik ga er ook van uit dat ook de regels
PasswordAuthentication no
ChallengeResponseAuthentication no
in je sshd_config hebt staan, zodat je alleen met de sleutels kunt inloggen.ChallengeResponseAuthentication no
12-10-2019, 01:03 door
botbot
Door Anoniem: Stel je voor meerdere mensen hebben toegang tot mijn computer en komen zo bij mij SSH keys (private en public)
Hoe kan de server nog identificeren dat de juiste persoon gebruik maakt van de SSH keys wanneer deze persoon ook mijn wachtwoord zou weten?
(Niet dat dit het geval is maar vraag dit uit intresse)
Hoe kan de server nog identificeren dat de juiste persoon gebruik maakt van de SSH keys wanneer deze persoon ook mijn wachtwoord zou weten?
(Niet dat dit het geval is maar vraag dit uit intresse)
Mmm waarom zou iemand ook je wachtwoord van je private SSH key weten? Kijk als ze dat weten, dan is er geen verschil tussen jou en die andere persoon. Ik bedoel in principe, en dat wordt niet vaak genoeg strict gehanteerd, weet *nooit* iemand anders een wachtwoord van jouw persoonlijke account/key/whatever. Nooit. Voor geen enkel account.
Als anderen het wachtwoord van jouw key hebben dan is het niet jouw persoonlijke key. Vergelijk het met een gedeeld account: familiejansen. Waarin iedereen van de fam. Jansen het wachtwoord weet. Dan is iedereen die daarmee inlogt geauthenticeerd als familiejansen. Of het Pietje, Janje of Klaasje is. Dat is zo bedacht. En dat is de bedoeling.
Als anderen het wachtwoord van je SSH key weten is het een gedeelde key. Dat is dan de bedoeling, of er is sprake van kwade opzet, dat ze je wachtwoord zonder jouw medeweten gestolen hebben. Een andere valide mogelijkheid is er niet.
Door Anoniem: Stel je voor meerdere mensen hebben toegang tot mijn computer en komen zo bij mij SSH keys (private en public)
Hoe kan de server nog identificeren dat de juiste persoon gebruik maakt van de SSH keys wanneer deze persoon ook mijn wachtwoord zou weten?
(Niet dat dit het geval is maar vraag dit uit intresse)
Hoe kan de server nog identificeren dat de juiste persoon gebruik maakt van de SSH keys wanneer deze persoon ook mijn wachtwoord zou weten?
(Niet dat dit het geval is maar vraag dit uit intresse)
Natuurlijk kan de server niet weten welk stuk vlees en bloed de SSH key aanbiedt (en/of het wachtwoord) als die key bij meerdere mensen bekend is.
Duh.
Magie bestaat niet.
De private key wordt geacht alleen bij de eigenaar bekend te zijn.
Als je een (goede) passphrase op de private key zet beperk je op die manier de mogelijkheden van anderen om de private key ook te gebruiken , ook al kunnen ze erbij.
Als de computer voldoende gehacked is, kunnen er keyloggers geinstalleerd zijn om je passphrase te capturen als jij 'm intikt.
Het is aan jou om in te schatten hoe waardevol de server access is, en hoe kwaadwillend (of slordig) de medegebruikers zijn van het systeem waarop je private key staat .
Door Anoniem: Stel je voor meerdere mensen hebben toegang tot mijn computer en komen zo bij mij SSH keys (private en public)
Hoe kan de server nog identificeren dat de juiste persoon gebruik maakt van de SSH keys wanneer deze persoon ook mijn wachtwoord zou weten?
(Niet dat dit het geval is maar vraag dit uit intresse)
Hoe kan de server nog identificeren dat de juiste persoon gebruik maakt van de SSH keys wanneer deze persoon ook mijn wachtwoord zou weten?
(Niet dat dit het geval is maar vraag dit uit intresse)
De server identificeert niet maar authenticeert.
En precies wat didrix al aangeeft, vervang je sleutels, dat is het gote voordeel van dit soort authenticatie t.o.v. biometrische gegevens. Die kan je namelijk nooit vervangen.
Door Anoniem: Stel je voor meerdere mensen hebben toegang tot mijn computer
Dan zou ik om te beginnen overwegen die mensen een eigen user te geven, en als je data tussen die users wilt delen daar een groep voor te definiëren met een eigen directory onder /home waar iedereen via die groep lees- en schrijfrechten op heeft. en komen zo bij mij SSH keys (private en public)
Hoe kan de server nog identificeren dat de juiste persoon gebruik maakt van de SSH keys wanneer deze persoon ook mijn wachtwoord zou weten?
Niet. Maar waarom zou deze persoon ook het wachtwoord van je ssh-sleutel weten? Of heb je een ssh-agent draaien (misschien via libpam-ssh) waarin het wachtwoord al is ingevuld?Hoe kan de server nog identificeren dat de juiste persoon gebruik maakt van de SSH keys wanneer deze persoon ook mijn wachtwoord zou weten?
Als iemand zich kan identificeren bij een server op een manier die niet van jou te onderscheiden is dan kan die server dat onderscheid onmogelijk maken, servers zijn niet helderziend en er zijn ook niet onder water stiekem nog andere authenticatiemechanismen actief die slordigheden kunnen opvangen. Als je wilt dat het niet kan dan moet je het zo inrichten dat het niet kan en consequenties als wat minder gemak voor lief nemen.
Door Anoniem:
De server identificeert niet maar authenticeert.
Door Anoniem: Stel je voor meerdere mensen hebben toegang tot mijn computer en komen zo bij mij SSH keys (private en public)
Hoe kan de server nog identificeren dat de juiste persoon gebruik maakt van de SSH keys wanneer deze persoon ook mijn wachtwoord zou weten?
(Niet dat dit het geval is maar vraag dit uit intresse)
Hoe kan de server nog identificeren dat de juiste persoon gebruik maakt van de SSH keys wanneer deze persoon ook mijn wachtwoord zou weten?
(Niet dat dit het geval is maar vraag dit uit intresse)
De server identificeert niet maar authenticeert.
Exact.
De inbreker hebben we niet meer kunnen identificeren terwijl hij/zij zich wel kon authenticeren zonder dat hij/zij geauthoriseerd was.
Door Anoniem:
De server identificeert niet maar authenticeert.
En precies wat didrix al aangeeft, vervang je sleutels, dat is het gote voordeel van dit soort authenticatie t.o.v. biometrische gegevens. Die kan je namelijk nooit vervangen.
Door Anoniem: Stel je voor meerdere mensen hebben toegang tot mijn computer en komen zo bij mij SSH keys (private en public)
Hoe kan de server nog identificeren dat de juiste persoon gebruik maakt van de SSH keys wanneer deze persoon ook mijn wachtwoord zou weten?
(Niet dat dit het geval is maar vraag dit uit intresse)
Hoe kan de server nog identificeren dat de juiste persoon gebruik maakt van de SSH keys wanneer deze persoon ook mijn wachtwoord zou weten?
(Niet dat dit het geval is maar vraag dit uit intresse)
De server identificeert niet maar authenticeert.
En precies wat didrix al aangeeft, vervang je sleutels, dat is het gote voordeel van dit soort authenticatie t.o.v. biometrische gegevens. Die kan je namelijk nooit vervangen.
Het grote nadeel van SSH keys is dat je ze niet centraal kunt intrekken. Er is niet zo iets als een revocation list en een
OCSP server ofzo. Dat is natuurlijk fijn omdat je niet wilt dat de SSH toegang van allerlei externe services afhankelijk
is, maar het zou toch wel fijn zijn als die optie er was.
Er is geen andere manier om te weten waar je SSH public key in de authorized_keys staat dan hier zelf een zorgvuldige
administratie van bij te houden, zodat je weet waar je allemaal langs moet om die te verwijderen in geval van problemen.
Door Anoniem:
Natuurlijk kan de server niet weten welk stuk vlees en bloed de SSH key aanbiedt (en/of het wachtwoord) als die key bij meerdere mensen bekend is.
Duh.
Magie bestaat niet.
Magie bestaat voor een gedeelte wel. Als het een ander source IP gebruikt wordt, dan dit wel een trigger zijn.Door Anoniem: Stel je voor meerdere mensen hebben toegang tot mijn computer en komen zo bij mij SSH keys (private en public)
Hoe kan de server nog identificeren dat de juiste persoon gebruik maakt van de SSH keys wanneer deze persoon ook mijn wachtwoord zou weten?
(Niet dat dit het geval is maar vraag dit uit intresse)
Hoe kan de server nog identificeren dat de juiste persoon gebruik maakt van de SSH keys wanneer deze persoon ook mijn wachtwoord zou weten?
(Niet dat dit het geval is maar vraag dit uit intresse)
Natuurlijk kan de server niet weten welk stuk vlees en bloed de SSH key aanbiedt (en/of het wachtwoord) als die key bij meerdere mensen bekend is.
Duh.
Magie bestaat niet.
Door Anoniem: Magie bestaat voor een gedeelte wel. Als het een ander source IP gebruikt wordt, dan dit wel een trigger zijn.
Het ging om mensen die de computer (en kennelijk de user) van de vraagsteller gebruiken. Dan zal het source-IP ook hetzelfde zijn.Reageren op een source-IP is geen magie, ook niet gedeeltelijk. Het is iets wat uit te leggen en te implementeren is, er is niets magisch aan.
Door Anoniem:
Het grote nadeel van SSH keys is dat je ze niet centraal kunt intrekken. Er is niet zo iets als een revocation list en een
OCSP server ofzo. Dat is natuurlijk fijn omdat je niet wilt dat de SSH toegang van allerlei externe services afhankelijk
is, maar het zou toch wel fijn zijn als die optie er was.
Er is geen andere manier om te weten waar je SSH public key in de authorized_keys staat dan hier zelf een zorgvuldige
administratie van bij te houden, zodat je weet waar je allemaal langs moet om die te verwijderen in geval van problemen.
Door Anoniem:
De server identificeert niet maar authenticeert.
En precies wat didrix al aangeeft, vervang je sleutels, dat is het gote voordeel van dit soort authenticatie t.o.v. biometrische gegevens. Die kan je namelijk nooit vervangen.
Door Anoniem: Stel je voor meerdere mensen hebben toegang tot mijn computer en komen zo bij mij SSH keys (private en public)
Hoe kan de server nog identificeren dat de juiste persoon gebruik maakt van de SSH keys wanneer deze persoon ook mijn wachtwoord zou weten?
(Niet dat dit het geval is maar vraag dit uit intresse)
Hoe kan de server nog identificeren dat de juiste persoon gebruik maakt van de SSH keys wanneer deze persoon ook mijn wachtwoord zou weten?
(Niet dat dit het geval is maar vraag dit uit intresse)
De server identificeert niet maar authenticeert.
En precies wat didrix al aangeeft, vervang je sleutels, dat is het gote voordeel van dit soort authenticatie t.o.v. biometrische gegevens. Die kan je namelijk nooit vervangen.
Het grote nadeel van SSH keys is dat je ze niet centraal kunt intrekken. Er is niet zo iets als een revocation list en een
OCSP server ofzo. Dat is natuurlijk fijn omdat je niet wilt dat de SSH toegang van allerlei externe services afhankelijk
is, maar het zou toch wel fijn zijn als die optie er was.
Er is geen andere manier om te weten waar je SSH public key in de authorized_keys staat dan hier zelf een zorgvuldige
administratie van bij te houden, zodat je weet waar je allemaal langs moet om die te verwijderen in geval van problemen.
zoiets zou via LDAP geregeld kunnen worden denk ik, ik heb er geen ervaring mee, maar unix logins kunnen via LDAP gaan, dus ik neem aan dat er ook een mogelijkheid zal zijn om de public keys hierin op te slaan en tegen deze te authenticeren bij login,
-edit- : yup... https://code.google.com/archive/p/openssh-lpk/
Door botbot:
zoiets zou via LDAP geregeld kunnen worden denk ik, ik heb er geen ervaring mee, maar unix logins kunnen via LDAP gaan, dus ik neem aan dat er ook een mogelijkheid zal zijn om de public keys hierin op te slaan en tegen deze te authenticeren bij login,
-edit- : yup... https://code.google.com/archive/p/openssh-lpk/
zoiets zou via LDAP geregeld kunnen worden denk ik, ik heb er geen ervaring mee, maar unix logins kunnen via LDAP gaan, dus ik neem aan dat er ook een mogelijkheid zal zijn om de public keys hierin op te slaan en tegen deze te authenticeren bij login,
-edit- : yup... https://code.google.com/archive/p/openssh-lpk/
Nah, de servers die je via ssh benaderd hoevel helemaal niet aan je eigen infra te hangen en dus geen ldap o.i.d. te gebruiken.
Hoe kan de server nog identificeren dat de juiste persoon gebruik maakt van de SSH keys wanneer deze persoon ook mijn wachtwoord zou weten?
Dit is net zoiets als vragen hoe je kan voorkomen dat iemand indien je hem je voordeur sleutel geeft, je voordeur open kan maken.
Door Anoniem:
Dit is net zoiets als vragen hoe je kan voorkomen dat iemand indien je hem je voordeur sleutel geeft, je voordeur open kan maken.
Hoe kan de server nog identificeren dat de juiste persoon gebruik maakt van de SSH keys wanneer deze persoon ook mijn wachtwoord zou weten?
Dit is net zoiets als vragen hoe je kan voorkomen dat iemand indien je hem je voordeur sleutel geeft, je voordeur open kan maken.
Ja of vragen of als iemand je geld gepikt heeft, deze persoon het ook zomaar kan uitgeven.
Door Anoniem:
Dit is net zoiets als vragen hoe je kan voorkomen dat iemand indien je hem je voordeur sleutel geeft, je voordeur open kan maken.
Hoe kan de server nog identificeren dat de juiste persoon gebruik maakt van de SSH keys wanneer deze persoon ook mijn wachtwoord zou weten?
Dit is net zoiets als vragen hoe je kan voorkomen dat iemand indien je hem je voordeur sleutel geeft, je voordeur open kan maken.
Nee dat is niet helemaal vergelijkbaar! Het lijkt er meer op dat jij bij de groothandel een heleboel cylinders gekocht hebt
met hetzelfde sleutelnummer zodat je maar 1 sleutel in je zak hoeft te hebben om allerlei deuren waar je regelmatig door
heen moet kunnen open te maken, en nou weet iemand welk sleutelnummr dat is.
(in het geschetste scenario doordat je die iemand even je sleutel geleend hebt, maar dat doet er niet echt toe)
Nu is het probleem dat je aan de sleutel niet kunt zien waar je die cylinders allemaal in gezet hebt. Dus je kunt wel die
in je voordeur verwisselen, maar al die andere plekken moet je ook doen en je weet niet meer zo precies waar dat allemaal
was (omdat je daar nooit bij na hoefde te denken), en het kan zelfs zijn dat je niet overal op ieder moment weer zo
gemakkelijk kunt komen om die cylinder te verwisselen. Als je dat niet goed krijgt dan blijven er altijd plekken waar die
iemand ineens naar binnen kan, en daar kun je op afstand niets tegen doen.
Door Anoniem:
Nah, de servers die je via ssh benaderd hoevel helemaal niet aan je eigen infra te hangen en dus geen ldap o.i.d. te gebruiken.
Dat is ook het hele slechte van de SSH Key oplossingen. Er is geen centrale management standaard uit te voeren. Leuk bij een paar servers. Maar als het er meerder worden, dan zie je gewoon dat het zeer slecht schaalbaar is. Intrekken van een key met controle of het ook gedaan is, is zeer lastig en complex.Door botbot:
zoiets zou via LDAP geregeld kunnen worden denk ik, ik heb er geen ervaring mee, maar unix logins kunnen via LDAP gaan, dus ik neem aan dat er ook een mogelijkheid zal zijn om de public keys hierin op te slaan en tegen deze te authenticeren bij login,
-edit- : yup... https://code.google.com/archive/p/openssh-lpk/
zoiets zou via LDAP geregeld kunnen worden denk ik, ik heb er geen ervaring mee, maar unix logins kunnen via LDAP gaan, dus ik neem aan dat er ook een mogelijkheid zal zijn om de public keys hierin op te slaan en tegen deze te authenticeren bij login,
-edit- : yup... https://code.google.com/archive/p/openssh-lpk/
Nah, de servers die je via ssh benaderd hoevel helemaal niet aan je eigen infra te hangen en dus geen ldap o.i.d. te gebruiken.
Door Anoniem:
Door Anoniem:
Nah, de servers die je via ssh benaderd hoevel helemaal niet aan je eigen infra te hangen en dus geen ldap o.i.d. te gebruiken.
Dat is ook het hele slechte van de SSH Key oplossingen. Er is geen centrale management standaard uit te voeren. Leuk bij een paar servers. Maar als het er meerder worden, dan zie je gewoon dat het zeer slecht schaalbaar is. Intrekken van een key met controle of het ook gedaan is, is zeer lastig en complex.Door botbot:
zoiets zou via LDAP geregeld kunnen worden denk ik, ik heb er geen ervaring mee, maar unix logins kunnen via LDAP gaan, dus ik neem aan dat er ook een mogelijkheid zal zijn om de public keys hierin op te slaan en tegen deze te authenticeren bij login,
-edit- : yup... https://code.google.com/archive/p/openssh-lpk/
zoiets zou via LDAP geregeld kunnen worden denk ik, ik heb er geen ervaring mee, maar unix logins kunnen via LDAP gaan, dus ik neem aan dat er ook een mogelijkheid zal zijn om de public keys hierin op te slaan en tegen deze te authenticeren bij login,
-edit- : yup... https://code.google.com/archive/p/openssh-lpk/
Nah, de servers die je via ssh benaderd hoevel helemaal niet aan je eigen infra te hangen en dus geen ldap o.i.d. te gebruiken.
Is dat "het slechte van SSH" of is dat een toepassing van SSH die wordt ingezet zonder dat erover wordt nagedacht?
Reageren
Deze posting is gelocked. Reageren is niet meer mogelijk.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
