Frage zu publik-keys

3

3df

Registered User
Hallo zusammen,

ich nutze auf meinem Server publik-keys, dass funktioniert auch bisher alles. Jedoch wenn ich auf einem anderen Rechner bin, auf diesem die Keys nicht liegen, kann ich mich trotzdem über SSH als root und mit dem root Passwort anmelden, ist das normal? oder kann man das deaktivieren, so das man sich nur von PCs aus einloggen kann, auf dem die Keys liegen?


Danke
 
Hallo,

wenn du ausschließlich RSA/DSA Keys verwendest setz einfach in deiner sshd.conf

Code: 
PasswordAuthentication No

Was ich dir nur empfehlen kann ist ein neuen User anzulegen ohne Root rechte. Mit diesem meldest du dich am System an via Key und wechselst dann in der Konsole zum Root (su/sudo).

Ist das geschehen so solltest du aufjedenfall den Root Login verbieten mit

Code: 
PermitRootLogin no
AllowUsers DEINNEUERBENUTZER

So bist du aufjedenfall "sicherer" unterwegs.

Grüße

Ps. Sollte deine Root Kombination wirklich root/root lauten, solltest du diese schleunigst ändern!
 
Ich hab bei mir überall PermitRootLogin without-password, da kannst dich als root einloggen, aber nur mit Key. Dann könntest Du noch einen User machen, welcher sich einloggen kann und mit su/sudo auf root wechseln kann.

Dass jemand meinen 2048bit-Key vom root bruteforced, ist doch schon sehr unwarscheinlich.
 
MOD EDIT: Fullquote enfernt.

Um den User ohne Root Login via Key anzumelden, muss ich an meinen Key der auf dem Rechner oder Server liegt nicht verändern, oder? Wenn ich dann zum Root mit su wechsle, muss ich dann das Root Passwort eingeben?

Was meinst Du denn hiermit? "Sollte deine Root Kombination wirklich root/root lauten, solltest du diese schleunigst ändern!"
 
Last edited by a moderator:
Die Frage ob man den Rootlogin unterbinden sollte oder nicht ist bei einem Key eher akademisch, da man den nicht einfach mal erraten kann, zumindest nicht bei ausreichender Schlüssellänge.

Bei Passwörtern ist die Grundüberlegung, dass der Angreifer nicht nur das Passwort per Bruteforce erraten müsste, sondern auf diese Weise eben auch noch den Benutzernamen, was zusätzliche Komplexität bringt.

Bei einem Key ist das eben - aufgrund der Länge - absolut egal und wenn er mal in die falschen Hände gekommen ist brennt die Bude sowieso schon lichterloh.

Ich persönlich handhabe das so: Rootlogin erlaubt, Port geändert (was bei einem Key eigentlich auch egal wäre aber das Hintergrundrauschen reduziert) und Auth nur per Key.

Der Key muss im richtigen Verzeichnis des Users liegen. Es nutzt also nichts, wenn Root einen Key hat, Du aber den User "xyz" anmelden musst. Normalerweise ist er im Verzeichnis ".ssh" im /home Verzeichnis des Nutzers hinterlegt.
 
Last edited by a moderator:
Die Frage ob man den Rootlogin unterbinden sollte oder nicht ist bei einem Key eher akademisch, da man den nicht einfach mal erraten kann, zumindest nicht bei ausreichender Schlüssellänge.
Click to expand...
Die Frage ist in allen Fällen akademisch. Ausser bei idiotisch gewählten Passwörter ist das Risiko dass der Server über das Erraten von Zugangsdaten kompromittiert wird sehr vernachlässigbar. In generell _ALLEN_ Fällen erfolgt der Einbruch über Software-Exploits oder, zunehmend, dem Diebstahl von SSH-Zugagsdaten auf dem Rechner des Admin.
Gegen einen solchen Diebstahl hilft, sobald der Trojaner/Keylogger eingenistet ist, keine noch so lange Keyfile sondern allerhöchstens Multi-factor Authentisierung via bspw Google Authenticator.

Ich habe in anderen Threads schon mehrmals dargestellt dass Keyfiles technisch gefährlicher sind da ein kurzzeitiger Zugriff auf die Daten des Rechners ausreicht um die Datei zu entweden und diese dann ohne Logdateien zu triggern auf einem Bruteforce-System des Angreifers geknackt werden könnte sofern er denn daran Interesse hat. Bei einem durchschnittlichen Kostenpunkt von 0.003$ je Amazon EC2 Instanz oder 0.65$ je CUDA-Instanz ist der Rechenaufwand schnell relativiert.
 
d4f said:
Gegen einen solchen Diebstahl hilft, sobald der Trojaner/Keylogger eingenistet ist, keine noch so lange Keyfile sondern allerhöchstens Multi-factor Authentisierung via bspw Google Authenticator.
Click to expand...
Ich habe meinen Key auf einer Smartcard liegen, die ich erst per PIN am Cardreader entsperren muss - den klaut mir auch keiner ;)

Bei Keys kann man Root eigentlich bedenkenlos die Anmeldung gestatten, mit dem Abschalten der Passwortauthentifizierung kann man sich aber auch ganz gepflegt in den Fuß schießen, wenn der Schlüssel mal verschwunden ist.
Es macht dann ggf. Sinn (wenn man ohnehin mehrere Client-Geräte hat) für jedes Gerät einen eigenen Schlüssel zu erzeugen.
Hat natürlich auch den Vorteil, dass bei Kompromittierung eines Systems nur der eine Schlüssel revoked resp. aus der authorized_keys-Datei entfernt werden muss.
 
Ich habe meinen Key auf einer Smartcard liegen, die ich erst per PIN am Cardreader entsperren muss - den klaut mir auch keiner
Click to expand...
Da wären wir dann wieder beim Thema Multifactor Authentisierung. Wo und wie diese abläuft kann sich je nach verwendeter Technik stark ändern aber unter dem Strich bestätigen mehrere unabhängige und bestenfalls nicht direkt verbundene Systeme die Integrität und Authentizität einer Transaktion sowie die Identität der Teilnehmer.
Wenn man nicht unbedingt die entsprechende Hardware hat, kaufen und mitschleppen will gibt es die oben erwähnte Alternative über server-seitiges Multifaktor was aber eigene Nachteile hat (generell haben automatisierte Tools damit ihr Problem)
 
d4f said:
Ich habe in anderen Threads schon mehrmals dargestellt dass Keyfiles technisch gefährlicher sind da ein kurzzeitiger Zugriff auf die Daten des Rechners ausreicht um die Datei zu entweden und diese dann ohne Logdateien zu triggern auf einem Bruteforce-System des Angreifers geknackt werden könnte sofern er denn daran Interesse hat. Bei einem durchschnittlichen Kostenpunkt von 0.003$ je Amazon EC2 Instanz oder 0.65$ je CUDA-Instanz ist der Rechenaufwand schnell relativiert.
Click to expand...
Wie lange mag es damit wohl dauern, meine Passphrase zu knacken?
 
Gut, d4f argumentiert wohl so, dass die Passphrase nicht so wahrscheinlich entwedet wird. Das sehe ich persönlich allerdings anders, wenn der Angreifer eh schon Zugriff auf den Rechner hat ist JEDE Maßnahme (bis auf two factor authentication) sinnlos, weil der Trojaner dann auch eine Weile dort bleiben und somit alle Passwörter mitloggen kann.

Es dauert ggfls. etwas länger, bis ich mich dazu durchringen kann, dass ich mich genau auf der gewünschten Seite/dem gewünschten Server mit meinem Passwort einlogge. Bis dahin ist der Angreifer mit dem Key wohl schon länger stiften gegangen, weil der ja brav auf der Platte liegt.

Aber stimmt schon, multi factor authentication ist wohl die beste Lösung, auch auf lange Sicht.
 
Last edited by a moderator:
Wie kann man jetzt eine multi factor authentication am einfachsten realisieren?

Ich hab es bis jetzt so gelöst:

root login nur mit Zertifikat und zusätzlichen Benutzer mit Passwort und su falls ich mal an einem anderen Rechner bin.
 
wenn der Angreifer eh schon Zugriff auf den Rechner hat ist JEDE Maßnahme (bis auf two factor authentication) sinnlos
Click to expand...
Hängt davon ab wie lange und wie der Angreifer Zugang hat. Wenn der Laptop mit (hoffentlich) eingeschränktem Benutzer offen da steht hat der Angreifer nicht viele Möglichkeiten einen Trojaner ein zu spielen, wohl aber Dateien zu klauen. Generell ist physikalischer Diebstahl aber eh die seltenste Methode bei 0815-Server...

Wie kann man jetzt eine multi factor authentication am einfachsten realisieren?
Click to expand...
Oben hatte ich Google Authenticator erwähnt. Es gibt eine gepatchte Version welche gewisse IP's (bspw den Backupserver) whitelisten kann damit automatisierte Tools weiterhin funktionieren.
=> https://code.google.com/r/kazimsarikaya-google-authenticatior-withwhitelist/
Hier gibt es eine Anleitung zum Installieren:
http://www.linux.org/threads/google-authenticator-for-ssh.4590/

Allerdings muss ich ehrlich sagen dass es auf Dauer nervig ist wenn man oft einloggen muss. Es gibt noch DuoSecurity, preislich bewegen die sich bei vielen Accounts jedoch jenseits Gut und Böse.
 
d4f said:
Allerdings muss ich ehrlich sagen dass es auf Dauer nervig ist wenn man oft einloggen muss.
Click to expand...
Man gewöhnt sich dran. Bei 10-50 Logins pro Tag komm ich mit meinem RSA SecurID Token noch ganz gut mit.
Nervig ist da eher viel mehr, wenn man bei komplexeren Ausfällen schlagartig möglichst schnell viele Logins auf unterschiedlichen Systemen braucht. Dann werden die TOTP schon manchmal sehr zur Qual, wenn man jedes Mal auf den nächsten Token warten muss. :)
 
Ich habe jetzt den Eintrag

Code: 
AllowUsers DEINNEUERBENUTZER

vorgenommen, jetzt kann ich mich zwar mit dem Benutzer anmelden, allerdings wenn ich "su" eingebe, dann ist Schluss. Komme nicht weiter, es wird zwar dann nach einem Passwort gefragt, gebe ich das aber ein passiert nichts.

Auf dem Server im ".ssh" Ordner von "DEINNEUERBENUTZER" liegt die Datei "authorized_keys" und auf meinem PC liegen die Dateien "id_rsa" und "id_rsa.pub" im Ordner "/Users/NAME/.ssh/" (Mac OS X). Melde ich mich per Terminal mit "DEINNEUERBENUTZER" über SSH an, dann bin ich sofort ohne Passwort Eingabe über "DEINNEUERBENUTZER" eingeloggt.
 
Last edited by a moderator:
Ich habe jetzt noch mal alles neu gemacht. Meine Config sieht jetzt so aus:

Code: 
# Authentication:
PermitRootLogin no
AllowUsers BENUTZER

RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile      %h/.ssh/authorized_keys

Code: 
# Change to no to disable tunnelled clear text passwords
PasswordAuthentication no

Das sollte jetzt so korrekt sein, oder?

Per SSH Melde ich mich erst mit dem BENUTZER per Keys an, dann zum root per "su" dann muss ich jedoch das root Passwort eingeben, ist das so richtig?

Danke euch
 
Last edited by a moderator:
Das wenn ich zu "su" wechsel, ich dann auch Automatisch Angemeldet werde geht nicht irgendwie?
 
Verstehe die Frage nicht. Wenn du an dem Punkt "su" bist, solltest du eigentlich schon angemeldet sein, oder suchst du jetzt nach einem Weg ohne das Rootpw eingeben zu müssen?
 
You must log in or register to reply here.
Back
Top