Kein SSH-Zugriff auf Server

[tro]

Hallo,

ich möchte mit 2 Kubuntu-PCs auf einen Stand alone Datei- und Druckserver zugreifen, auf dem Debian 5.0 ohne GUI läuft. Auf einem PC habe ich Key Authentification eingerichtet, d.h. mit

ssh-keygen -t dsa

ein Schlüsselpaar erzeugt und den Pub-Key auf den Server kopiert (mit ssh-copy usw.). Ziel war, in einem Script einen SSH-Zugriff ohne Passwortabfrage benutzen zu können um z.B. den Server mit ssh <sevrer-IP> halt runterfahren zu können (="ausschalten"). Dies funktioniert auch hervorragend.

Nun möchte ich dies auch mit dem 2. PC so machen. Dieser kommt aber nicht mehr auf den Server. Am 2. PC kommt folgende Fehlermeldung:

The authentcity of host 'xxx.xxx.xxx.xxx` can`t be established.
RSA key fingerprint is xxxxxxxx.
Are you sure you wont to continue connecting (yes/no)?

Ist egal wie man antwortet, es kommt danach die Meldung "Host key verification failed"

Nun habe ich in manchen Beiträgen gelesen, das man eine Zeile aus der Datei "~/,ssh/known-hosts" löschen soll. Diese Datei kann ich auf meinem System aber nicht finden (und dann lösch mal).

Wo könnte diese Datei sein?

Muß ich in der sshd.config was einstellen?

Sollte ich die beiden erzeugten Schlüssel des ersten PCs nur auf den 2. PC kopieren (habe ich noch nicht ausprobiert)? Oder wie könnte die Lösung aussehen?

[uname]

Es liegt wohl an der "known_hosts" mit Unterstrich.

Code: Alles auswählen

~/.ssh/known_hosts

Poste evtl. mal:

Code: Alles auswählen

ls -al ~/.ssh

Das Löschen der Datei stellt kein Risiko dar. Der SSH-Client merkt sich nur die Fingerprints des Servers. Wenn der Schlüssel des Servers sich ändert passt der Eintrag nicht mehr. Bewahrt unter anderem for Man-in-the-Middle-Angriffen würde ich sagen.

[tro]

Hallo,

danke für die schnelle Antwort

Es liegt wohl an der "known_hosts" mit Unterstrich.

nein, ich habe schon nach Namen mit Unterstrich gesucht. Der Hinweis im Threadbeginn war falsch von mir, nur hier habe ich dies verwechselt.

Poste evtl. mal:

Code: Alles auswählen
ls -al ~/.ssh

Hier das Ergebnis:

Code: Alles auswählen

insgesamt 16
drwx------  2 root root 4096 2009-06-21 23:23 .
drwx------ 11 root root 4096 2009-06-21 22:55 ..
-rw-------  1 root root  672 2009-06-21 23:23 id_dsa
-rw-r--r--  1 root root  606 2009-06-21 23:23 id_dsa.pub

Was nun "insgesammt 16" heißt, verstehe ich nicht. Sind dort noch mehr Dateien "versteckt"? Wie sehe ich die?

[uname]

Das ist schon in Ordnung.

Wenn ich gar icht mehr weiter weiß mach ich es so. Ich lege ein leeres Verzeichnis an, gehe in das leere Verzeichnis und führe den Befehl per strace durch:

Code: Alles auswählen

strace -ff -o out.txt ssh ...

Und dann die ganzen erzeugten Dateien mal durchwühlen. Alternativ kann man auch mal die Option "-v" oder "-vv" versuchen.

[tro]

Wenn ich gar icht mehr weiter weiß mach ich es so. Ich lege ein leeres Verzeichnis an, gehe in das leere Verzeichnis und führe den Befehl per strace durch:

Code: Alles auswählen
strace -ff -o out.txt ssh ...

ok, habe ich auch gemacht und erhalte eine Datei mit über 6000 zeilen, die mir nichts mehr sagen (nur noch böhmische Dörfer).

So komme ich leider auch nicht weiter. Gibt es weitere Ideen?

[Danielx]

Was nun "insgesammt 16" heißt, verstehe ich nicht.

Die angezeigten Dateien belegen insgesamt 16 Blöcke des Dateisystems.

Gruß,
Daniel

[tro]

danke, man sieht den Wald vor lauter Bäumen nicht

[dingsda]

Als Erstes versuche ssh -vvv um zu sehen was wirklich das Problem ist.

- verw. gpg-agent und teile ihm deine key(s) mit
- wenn du mehr als einen key hast und MaxAuthTries 1 in /etc/ssh/sshd_config kann dies der Grund sein warum der sshd nach dem ersten try mit dem falschen key die Verbindung beendet
- du kannst MaxAuthTries 1 erhoehen oder noch besser
- lokal (auf client seite) den passenden key angeben (z.B. IdentityFile %d/.ssh/keypairs/github_id_rsa) sodass es bei MaxAuthTries 1 bleiben kann

mehr info gibt es hier http://sunoano.name/ws/public_xhtml/ssh.html

[tro]

Hallo dingsda,

Als Erstes versuche ssh -vvv um zu sehen was wirklich das Problem ist.

Ja, der Befehl mit den Parametern bringt Klarheit. Der Befehl sucht nach Einträgen in
- /root/.ssh/known_hosts
- /etc/ssh/ssh_known_hosts
nachdem er da nichts findet noch in
- /root/.ssh/known_hosts2
- /etc/ssh/ssh_known_hosts

Problem ist nur, kein dieser 3 Dateien befinden sich auf dem Rechner. Da ich die fehlende known_hosts schon im Verdacht hatte, habe ich ssh auch schon deinstalliert und wieder installiert (nach beiden Methoden, die Synaptic zur Verfügung stellt.

Für mich ist es nun klar, die fehlende known_hosts ist das Problem. Aber wie erzeuge ich sie?
Deinstallation und Installation reichen nicht aus. Gibt es ein reconfigure?

- wenn du mehr als einen key hast und MaxAuthTries 1 in /etc/ssh/sshd_config kann dies der Grund sein warum der sshd nach dem ersten try mit dem falschen key die Verbindung beendet
- du kannst MaxAuthTries 1 erhoehen oder noch besser

In der sshd_config gibt es den Parameter MaxAuthTries noch nicht, könnte somit ein Defaultwert (=1?) zuschlagen.

Danke für den Link, den kannte ich noch nicht.

So, alle deine Vorschläge habe ich zwar noch nicht abgearbeitet, aber ich halte mittlerweile die fehlende known_hosts Datei für den Übeltäter und konzentrier mich erstmal darauf.

Hast du Vorschläge, wie man die erzeugt?

[whisper]

Schon mal als normaler user die sache probiert und nicht als root?
könnte sein, das root_login verboten wird.
known_hosts wird beim ersten login angelegt, das musst du wirklich nicht selber machen
dein pub-key muss in die Datei authorized_keys auf dem Server.
die Datei authorized_keys musst 'DU anlegen, das kann in einfachsten Fall die umbenannte pub-key Datei sein und muss im Ordner .ssh liegen

[tro]

Hallo,

Schon mal als normaler user die sache probiert und nicht als root?

ja, habe ich. Aber nachdem ich dieses Verhalten habe, habe ich ssh ein paar mal de- und installiert. Habe danach erst als User und danach als root eine ssh-Verbindung zum Server probiert (und andersrum: erst als root und dann als User).
--> gleiches Verhalten

Nun habe ich die Datei "known_hosts° vom 1. Pc, auf dem die Arie ja funktioniert, auf den 2. PC kopiert.
Und siehe da, es funktioniert. Nun läuft der 2. PC ganauso wie er soll.
--> Problem war wirklich die fehlende Datei "known_hosts"

Warum die fehlte und warum sie nicht erneut angelegt wurde, kann ich mich nur mit Überresten der vorherigen Installation erklären. Vielleicht befindet sich irgendwo noch ein Eintrag,der dieses Verhalten bewirkt. Keine Ahnung.

Nun, es läuft. deswegen danke an alle die mir bei der Einkreisung des Problem geholfen haben.

Sollte jemand noch eine Erklärung für dieses Verhalten haben, wäre ich sehr interessiert, damit man dies zu einem logischen Abschluß führen kann.

[dingsda]

Hast du Vorschläge, wie man die erzeugt?

touch <filename> siehe man touch

hm ... mein Vorschlag waere ganz locker bleiben denn, wie immer, ist es sicher eine Kleinigkeit. Ich sage einfach einmal so, vom Bauch heraus, dass PKA setup von dir ist ein wenig buggy/verkonfiguriert. Ich wuerde nochmal Schritt fuer Schritt alles machen ... das Dusselsichere (tm) Kochrezept findest du ja auf Suno's page. Um mit einem clean slate zu starten purge openssh-{server,client} mit aptitude purge <package_name>

http://sunoano.name/ws/public_xhtml/ssh ... entication there you go again

[dingsda]

die Datei authorized_keys musst 'DU anlegen, das kann in einfachsten Fall die umbenannte pub-key Datei sein und muss im Ordner .ssh liegen

ja und nein; besser ssh-copy-id nehmen denn dann ist garantiert das man auch kein permisson problem bekommt ... siehe link oben, Strg+f in iceweasel erlaubt das suchen nach ssh-copy-id auf der page vom Suno