SSH public key authentication will nicht auf einem Host

[pangu]

Hi all,

irgendwie steh ich grad auf dem Schlauch. Ich hab das schon so oft gemacht und plötzlich stehe ich vor diesem Problem:

Host(A) soll auf Host(B) durch ein public key auth zugreifen (ohne pwd). Die Schritte sind simpel:

Auf Host(A):

Code: Alles auswählen

ssh-keygen -t rsa
ssh-copy-id root@hostb

Dann noch Eingabe des root-pwds damit ich access auf hostb erlange, damit die keys rüberkopiert werden können und...
fertig! ich hab das auch überprüft, die keys sind definitiv angelangt auf hostb und natürlich auch im richtigen Userdir (in diesem Falle /root/.ssh/authorized_keys). Hab das zig mal probiert, auch manuell rübergebracht auf hostb und eingetragen. Auch habe ich auf HostA meine known_hosts komplett gelöscht, oder auch manuell mit "ssh-keygen -R hostb" versucht den Eintrag für diesen Clienten zu entfernen.

Es will einfach nicht klappen, denn wenn ich bei HostA in derselben Shell+Usernamen eingebe "ssh root@hostb" dann werde ich nach dem Passwort gefragt, was aber eigentlich nicht sein sollte. Durch Googlerecherche konnte ich lesen, dass auf dem Server die authorized_keys nur Schreibrechte für den entsprechenden User besitzen darf, aus Sicherheitsgründen wird das gecheckt. Aber auch das stimmt und ich hab die Zugriffsflags mit zig andren Clients verglichen. Auf HostB hat die /root/.ssh/authorized_keys user+gruppe = root und mod=600.

Und die sshd_config habe ich auch gecheckt, da ist so ziemlich alles standard, und PubkeyAuthentication steht natürlich auch auf yes und root darf sich natürlich auch anmelden. Und mit einem anderen als HostA habe ich es auch probiert. Geht auch nicht. Es muss definitiv irgendwas an HostB sein, bloss was??

Irgendwie steh ich grad auf dem Schlauch, und bitte um eure Hilfe. Danke!

[feltel]

Was sagt denn /var/log/auth.log auf dem Zielrechner?

[pangu]

Authentication refused, bad ownership or modes for directory /root.

Arrrrgh! tatsächlich: das /root Verzeichnis auf HostB hatte 777 gesetzt. Da werd ich morgen früh meinem Kollegen die Ohren langziehen. Der muss natürlich auf 700der stehen und zur Sicherheit läßt es der ssh daemon nicht zu, ähnlich wie weiter oben mit der authorized_keys beschrieben.

Danke für den Tip, der mich letztendlich darauf gebracht hat.

[feltel]

Keine Ursache

[pangu]

Jetzt hab ich dasselbe Problem noch mal erlebt, jedoch liegts nicht am /root Verzeichnis. Das root-verzeichnis auf dem Zielhost hatte zwar 755 per default, aber selbst als ich es auf 700 gesetzt habe, half es nix.

Bei dem Zielrechner handelt es sich um eine IPFIRE. Keine Ahnung, ob da jetzt irgendwelche Zusatzbeschränkungen aktiv sind oder nicht. Auf jeden Fall hab ich die sshd_config so angepasst, damit pubkeyauthentication auf YES steht. Wenn ich über die Weboberfläche des IPFire nachschaue, dann ist der Haken bei "Pubkeyauthentification" nicht drin. Also dachte ich mir, dass ich die Änderung in sshd_config wieder rückgängig mache, und stattdessen diese Funktion über das Webinterface aktiviere. Aber komischerweise kann ich im Webinterface zum SSH-Zugriff einstellen was ich möchte, es wird nicht übernommen auch wenn ich auf speichern klicke.


Irgendeine Idee?

GELÖST: Die manuelle Anpassung an der /etc/sshd_config schien den SSH Dämon nicht zu interessieren, da wohl die settings von wo anders geladen wurden. Ich habe ,nach dem ich ja wie oben beschrieben habe, mit dem Browser keine Änderungen am Webinterface des IPFire durchführen können. Da ich Opera einsetze und aus Erfahrung wußte, dass er bei manchen Seiten Probleme macht, hab ichs daraufhin mit dem Internet Explorer probiert. Also mit dem IE auf das Webinterface der IPFire zugegriffen, und dort den Haken "Pubkey Authentification" reingesetzt. Gespeichert, neugeladen, und siehe da, die Einstellung blieb nun endlich. Und seitdem kann ich mich nun wie erwartet mit pubkey anmelden. Problem also gelöst