SSH mit Aufforderung zur PW-Eingabe

dirtydan

dirtydan

New Member
Hi @ all,

hier mal wieder ein Beitrag zu SSH. Dieses Mal scheints aber echt seltsam zu sein. Ich habe SSH auf 2 AIX-Servern installiert. Anschließend die Schlüssel für Root generiert und ausgetauscht so das keine Passwort-Abfrage mehr nötig ist. Funktioniert auch alles einwandfrei. Jetzt gab es die Notwendigkeit für einen anderen User der Systeme SSH verfügbar zu machen. Also meldete ich mich mit diesesm User an und generierte die Schlüssel welche ich im Anschluss ausgetauscht habe. Und nun? Gehts nicht. Er fragt jedes Mal nach dem Passwort für den jenigen User.

Weiss jemand woran das liegen kann? Bin für jeden Tipp dankbar da ich etwas unter Zeitdruck stehe.

Gruß
Dirty......
 
Hi,

nein habe ich nicht. Das ist ja die Sache. Er fragt ja auch nicht nach der Passphrase sondern nach dem normalen User-PW.

Hast Du vielleicht einen weiteren Tipp?

Gruß
Daniel
 
Hi,

beide pub-Keys sind jeweils in die authorzied_keys des jeweiligen Users hineinkopiert worden. Root hat seine eigenen Schlüssel.
Weiß jemand wo und ob es ein SSH log gibt indem mehr steht als beispielsweise "access denied" ?


Gruß
Dirty
 
Starte den Client mal mit -v und prüfe die Permissions auf .ssh und authorized_keys. SSH mag es nicht, wenn diese group/world-writable sind.
 
elias5000 said:
Starte den Client mal mit -v und prüfe die Permissions auf .ssh und authorized_keys. SSH mag es nicht, wenn diese group/world-writable sind.
Click to expand...


Hallo,

die Permissions für den Priv Key sind 600 und für die anderen files in .ssh auf 644, also nur Schreibrechte für den User. Auf das Verzeichnis .ssh sind die Berechtigungen 700 eingeteilt. Das war aber Standardmäßig nach der installation bzw. Schlüsselgenerierung so. Was meinst Du genau mit Client neu starten, meinst den sshd?


Gruß
Dirty
 
dirtydan said:
die Permissions für den Priv Key sind 600 und für die anderen files in .ssh auf 644, also nur Schreibrechte für den User. Auf das Verzeichnis .ssh sind die Berechtigungen 700 eingeteilt.
Click to expand...
Auf beiden Seiten?

Was meinst Du genau mit Client neu starten, meinst den sshd?
Click to expand...
Ich meine den ssh - wenn man den mit -v startet, dann gibt er viel Output.

Ansolsten dürfte sich ein Blick ins Security-Log auf dem Server lohnen. Da sollte ja drin stehen, wieso er keinen Key-Auth mag.
 
Ja die Berechtigungen sind auf beiden Seiten gleich.
SSH mit -v bringt folgende Mitteilung:

debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Trying private key: /home/alcibnet/.ssh/identity
debug1: Offering public key: /home/alcibnet/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Trying private key: /home/alcibnet/.ssh/id_dsa
debug1: Next authentication method: keyboard-interactive
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: password

Kannst Du damit was anfangen?
 
dirtydan said:
debug1: Offering public key: /home/alcibnet/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password,keyboard-interactive
[...]
debug1: Next authentication method: keyboard-interactive
Click to expand...
Jetzt ist das Server-Log dran. Der Client hat ihm den Key angeboten aber der Server ist nicht drauf eingegangen.
 
Das Failedlogin - Log spuckt folgende Info aus:

UNKNOWN_ + pts/9 Jul 16 14:58 16:18
UNKNOWN_ + pts/5 Jul 16 14:58 13:09
UNKNOWN_ + pts/5 Jul 16 15:00 13:09
UNKNOWN_ + pts/5 Jul 16 15:04 13:09
UNKNOWN_ + pts/5 Jul 16 15:04 13:09
UNKNOWN_ + pts/5 Jul 16 15:16 13:09
UNKNOWN_ + pts/5 Jul 16 15:24 13:09
UNKNOWN_ + pts/5 Jul 16 15:24 13:09

Kann jetzt aber auch nicht 100%ig sagen ob das mein User sein soll der sich mit ssh einloggen soll. Aber den User Alcibnet, um den es geht, finde ich in dem Log nicht. Der User ist jedoch auf beiden Maschinen (laufen im HACMP Cluster Verbund) angelegt.

Der Log für die erfolgreichen Logins sagt auch nix aus. Hatte mich den ganzen Tag nur mit root angemeldet und ansonsten steht auch dort demnach kein anderer User drin.
 
Last edited by a moderator:
Der Log-Auszug ist relativ nichtssagend. Du müsstest den SSHd geschwätziger machen. Ich kann die allerdings nicht genau sagen, wie - weil ich nicht mal weiß, ob AIX OpenSSH verwendet.
Wenn es OpenSSH ist, dann heißt die Config sshd_config und liegt unter /etc/ssh (Linux-Style) oder auch direkt unter /etc (Mac-Style) oder irgendwo da in der Gegend.

Das Loglevel am besten auf DEBUG stellen, für die Dauer der Tests und danach auf INFO.
Es müssen einfach im Log Informationen landen, die sagen, wer sich wann von wo mit welchem Authmech eingeloggt hat.
 
Ja AIX benutzt OpenSSH. Ich werde das gleich mit dem DEBUG-Mode mal ausprobieren und dann das Ergebnis Posten....
 
elias5000 said:
Das Loglevel am besten auf DEBUG stellen, für die Dauer der Tests und danach auf INFO.
Es müssen einfach im Log Informationen landen, die sagen, wer sich wann von wo mit welchem Authmech eingeloggt hat.
Click to expand...

Wo finde ich denn das dazugehörige Log indem diese Informationen durch den DEBUG bzw INFO Mode eingetragen werden?
 
OpenSSH loggt über Syslog auf als authpriv.* - in welchem File das bei AIX landet musst du mal in deiner Syslog-Config checken.

BTW: Es ist immer eine gute Idee ein Logfile zu haben (z.B. /var/log/anything), in dass alles (*.*) geloggt wird - dann muss man nicht suchen. (Sollte nur für root lesbar sein.)
 
Also aus dem Log kann ich auch nichts zutreffendes bzw. problemlösendes empfehlen. Da es mit anderen Benutzern geht, werde ich mal in Erfahrung bringen ob der User gelöscht werden und noch einmal neu erstellt werden kann. Vielleicht schafft das Abhilfe.....
 
Ich habe den Benutzer gelöscht und mit selber UID wieder angelegt. Auch die Schlüssel habe ich zur Sicherheit noch einmal neu erstellt und ausgetauscht. Ergebnis: Keins. Immer noch die selbe sch*****.
So langsam gehen mir die Ideen aus....
 
dirtydan said:
Ja die Berechtigungen sind auf beiden Seiten gleich.
SSH mit -v bringt folgende Mitteilung:

debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Trying private key: /home/alcibnet/.ssh/identity
debug1: Offering public key: /home/alcibnet/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Trying private key: /home/alcibnet/.ssh/id_dsa
debug1: Next authentication method: keyboard-interactive
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: password

Kannst Du damit was anfangen?
Click to expand...



Mir ist mal was aufgefallen!
Oben steht "Trying private key: / .../identity" und Trying public key /..../id_rsa"

Die Angaben stimmen nicht! Der private key liegt in id_rsa und der public in id_rsa.pub....

Ne Idee dazu wie man das ändern könnte?
 
dirtydan said:
Die Angaben stimmen nicht! Der private key liegt in id_rsa und der public in id_rsa.pub....
Click to expand...
Das sind default-Namen und wie man sieht (Offering public key: /home/alcibnet/.ssh/id_rsa) findet SSH den richtigen auch.

Was du da postest ist aber die Ausgabe auf dem Client - und die verweist eindeutig auf den Server, der den angeboteten Key allem Anschein nach nicht akzeptiert.

Zum Thema Server fallen mir nur 3 mögliche Szenarien ein, auf die es jetzt ankommt:
1. In den Logs steht, dass es geht.
2. In den Logs steht, wieso es nicht geht.
3. In den Logs steht nichts.

1. Ist das Ziel.
2. Sagt aus, was getan werden muss.
3. Bedeutet, dass entweder an der falschen Stelle geschaut wurde oder der OpenSSH mehr verbose eingestellt werden muss.

1. sieht ungefähr so aus:
Jul 19 11:37:28 thor sshd[633]: Accepted publickey for elias from 1.2.3.4 port 59546 ssh2
Click to expand...
Solange das nicht drin ist, hast du entweder Fall 2 oder 3 - und was das bedeutet, habe ich schon geschrieben.

Was nicht im Log steht, ist keine gesicherte Erkenntnis. Und nur gesicherte Erkenntnisse sind wertvoll.
Alles andere ist wildes Vermuten und Raten.
 
You must log in or register to reply here.
Back
Top