SSH - Fehler beim Verbindungsaufbau

[JeffRoc]

habe folgende Fehlermeldung, wenn ich auf meinen Server connecten will:

bash: ssh 192.168.0.1 -l root

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
xx:xx:23:41:4d:99:e7:0a:69:xx:09:xx:cd:7e:xx:6e.
Please contact your system administrator.
Add correct host key in /home/oliver/.ssh/known_hosts to get rid of this message.
Offending key in /home/oliver/.ssh/known_hosts:1
RSA host key for 192.168.0.1 has changed and you have requested strict checking.
Host key verification failed.

kann ich mit root prinzipiell nicht connecten? kenne mich mit SSH nicht aus

Danke für jede Hilfe
jR

[bluesky666]

lösche mal die Datei /home/oliver/.ssh/known_hosts
danach sollte es wieder gehen

[JeffRoc]

werde diese später dann mal löschen..
ist diese Datei denn nicht relevant für das System (so eine Art LMHost)??
soll ich diese auf dem Server oder auf dem Client löschen, denke mal auf dem Client, aber sicher ist sicher?

kann ich eigentlich ohne Probleme per -l root connecten, oder gibt es dafür bei default eine Sperre??

Danke für die Hilfe

[gaansch]

In dieser Datei stehen die HostKeys von den Systemen, zu denen du dich per SSH connected hast. Die Meldung, die du bekommen hast, sagt aus, dass sich der Hostkey eines Systemes geändert hat. Beispielsweise durch eine Neuinstallation. Wenn du die Datei löschst, kann nichts passieren.

[L00NIX]

In dieser Datei stehen die HostKeys von den Systemen, zu denen du dich per SSH connected hast. Die Meldung, die du bekommen hast, sagt aus, dass sich der Hostkey eines Systemes geändert hat. Beispielsweise durch eine Neuinstallation. Wenn du die Datei löschst, kann nichts passieren.

Außer das damit ein Sicherheitsmechanismus von SSH ausgehebelt wurde, nämlich die Überprüfung bereits bekannter Keys. Somit wird bei erneuter Verbindung zu Systemen, deren Schlüssel bereits bekannt und verifiziert war, erneut die Gefahr einer Man-in-the-Middle Attack eingeräumt.

Besser wäre es, entweder nur die Zeile aus dieser Datei zu löschen, die am Anfang den hostnamen des betroffenen Rechners hat. Danach erfolgt bei erneuter Verbindung die Vertrauensfrage, ob diesem Schlüssel getraut werden soll oder nicht.

Am besten wäre es, die Zeile zu löschen und den Key von Hand neu einzutragen, sofern die Verbindung über ein unsicheres Netz hergestellt wird. Mit "von Hand" meine ich z.B. über ein Wechselmedium wie Diskette oder so.

[gaansch]

Gut das ist klar, aber wie man anhand der geposteten Fehlermeldung sehen kann, scheint es sich wohl um einen Rechner im lokalen Netz zu handeln...

[L00NIX]

Gut das ist klar, aber wie man anhand der geposteten Fehlermeldung sehen kann, scheint es sich wohl um einen Rechner im lokalen Netz zu handeln...

Auch in einem lokales Netz können Gefahren lauern, deswegen habe ich "vertrauenswürdig" (!=unsicher) als Bezeichnung gewählt.

[JeffRoc]

die key-datei werde ich einfach killen... passiert schon nix

das komische ist, dass ich seit der neuinstallation auch nicht mehr per win/putty auf den server zugreifen kann!! bringt keine fehlermeldung sondern kann denke ich einfach nicht mit "root" anmelden!?

ist der root denn per default sshd.conf gesperrt? ...ich weiß das dieser mal in älteren versionen gesperrt war..

Danke für die ausgiebige hilfe
jR

[L00NIX]

ist der root denn per default sshd.conf gesperrt? ...ich weiß das dieser mal in älteren versionen gesperrt war..

Schau in die Datei /etc/ssh/sshd_config

Wenn die Option "PermitRootLogin no" nicht auskommentiert oder mit "yes" deklariert ist, ist root Zugang nicht erlaubt. Ich glaube, der Defaultwert (falls diese Option auskommentiert ist) ist zulassen, aber schau sicherheitshalber in der Manpage nach oder probier' es aus.

[cane]

Den direkten Root-Login sollte man immer deaktivieren!

Es ist ja wohl nicht zuviel verlangt nach einem Login "su -" einzutippen

mfg
cane

[JeffRoc]

Den direkten Root-Login sollte man immer deaktivieren!

Es ist ja wohl nicht zuviel verlangt nach einem Login "su -" einzutippen

mfg
cane

das stimmt, so kann ich natürlich direkt wechseln - aber welchen nachteil hat denn der root zugang über ssh - secure shell ist doch sicher?!

danke für die hilfe

[L00NIX]

das stimmt, so kann ich natürlich direkt wechseln - aber welchen nachteil hat denn der root zugang über ssh - secure shell ist doch sicher?!

Sorry für diesen sinnlosen Post, aber:

Das würde mich auch mal interessieren!

[Harry]

Ehrlich gesagt, interessiert mich das auch, da ich diese These bereits mehrfach gelesen aber nicht so recht verstanden habe.

M.E. ist bei ssh der sensible Punkt doch der Moment des (Host)Schlüsselaustauschs und die Authentifizierung zwischen Client und Server mittels Signaturen (inkl. Verschlüsselung natürlich und das ganze über asymmetrische Algorithmen). Anschließend wird dann ein session-key für die symmterische Verschlüsselung generiert und auf beide Kommunikationspartner verteilt. Erst innerhalb der symmetrischen Verschlüsselung wird dann die eigentliche "Payload" übertragen. Und in der Payload dann auch erst das Passwort des Users, der sich auf dem Server anmeldet (vorausgesetzt, er führt eine normale Passwort-Authentifizierung durch).

Sollte ein Angreifer in der Lage sein, die Kommunikation bis zu diesem Punkt zu knacken, dann kommt er theoretisch immer in den Besitz des Passwortes und zwar unabhängig davon, ob sich der root direkt angemeldet hat oder nachträglich erst durch ein "su -" eingeloggt ist.

Oder habe ich da nun doch etwas nicht so richtig verstanden?

Harry

[L00NIX]

Ehrlich gesagt, interessiert mich das auch, da ich diese These bereits mehrfach gelesen aber nicht so recht verstanden habe.

Puh! Ich dachte schon ich wäre damit alleine hier...

M.E. ist bei ssh der sensible Punkt doch der Moment des (Host)Schlüsselaustauschs und die Authentifizierung zwischen Client und Server mittels Signaturen (inkl. Verschlüsselung natürlich und das ganze über asymmetrische Algorithmen).

So... und hier bemerkt man Man-in-the-Middle Attacks anhand der known_hosts Datei, die man bei einer Fehlermeldung natürlich gleich in den Wind schießt, denn dann kommt ja nur noch eine Warnung.

Bei dieser Warnung erkennt man anhand des Fingerabdrucks vom Server, ob man richtig verbunden ist. In guter alter Windowsmanier drückt man natürlich unkontrolliert auf "yes" (basst scho).

Damit hat man diesen Sicherheitsmechanismus schon mal erfolgreich ausgehebelt.

Anschließend wird dann ein session-key für die symmterische Verschlüsselung generiert und auf beide Kommunikationspartner verteilt. Erst innerhalb der symmetrischen Verschlüsselung wird dann die eigentliche "Payload" übertragen. Und in der Payload dann auch erst das Passwort des Users, der sich auf dem Server anmeldet (vorausgesetzt, er führt eine normale Passwort-Authentifizierung durch).

Da ist dann eh schon alles zu spät, sofern oben eben diese MITMA ausgeführt wurde. Der Session Key ist ja dafür da, dass wenn jemand in den Besitz des Hostkeys kommen sollte, dennoch die übertragenen Daten nicht entschlüsseln kann. Da hier der Session Key aber mit dem falschen Rechner ausgetauscht wird, ist dieser natürlich vom Cracker und bietet keinen weiteren Schutz.

Sollte ein Angreifer in der Lage sein, die Kommunikation bis zu diesem Punkt zu knacken, dann kommt er theoretisch immer in den Besitz des Passwortes und zwar unabhängig davon, ob sich der root direkt angemeldet hat oder nachträglich erst durch ein "su -" eingeloggt ist.

Na gut, er hat das Nutzer Passwort, nicht aber das von root. Das muss er/sie dann immer noch extra wissen für das "su root". Also muss der Angreifer zwei statt nur einem Passwort wissen, um root-Rechte zu erlangen.

Da die meisten Angriffe aber sowieso auf Schwachstellen in der Implementierung von irgendwelchen als root laufenden Programmen beruhen, mit denen man dann ohne Passwort root-Rechte bekommt, ist diese "Sicherheitsmaßnahme" eher überflüssig.

Oder kann das jemand mit einem Beispiel oder auch zwei belegen, dass es wirklich Sinn macht?

[Harry]

Puh! Ich dachte schon ich wäre damit alleine hier...
...
Oder kann das jemand mit einem Beispiel oder auch zwei belegen, dass es wirklich Sinn macht?

Schau an ... nun haben wir uns gegenseitig bestätigt, was wir dachten, über ssh zu wissen

Und die Frage nach dem Sinn/Unsinn eines initialen root-Logins über ssh steht immer noch im Raum

Harry