• Hallo liebe Userinnen und User,

    nach bereits längeren Planungen und Vorbereitungen sind wir nun von vBulletin auf Xenforo umgestiegen. Die Umstellung musste leider aufgrund der Serverprobleme der letzten Tage notgedrungen vorverlegt werden. Das neue Forum ist soweit voll funktionsfähig, allerdings sind noch nicht alle der gewohnten Funktionen vorhanden. Nach Möglichkeit werden wir sie in den nächsten Wochen nachrüsten. Dafür sollte es nun einige der Probleme lösen, die wir in den letzten Tagen, Wochen und Monaten hatten. Auch der Server ist nun potenter als bei unserem alten Hoster, wodurch wir nun langfristig den Tank mit Bytes vollgetankt haben.

    Anfangs mag die neue Boardsoftware etwas ungewohnt sein, aber man findet sich recht schnell ein. Wir wissen, dass ihr alle Gewohnheitstiere seid, aber gebt dem neuen Board eine Chance.
    Sollte etwas der neuen oder auch gewohnten Funktionen unklar sein, könnt ihr den "Wo issn da der Button zu"-Thread im Feedback nutzen. Bugs meldet ihr bitte im Bugtracker, es wird sicher welche geben die uns noch nicht aufgefallen sind. Ich werde das dann versuchen, halbwegs im Startbeitrag übersichtlich zu halten, was an Arbeit noch aussteht.

    Neu ist, dass die Boardsoftware deutlich besser für Mobiltelefone und diverse Endgeräte geeignet ist und nun auch im mobilen Style alle Funktionen verfügbar sind. Am Desktop findet ihr oben rechts sowohl den Umschalter zwischen hellem und dunklem Style. Am Handy ist der Hell-/Dunkelschalter am Ende der Seite. Damit sollte zukünftig jeder sein Board so konfigurieren können, wie es ihm am liebsten ist.


    Die restlichen Funktionen sollten eigentlich soweit wie gewohnt funktionieren. Einfach mal ein wenig damit spielen oder bei Unklarheiten im Thread nachfragen. Viel Spaß im ngb 2.0.

SSH key login: Vor- und Nachteile?

Pulliuser

100% Baumwolle

Registriert
4 Nov. 2014
Beiträge
74
Hallo,

welche Vor- und Nachteile fallen euch ein bei der Nutzung eines Key Logins gegenüber eines klassischen Passwort Logins?

Habe spontan im Netz und auch hier im Forum leider nicht viel dazu gefunden. Es heißt Key Login sei sicherer wenn der Server gehackt wird bei dem mein public key hinterlegt ist, weil man mit diesem nicht wirklich etwas anfangen kann? Klingt an sich sehr gut.

Allerdings stelle ich mir vor das ich für jedes Gerät, von welchem aus ich mich einloggen möchte, entweder einen eigenen Key erstellen muss (ist wohl empfohlen?). Dann frage ich mich aber wie ich all diese Keys verwalten will, sicherstelle das diese nicht abhanden kommen und was mache ich wenn ich mich von einem fremden Rechner einloggen will?

Oder ich erstelle nur einen privaten Key und kopiere den auf alle Geräte zum einloggen, was ja aber auch total unsicher ist wenn dieser in fremde Hände gelangt.

Dem gegenüber sehe ich den Login via kompliziertem Passwort mit Passwort Manager einfacher zu handhaben. Auf fremden Geräten kann ich das PW zumindest von meinem Handy abtippen (auf dem ebenfalls der PW Manager installiert ist). Und sollte ein Server gehackt werden ändere ich das PW und gut. Einziger Nachteil wäre das ein PW evtl. "erraten" werden kann. Dazu gleich die Frage welche Passwortlänge denn absehbar als zukunftssicher betrachtet werden kann?
 

braegler

Aktiver NGBler

Registriert
14 Juli 2013
Beiträge
896
Wenn Du für jedes Gerät einen Key erstellst, dann bleibt dieser auch auf diesem Gerät. Du trägst nur den Pubkey in den autorized_keys der Systeme ein, auf der PrivKey Zugriff haben soll.
Die Keys sicherst Du Sinnvollerweise mit einem Passwort. Da dieses ja nicht versendet wird, kannst Du da auch relativ gefahrlos für die jeweiligen Keys die selben PWs verwenden.
Kommt ein Gerät abhanden muss der Angreifer erst noch das PW bruteforcen*. Die Komplexität des PWs bestimmt den Zeitraum den Du hast, um den pubkey des potentiell kompromittieren PrivateKeys aus den authorized_keys zu entfernen.

* Es sei denn er hat einen Keylogger. Dann kann er Dein PW mitlesen, aber braucht im Gegensatz zum PW-Login immer noch Deinen PrivateKey.
 

theSplit

1998
Veteran Barkeeper

Registriert
3 Aug. 2014
Beiträge
28.560
Ich unterstelle dir mal, du hast nicht oder nicht richtig gesucht - beides in Kombination ist auch wahrscheinlich. Es gibt Tonnen an Informationen dazu... ;)

Einige deiner Fragen werden hier beantwortet, zumindest was den Umgang und auch die Erstellung und Nutzung angeht (Linux): https://wiki.archlinux.org/index.php/SSH_keys

Da wird auch zum Beispiel ein bzw. zwei Werkzeuge genannt, mit dem sich SSH Keys verwalten lassen. Unter anderem auch Keepass2 mit Plugin.

Sagen wir so, wenn die Mindestlänge für eine Public Key zwischen 1024 und 16384 Bits besteht, was glaubst du, wie lang soll dein handeingegebes Passwort sein um damit Schritt zu halten?

Minimum key size is 1024 bits, default is 2048 (see ssh-keygen(1)) and maximum is 16384

Also 128 Zeichen Minimum, bis zu 2048 Zeichen!

Und das gleich dazu, weil es hier ins Thema passt:

Background

SSH keys serve as a means of identifying yourself to an SSH server using public-key cryptography and challenge-response authentication. One immediate advantage this method has over traditional password authentication is that you can be authenticated by the server without ever having to send your password over the network. Anyone eavesdropping on your connection will not be able to intercept and crack your password because it is never actually transmitted. Additionally, using SSH keys for authentication virtually eliminates the risk posed by brute-force password attacks by drastically reducing the chances of the attacker correctly guessing the proper credentials.

As well as offering additional security, SSH key authentication can be more convenient than the more traditional password authentication. When used with a program known as an SSH agent, SSH keys can allow you to connect to a server, or multiple servers, without having to remember or enter your password for each system.

SSH keys are not without their drawbacks and may not be appropriate for all environments, but in many circumstances they can offer some strong advantages. A general understanding of how SSH keys work will help you decide how and when to use them to meet your needs.

Quelle

Wenn du jetzt noch nen Login mit Username hast, "der auch noch erraten werden muß" (und das ist nicht "root" oder "default user name of hardware") - dann sieht es sehr schwer aus das erfolgreich zu erraten, eher, wenn du Login attempts logst, würdest du mitbekommen, wenn du die Logs überprüfst, das es feherhafte Verbindungen gab.

Außerdem ist dein Schlüsselbund auch noch mit einem Passwort gesichert, sollte es zumindest, das heißt, ein Public Key ohne Secret Key ist wertlos, warum, das erklärt auch Wikipedia:
https://de.wikipedia.org/wiki/Asymmetrisches_Kryptosystem#Sicherheit

Note: Daher, selbst wenn jemand Zugriff auf deine Remote-Maschine bekommt, physisch, ist nur der Publik Key hinterlegt, aber dein Secret Key bleibt geheim.

Und es gibt nur die Kombination "Private/Secret" + "Public" key. - Nicht eines ohne das andere kann funktionieren

Und auch das hier mal zu Gemüte führen bitte:
https://de.wikipedia.org/wiki/Asymmetrisches_Kryptosystem#Formale_Definition
 
Zuletzt bearbeitet:

Shodan

runs on biochips

Registriert
14 Juli 2013
Beiträge
661
Ort
Citadel Station
was mache ich wenn ich mich von einem fremden Rechner einloggen will?
Die einzige mir bekannte Möglichkeit dich von einem fremden (aka "untrusted") System aus zu authentifizieren ohne dabei zu riskieren, dass dein Zugang gestohlen wird ist "one time password authentication": mögliche Implementation ist z.B. eine Liste mit möglichen Passwörtern auf dem Server zu hinterlegen und wenn du dich mit einem davon anmeldest, wird es aus der Liste gestrichen und somit nutzlos. Mitschneiden bringt also nichts.

Allerdings hast du mit "fremden Systemen" noch ganz andere Probleme: nicht nur dein Key fehlt auf dem System, der Server steht nicht in der known_hosts, bzw du kannst den Einträgen dort nicht trauen. Um Man-in-the-Middle Attacken zu vermeiden musst du den Fingerprint des Servers prüfen.

Und selbst dann kann ein kompromitiertes System dich noch täuschen, denn der installierten SSH Client kann z.B. die geöffnete Verbindung nutzen um Befehle auszuführen und dir nichts davon zu erzählen. (Erzähl mir jetzt nicht du meinst mit fremd "schneided Passwörter mit, sabotiert aber keine Software" ).
Reicht es deinen eigenen SSH Client mitzubringen? Eventuell, denn wenn der Besitzer dich den nicht installieren lässt, steigt die Vertrauenswürdigkeit des Systems :D
 

sia

gesperrt

Registriert
26 März 2015
Beiträge
5.931
Ort
FFM (NSFW)
Einfach nicht von einem fremden Rechner einloggen.

Oder von einer Live-Disk booten, was das Problem der Hardware Keylogger nicht umgeht.
 

Metal_Warrior

Defender of Freedom
Teammitglied

Registriert
10 Aug. 2013
Beiträge
6.830
Ort
/dev/mapper/home
Ich weiß, die anderen haben eigentlich fast alles schon gesagt (allerdings ziemlich durcheinander); ich fass es dir nochmal auf deine Fragen konkret zusammen.

welche Vor- und Nachteile fallen euch ein bei der Nutzung eines Key Logins gegenüber eines klassischen Passwort Logins?
Vorteile:
  • Dein Passwort des Servers und dein Login-"Passwort" sind unterschiedlich
  • Richtig konfiguriert musst du dich zum Verbinden um nix mehr kümmern (keine Passwortabfrage etc.)
  • Kein Bot im Netz, den ich bislang gesehen habe, bruteforced PubKeyAuthentication - die geben alle direkt auf
  • Dein Passwort wird nie übers Netz geschickt, d. h. auch ein Man in the Middle sieht keine für ihn brauchbaren Informationen

Nachteile:
  • Höherer Einrichtungsaufwand (2-10 Minuten, je nach System)
  • PrivateKey MUSS gesichert werden (d. h. verschlüsselt)
  • Funktioniert richtig gut nur auf Unixoiden, Windows hinkt da ein wenig hinterher (kann sich mittlerweile aber geändert haben, bin da nicht up to date)

Allerdings stelle ich mir vor das ich für jedes Gerät, von welchem aus ich mich einloggen möchte, entweder einen eigenen Key erstellen muss (ist wohl empfohlen?).
Nein, musst du nicht. Du kannst mit einem Key 25000 Server verwalten, wichtig ist nur, dass dein PrivateKey sicher bleibt. Den PublicKey kannst du auch offen ins Internet schreiben, und das ist der einzige Key, den der Server jemals sieht (weil du ihn auf dem Server in die Datei ~/.ssh/authorized_keys schreibst).

Dann frage ich mich aber wie ich all diese Keys verwalten will, sicherstelle das diese nicht abhanden kommen und was mache ich wenn ich mich von einem fremden Rechner einloggen will?
Die Verwaltung deiner Logins übernimmt SSH selbst. Es sucht sich den Key am Standardort, und einigt sich mit dem Server auf dessen Nutzung. Der Key liegt standardmäßig in ~/.ssh/id_[Keyalgorithmus]. Dieser muss unter allen Umständen gesichert werden (Passwort-gesichert, verschlüsseltes Laufwerk etc.). Kommt er dir abhanden, selbst wenn er verschlüsselt ist, gilt er als verbrannt und muss ersetzt werden. Daneben gibt es auch noch die ~/.ssh/id_[Keyalgorithmus].pub. Das ist dein PublicKey und darf jedem in die Hand gedrückt werden, der dir über den Weg läuft. Er wird auf dem Server abgelegt (siehe oben).
Fremder Rechner: NO-GO. PrivateKey auf USB-Stick: Klares NEIN (es sei denn, der ist auch LUKS-encrypted). Den PrivateKey dürfen nur Maschinen sehen, die vertrauenswürdig sind. Hast du mehrere Maschinen, wird für jede ein eigenes KeyPair erstellt - wird eine kompromittiert, wird einfach nur deren PrivateKey als verbrannt angesehen und der zugehörige PublicKey aus der authorized_keys gelöscht. Es gibt afaik kein Limit an PublicKeys, die in der authorized_keys stehen dürfen - oder zumindest keines, das dir bei sinnvollem Umgang jemals in die Quere kommt.

Für die Leute, die es gern hübsch einfach haben wollen, bietet sich eine ~/.ssh/config an:
[src=bash]Host MeinAlias
HostName server.example.com
Port 22
User hanswurst
IdentityFile ~/.ssh/id_[Keyalgorithmus][/src]
Danach ist es für dich ein
[src=bash]ssh MeinAlias[/src]
und du bist eingeloggt.

Übrigens: Handy würde ich als unsicheres Gerät einstufen, es sei denn, du hast es gerootet. Wenn du dich aber wirklich über Handy einloggen willst, kann z. B. ConnectBot auch PubKeyAuthentication. Lass dir von der App nen KeyPair erstellen (oder gib ihr ein extra für sie erstelltes) und kopier den PubKey in die ~/.ssh/authorized_keys auf dem Server. Schon funktioniert der Login.
 

maggot

[gEB] Trauergruppe

Registriert
14 Okt. 2013
Beiträge
40
Ort
hinterm Mond
Ich möchte noch ergänzen, das man in Keepass (Passwortmanager) nicht nur Passwörter sondern auch Attachments, also hier z.B. die Privatekeys speichern kann. Dann hat man gleich noch ein Backup.
 

sia

gesperrt

Registriert
26 März 2015
Beiträge
5.931
Ort
FFM (NSFW)
… und dass KeePassXC seit Version 2.3 einen SSH-Agent mitbringt. Den nutze ich rege.

Ich empfehle die Installation im Linux-Paketmanager oder über chocolatey in Windows.
 
Zuletzt bearbeitet:

maggot

[gEB] Trauergruppe

Registriert
14 Okt. 2013
Beiträge
40
Ort
hinterm Mond
Oh, den XC kenne ich ja noch gar nicht, den schaue ich mir direkt mal an.
Nutze KeePass2...
 

BurnerR

Bot #0384479

Registriert
20 Juli 2013
Beiträge
5.504
Kurzum:
Mögliche Nachteile der ausschließlichen Benutzung von keyfiles basieren darauf, dass man anderswo bad practices verwendet (einloggen auf unsicheren Geräten, keine Backups, keine Verschlüsselten Partitionen/Container u.ä.)


BTW
Was ich ja immer seltsam/kurios/komisch finde
Die Benennung der keyfiles bei Erstellung mit Stanndardparemtern.
"id_rsa" und "id_rsa.pub" führt, dazu, dass wenn man in der Shell (z.B. bash) autocompletion verwendet er immer erst zum private key springt..
was ja, wenn man gerade zu wenig kaffee hatte durchaus mal in scherzen wie "scp id_rsa someserver" enden kann :D.
 
Zuletzt bearbeitet:

Metal_Warrior

Defender of Freedom
Teammitglied

Registriert
10 Aug. 2013
Beiträge
6.830
Ort
/dev/mapper/home
@BurnerR: Das ist dann ein typischer Fall von "erst denken, dann Enter drücken". Und führt dazu, dass man den letzten Befehl nochmal ausführen darf (nämlich ssh-keygen).

Lernen durch Schmerz ;)
 

BurnerR

Bot #0384479

Registriert
20 Juli 2013
Beiträge
5.504
Wenn der pubkey schon an mehreren Stellen verwendet wird ist es deutlich mehr Aufwand.
Sicher hast du recht 'erst denken dann Enter drücken', aber das ist ja beim Thema "Arbeitssicherheit" nicht der Maßstab, man legt auch keine Bretter mit Nägeln auf dem Boden einer Baustelle ab, weil jeder schließlich sowieso gucken sollte, wo er hintritt.
 

Metal_Warrior

Defender of Freedom
Teammitglied

Registriert
10 Aug. 2013
Beiträge
6.830
Ort
/dev/mapper/home
@BurnerR: Ganz ehrlich:

Würdest du einem Admin root-Rechte geben, der schon bei der Systemeinrichtung falsche Dateien kopiert? Also ich nicht. Am Ende löscht er statt "/srv/Daten/Büro/Buchhaltung/alter_Scheiß" "/srv/Daten"... Scheiß Autovervollständigung ;)
 

sia

gesperrt

Registriert
26 März 2015
Beiträge
5.931
Ort
FFM (NSFW)
Geht hier nicht um Root.

Aber aus dem Grund nutze ich i.d.R. ssh-copy-id.
 
Zuletzt bearbeitet:

Metal_Warrior

Defender of Freedom
Teammitglied

Registriert
10 Aug. 2013
Beiträge
6.830
Ort
/dev/mapper/home
@phre4k: Unabhängig um welchen User es geht - aber wer auf zig Server SSH-Zugriff hat, ist meist auch in der sudoers drin ;)

Also ich gehör irgendwie zur alten Schule: Ich kontrollier die Autovervollständigung, bevor ich Enter drücke ;)
 

Pulliuser

100% Baumwolle

Registriert
4 Nov. 2014
Beiträge
74
  • Thread Starter Thread Starter
  • #17
Vielen Dank für eure Antworten! Dachte mir schon das mir bei dem Thema hier wieder die Kompetenzen um die Ohren fliegen ;D

Vielen Dank auch besonders für die Zusammenfassungen.

Dann sehe ich es eindeutig als Nachteil das das Einloggen an fremden Rechnern zu unsicher und unpraktikabel ist. Wobei das dort, wo Login via Key überhaupt möglich ist, vlt noch nicht von fremden Rechnern relevant ist. Wobei ich vlt auch von anderen Stellen mal auf den uberspace Server möchte/muss.

Bleibt für mich ein abtippbares PW vlt nicht zwingend sicherer aber auf jeden Fall flexibler. Zudem bin ich einer dieser Windows user ;) Ist mal wieder der ewige Trade Off zwischen Flexibilität und Sicherheit den jeder für sich entscheiden muss. Aber dank eurer Infos kann ich eine fundiertere Entscheidung treffen.

Btw, da es hier erwähnt wurde, auf dem Android ohne root nutze ich Keepass2Android. Haltet ihr das auch für unsicher und wenn ja, warum?
 

BurnerR

Bot #0384479

Registriert
20 Juli 2013
Beiträge
5.504
Aus realer Neugierde:
Was sind das für andere Stellen, wo du dich einloggen möchtest oder musst?
Ich kenne bei mir nur drei Endpunkte: Büro, Zuhause und Laptop/Unterwegs und kann mir nicht so recht vorstellen, wann man sich außerhalb von Laptop anmelden will.
ImHo bietet sich an einen speziellen Account für 'Unterwegs/Fremdrechner' einzurichten, wo du eine E-Mail kriegst, wenn sich jmd mit diesem Account einloggt.
 

sia

gesperrt

Registriert
26 März 2015
Beiträge
5.931
Ort
FFM (NSFW)
Wobei ich vlt auch von anderen Stellen mal auf den uberspace Server möchte/muss.
Dann richte dir Termux auf dem Android-Handy ein, lade dort deinen Key und verbinde dich auf das Handy mit AirDroid o.ä.

So mache ich das :D

Bleibt für mich ein abtippbares PW vlt nicht zwingend sicherer aber auf jeden Fall flexibler.
Nein, nein, nein nein nein. Lieber 2-Faktor-Authentifizierung, falls mit Passwort eingeloggt wird und beim Key halt nicht.

Btw, da es hier erwähnt wurde, auf dem Android ohne root nutze ich Keepass2Android. Haltet ihr das auch für unsicher und wenn ja, warum?
Ist okay, ich selbst nutze KeePassDroid, was vermutlich ähnlich gut/schlecht ist. Praktisch ist das Entsperren per Fingerabdruck.
 

Metal_Warrior

Defender of Freedom
Teammitglied

Registriert
10 Aug. 2013
Beiträge
6.830
Ort
/dev/mapper/home
Wobei ich vlt auch von anderen Stellen mal auf den uberspace Server möchte/muss.
Von einer fremden Maschine? Nö. Nö, nö, nö. Weder mit Key, noch mit Passwort (was noch schlimmer ist, denn dann hat der Fremde direkt die Zugangsdaten). Du hast ein Notebook - nimm das mit. Ansonsten Handy.

Praktisch ist das Entsperren per Fingerabdruck.
Das ist grad nen herber Schock. Von dir hätte ich wirklich mehr Umsicht mit Biometrie erwartet. Grade von dir... :eek:
 
Oben