PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : SSH - Fehler beim Verbindungsaufbau



JeffRoc
23.06.04, 00:11
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
23.06.04, 05:01
lösche mal die Datei /home/oliver/.ssh/known_hosts
danach sollte es wieder gehen

JeffRoc
23.06.04, 08:23
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
23.06.04, 09:21
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
23.06.04, 10:11
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
23.06.04, 10:32
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
23.06.04, 10:38
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
23.06.04, 13:08
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
24.06.04, 08:09
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
24.06.04, 12:06
Den direkten Root-Login sollte man immer deaktivieren!

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

mfg
cane

JeffRoc
25.06.04, 13:06
Den direkten Root-Login sollte man immer deaktivieren!

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

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
25.06.04, 14:46
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
25.06.04, 15:01
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
25.06.04, 15:25
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
25.06.04, 15:42
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 :D

Harry

spirou
25.06.04, 17:01
Is doch ganz einfach, gelingt es jemand, den ssh-zugang zu knacken (wie auch immer), ist er wenigstens nicht gleich root. Ist halt eine weitere Hürde zu nehmen, weil er nach erfolgtem Einbruch dann auch noch das rootpasswort brauchen täte.
(Hab keine Ahnung, aber das erscheint mir halbwegs logisch).

Grüßle
Spirou :D

L00NIX
25.06.04, 17:01
Schau an ... nun haben wir uns gegenseitig bestätigt, was wir dachten, über ssh zu wissen ;)

Wohl wahr, aber dennoch unterschiedlich formuliert.



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

Nicht doch, hier: Zwei Passwörter > ein Passwort

Harry
25.06.04, 18:14
Hi,

wenn die ssh-Session geknackt _wird_, dann ist es völlig wurscht, ob ich mich zuerst mit einem "normalen" User eingeloggt habe und dann per "su -" auf root wechsele, oder ob ich mich direkt als root einlogge.
Wird die Session dann geknackt, und ich arbeite bereits als root, dann hat der Cracker root-Rechte. Andererseits gelangt das root-Passwort in beiden Fällen durch die ssh-Session (einmal früher - einmal später) und lässt sich also auch auslesen (wenn die Session mitgelesen wurde). Sicherheitsrelevant gesehen gibt es da erstmal überhaupt keinen Unterschied.

Nochmal: Sowohl die initiale Anmeldung (das Passwort des Users) als auch das Passwort des root mit "su -" gelangen über die ssh-Session. Wird diese geknackt (was praktisch sicher alles andere als einfach ist), dann ist meine Sicherheit dahin und zwar ganz unabhängig davon, ob ich mich erstmal initial mit einem User eingeloggt habe und erst dann ein su - mache oder mich direkt als root anmelde.

Harry

Harry
25.06.04, 18:19
Is doch ganz einfach, gelingt es jemand, den ssh-zugang zu knacken (wie auch immer), ist er wenigstens nicht gleich root.
Ja klar - ssh ist ja eben sooo einfach und deswegen wissen hier auch alle ganz genau, wie es funkioniert :D

Wenn dieser _jemand_ ssh benutzt, um eine remote-Box zu administrieren, dann muss er irgendwie root sein, gell? In der Folge hat er eine offene root-Session über ssh auf der Box, richtig? Und wenn in dem Zeitraum die ssh-Session gecrackt/gehijackt (was für nette Anglizismen ;)) wird, dann ist derjenige natürlich root.

Etwas anderes hätten wir hier, wenn sich unser User remote über ssh einloggt, nur um seine Mails zu lesen; dazu benötigt er sicher sowieso keine root-Rechte (weder mittel- noch unmittelbar) - für den Fall stimme ich Deiner Aussage zu ;)

Harry

IPonEverything
17.09.04, 12:04
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 :D

Harry

HI,
was halten die Herren von der idee,
dass böse eindringlinge bei erlaubten root logins wohl einen usernamen nicht mehr raten müssen?
mfg

isch wees doch unix...