Ist ein SSH-Login per RSA-key sicher?

[tubbi]

Hallo Zusammen,

ich habe offentsichtlich ein Sicherheitsproblem:

ssh -i .ssh/user1_rsa.key user1@sshserver funktioniert super!

ssh -i .ssh/user1_rsa.key user2@sshserver funktioniert auch, und ich bin tatsächlich im user2 Home-Verzeichnis gelandet!

Warum ist das möglich und wie kann ich das verhindern?

[wanne]

Öffentliche Schlüssel sind so gedacht, dass man die veröffentlichen kann. (Auch wenn es bei SSH auch gründe dagegen gibt.) Jeder der dir vertraut kann deinen öffentlichen Schlüssel kopieren und dir damit Zugang zum System geben. Wenn also user1 und user2 deinen Key kopiert haben kannst du auf beide Systeme. War ja deren freie Entscheidung das zu tun. (Umgekehrt nicht.) Der riesige Vorteil von RSA das ein Schlüssel Zugang zu vielen verschiedenen Dingen geben kann ohne die Sicherheit zu gefährden. Deswegen wird es an so vielen Stellen verwendet.

[uname]

Ein sehr großer Vorteil gegenüber Passwörtern egal wie komplex ist, dass die geheime Information nicht an einen Zielserver übertragen werden muss. Du kannst dich ja mal aus Spaß mit strace an den SSH-Server-Prozess deines Servers dranhängen und das beliebig komplexe Passwort im Klartext mitlesen. Bei einer Anmeldung mit einem SSH-Key wirst du den geheimen Schlüssel auf dem Server mit strace nicht erfahren, da er nie den Server erreicht es sei denn er wurde dort erzeugt bzw. muss dort verwendet werden.

[mat6937]

... wie kann ich das verhindern?

Das kannst Du verhindern, in dem Du in der config des ssh-Servers (sshd) einträgst/festlegst, dass der user2 such nicht anmelden/einloggen soll/darf.

[tubbi]

@wanne @uname
Besten dank für die Hinweise. Ist schon auf meiner Todo-Liste.

@mat6937
Danke für deine Antwort. Aber ... ich will nicht verhindern, dass sich beide user anmelden können. Ich will lediglich NICHT, dass sich user1 mit seinem eigenen Schlüssel als user2 anmelden kann: ssh -i .ssh/user1_rsa.key user2@sshserver

[uname]

Ich will lediglich NICHT, dass sich user1 mit seinem eigenen Schlüssel als user2 anmelden kann

Das könnte er nur, wenn er seinen öffentlichen Schlüssel im Speicherbereich von user2 also /home/user2/.ssh/authorized_keys ablegen könnte. Hat er diese Möglichkeit? Wenn ja, wie und warum?

[wanne]

Danke für deine Antwort. Aber ... ich will nicht verhindern, dass sich beide user anmelden können. Ich will lediglich NICHT, dass sich user1 mit seinem eigenen Schlüssel als user2 anmelden kann: ssh -i .ssh/user1_rsa.key user2@sshserver

Musst du den public-Key halt wieder löschen:
Also in die ~/.ssh/authorized_keys gehen und die passende Zeile für user1 löschen.

[tubbi]

@ wanne uname matt6937

Ich habe dank eurer Mithilfe die Lösung bzw. die Ursache gefunden.
Zur besseren Übersicht hier nochmal das Ausgangsszenario:

ssh -i .ssh/user1_rsa.key user1@sshserver <--- funktioniert super!
ssh -i .ssh/user1_rsa.key user2@sshserver <--- user1 ist als user2 im Homeverzeichnis von user2 eingeloggt.

Der Knackpunkt:
user2 ist der bei der vServer-Installation angelegte administrative User. Lösche ich also von diesem, also von user2, die .ssh/authorized_keys, dann wird user1 der Zugang als user2 verwehrt. Lege ich aber wieder eine neue authorized_keys für user2 an und fülle diese NUR mit dem user2_rsa.pub, so wie es sein soll, ohne den RSA-Pub von user1, dann ist das Ausgangsszenario wieder gültig!

LÖSUNG:
Das Home-Verzeichnis von user2 hatte bei der vServer-Installation den Besitzer "user2" und die Gruppe "users" bekommen. Die bisher fehlende Gruppe "user2" habe ich nun erstellt und beim user2 Home-Verzeichnis habe via "chgrp user2 /home/user2" geändert.

Schlussszenario:
ssh -i .ssh/user1_rsa.key user2@sshserver <--- user1 kann sich NICHT als user2 in das Homeverzeichnis von user2 einloggen.

Nochmals vielen Dank an alle für die gelieferten "Zaunphähle"!
Wie setze ich meine Fragen, bzw. den gesamten Beitrag auf "gelöst"?

[uname]

Wirklich nachvollziehen kann ich das nicht. Nur so, dass der Benutzer user1 unrechtmäßig den Key nach /home/user2/.ssh/authorized_keys kopiert hat. Trotz evtl. Berechtigung sollte das ein user1 normalerweise trotzdem nicht tun, da die Funktionalität standardmäßig nicht zu erwarten ist. Somit wohl Anwenderfehler und da die Berechtigung falsch war hat es funktioniert.