sshd unterschiedliche host Einträge in ~/.ssh/config

[reredok]

Hallo Forum,

es geht prinzipiell um das Thema [... Permission denied (publickey) ...]

Die Steuerung ob die ssh Client Verbindung ein Passwort oder einen public key nutzt habe ich in ~/.ssh/config konfiguriert. Dadurch wird erst in den Host-Einträgen gesucht um eine Password Authentication durchzuführen; falls kein Host Eintrag zutrifft wird dann public key genutzt.

Host <ip-Adresse>
Hostname host01.domain.tld
User <remote ssh Benutzer>
Port 22
PasswordAuthtication yes

Host <ip-Adresse>
Hostname host02.domain.tld
User <remote ssh Benutzer>
Port 22
PasswordAuthtication yes

Das funktioniert für den ersten host host01 wunderbar.
Beim ssh Aufruf sieht man wie er alle Möglichkeiten durchgeht und bei der Password Authentication weitermacht.

Beim zweiten host allerdings nicht. Dort dann mit der Fehlermeldung "Permission denied (publickey)"

Auf allen 3 debian Systemen ist der gleiche sshd Stand installiert. Ich habe auch mittels " ssh -o PreferredAuthentications=password -o PubkeyAuthentication=no account@your-ip " versucht das Verhalten zu erzwingen; hab mit "LogLevel VERBOSE" in /etc/ssh/sshd_config versucht das Problem zu lokalisieren. Hab mit "Match" experimentiert ...

Die beiden ssh Client configs /etc/ssh/ssh_config auf host01 und host02 sind identisch.

Bin mit meinem Latein ziemlich am Ende warum sich die beiden linux(e) so unterschiedlich verhalten

Vlt weiß jemand von euch wir man das am besten konfiguriert.

Vielen herzlichen Dank
reredok

[MSfree]

PasswordAuthtication muß der Server zulassen. Wenn der Server das nicht erlaubt, nützt die Einstllung in der Clientkonfiguration gar nichts.

[reredok]

.. hatte ich auch gedacht. Nun bei beiden /etc/ssh/sshd_config ist <PasswordAuthentication yes> konfiguriert und es funktioniert nur bei host01

[pixelpirat]

PasswordAuthtication yes
Ist das nur ein Abtippfehler oder steht es so in der .ssh/config

Es muss heißen: PasswordAuthentication yes

[reredok]

ja Tippfehler. Steht als
PasswordAuthentication yes
in sshd_config

Ich hab keine Ahnung wo ich noch suchen soll ...

[pixelpirat]

Wenn Du ein diff über bei sshd_configs hast laufen lassen und sie sind 100% identisch, dann kontrolliere mal die Owner / Permissions in den Verzeichnissen und Dateien.

Ein wenig stochern im Nebel. Hast Du auch mal die Reihenfolge der Loginversuche umgedreht? Nicht das nach dem ersten Versuch etwas im RAM gehalten wird, dass den 2 Loginversuch anders verlaufen lässt.

Rein interessenshalber. Warum besteht man bei ssh auf PW-Logins, wenn es doch mit PublicKeys wesentlich einfacher und komfortabler geht?

Gruß
Pixelpirat

[pixelpirat]

Wenn Du ein diff über bei sshd_configs hast laufen lassen und sie sind 100% identisch, dann kontrolliere mal die Owner / Permissions in den Verzeichnissen und Dateien.

Ein wenig stochern im Nebel. Hast Du auch mal die Reihenfolge der Loginversuche umgedreht? Nicht das nach dem ersten Versuch etwas im RAM gehalten wird, dass den 2 Loginversuch anders verlaufen lässt.

Rein interessenshalber. Warum besteht man bei ssh auf PW-Logins, wenn es doch mit PublicKeys wesentlich einfacher und komfortabler geht?

Gruß
Pixelpirat

[reredok]

zu Deiner Frage: [... Rein interessenshalber. Warum besteht man bei ssh auf PW-Logins, wenn es doch mit PublicKeys wesentlich einfacher und komfortabler geht? ...]
Ich hab den host03 abgesichert wie in https://blog.buettner.xyz/sichere-ssh-konfiguration/ beschrieben. Ziemlich spannend auch der Artikel https://stribika.github.io/2015/01/04/s ... shell.html

Nun "verbaut" mir der erste Artikel die /etc/ssh/ssh_config. Damit funktioniert nur noch public key AUTH. Auch wenn ich mich per ssh auf ein anderes remote system einwählen will kommt "Permission denied (publickey,password)" und das nervt da ich mich an anderen System gerne interim mittel user und password einlogen will. Mit anderen Worten: es muss also an der /etc/ssh/ssh_config von host03 liegen...

Deswegen war meine Idee das man die ssh AUTH mittels "host" oder "Match Adress" unterschiedliche AUTH (public key, password) pro host, fqdn, ip-Adr. konfigurieren kann was ja auch bei unterschiedlichsten Google Suchen angegben wird was aber wie gesagt für host02 nicht funktioniert.

[MSfree]

Blöde Frage am Rande: den sshd auf dem Server hast du aber nach Änderung der /etc/ssh/sshd_config schon neu gestartet?

Schieb mal deine config aus dem ~/,ssh-Verzeichnis woanders hin, oder lösche sie ganz. SSH handelt sowieso von selbst mit dem Server aus, ob der normale Benutzer/Paßwort-Login verwendet werden soll, da braucht man nichts in die config zu schreiben.

Dann führst du zu beiden Servern mal

Code: Alles auswählen

ssh user1@server1 -vvv

aus, und

Code: Alles auswählen

ssh user2@server2 -vvv

aus. das "-vvv" sollte dir genug Augaben liefern, um zu erkennen, was da schief läuft.

[mat6937]

es geht prinzipiell um das Thema [... Permission denied (publickey) ...]
...
Auf allen 3 debian Systemen ist der gleiche sshd Stand installiert.

Wie sind die Ausgaben von:

Code: Alles auswählen

cat /etc/ssh/sshd_config | grep -iE 'AuthenticationMethods|IPQoS'
ssh -V
sshd -t
ldd $(which sshd) | grep -i wrap
netstat -tlpena | grep -i inetd

?

[wanne]

Bei SSH ist es normal, dass man alle Varianten mal durchprobiert um raus zu finden, was der Server denn haben will. Per default erst mal gssapi und PubKey mit allen Keys die man hat (das können eine Menge sein) dann ChallangeResponse und dann Passwort.
Bei dem ersten funktioniert das hervorragend. Da wird zuerst PublicKey versucht – funktioniert nicht dann passwort und das tut dann.
Der 2. Server scheint irgend wie abstrus konfiguriert zu sein und entweder keine PasswortAuthentification zuzulassen oder nach ein paar Versuchen die Verbindung abzubrechen. Wie schon angemerkt das hilft weiter, was das passiert.

Code: Alles auswählen

ssh user2@server2 -v

Sollte der Fall sein, dass der der nur nach dem XTen mal abbricht kannst du PubKey abschalten:

Code: Alles auswählen

Host <ip-Adresse>
Hostname host02.domain.tld
User <remote ssh Benutzer>
Port 22
PasswordAuthtication yes
PubkeyAuthentication no

Eventuell will der auch ChallangeResponse (Das ist im Normalfall auch mit Username und Passwort!)

[reredok]

da ich allmählich mit dem Konstrukt durcheinander komme die richtigen hosts:
host01 -- jitsi (192.168.2.159)
host02 -- ns01 (192.168.2.5)
host03 -- rclone (192.168.2.149)
----------------

>>Blöde Frage am Rande: den sshd auf dem Server hast du aber nach Änderung der /etc/ssh/sshd_config schon neu gestartet?

Klar

rclone -- ssh --> jitsi (Verbindung OK, Password)
rclone -- ssh --> ns01 (Permission denied (publickey))
wsl (windows Subsystem Linux) -- ssh --> jitsi (Verbindung OK, Password)
wsl (windows Subsystem Linux) -- ssh --> ns01 (Verbindung OK, Password)
wsl (windows Subsystem Linux) -- ssh --> rclone (Verbindung OK, public key, hier wurde public key AUTH explizit konfiguriert)


ssh -V (alle 3)
OpenSSH_7.9p1 Debian-10+deb10u2, OpenSSL 1.1.1d 10 Sep 2019

cat /etc/ssh/sshd_config | grep -iE 'AuthenticationMethods|IPQoS'
(keine Ausgabe)

sshd -t
/etc/ssh/sshd_config line 35: Deprecated option UsePrivilegeSeparation (rclone)
keine Ausgabe (ns01)
keine Ausgabe (jitsi)

ldd $(which sshd) | grep -i wrap
libwrap.so.0 => /lib/x86_64-linux-gnu/libwrap.so.0 (0x00007ff77ce82000) (rclone)
libwrap.so.0 => /lib/x86_64-linux-gnu/libwrap.so.0 (0x00007f3b2809b000) (ns01)
libwrap.so.0 => /lib/x86_64-linux-gnu/libwrap.so.0 (0x00007f4617c89000) (jitsi)

netstat -tlpena | grep -i inetd
keine Ausgabe (rclone, ns01, jitsi)

Vielen Dank für die vielen Rückmeldungen - muss aber nebenbei noch arbeiten und werde mal alles Mögliche heute spät Abends testen!

linux ist leider nur ein Hobby

[mat6937]

cat /etc/ssh/sshd_config | grep -iE 'AuthenticationMethods|IPQoS'
(keine Ausgabe)

Versuch mal beim 2. Server, in der sshd_config, mit der Zeile:

Code: Alles auswählen

AuthenticationMethods password

, danach den sshd neu starten, nach dem restart:

Code: Alles auswählen

sshd -t

und anschließend mit dem ssh-Client zum 2. Server verbinden:

Code: Alles auswählen

ssh -v user@ns01

[reredok]

Ich habe die ~/.ssh/config Host Konfiguration auf ca. 5 weiteren debian Test-VM ausprobiert und dort läuft es. Da auf dem ns01 nur ein dnsmasq u. ddclient aktiv ist werde ich den mal mit einer debian 10.4.x neu aufsetzen weil es ist der einzige bei dem es nicht funktioniert.

[wanne]

Kannst du die Antworten lesen? Dir haben mindestens 3 Leute einen Weg zur Lösung aufgezeigt. Wenn du den nicht einschlägst, kann man nichts machen...

[reredok]

Ich hab euere Antworten gelesen und hab auch alles ausprobiert - leider ohne Erfolg.

Entschuldig das ich nicht alle Ansätze und Fehlversuche gepostet habe; auch habe ich noch viel recheriert ohne konkret einen roten Faden zu finden. Ich war jedoch der Meinung das der ~/.ssh/config host Ansatz richtig und wenn es wie gesagt bei allen anderen debian-VM funktioniert ...

Ganz oben hat jemand vermutet das irgendetwas mit dem ns01 nicht stimmt und der Gedanke geistert die ganze Zeit in meinem Kopf vorallem weil ns01 die älteste debian Installation ist.

Ich hoffe ich hab euch nicht verärgert. Von euch gab es ganz viel Rückmeldung und hier ist wirklich ein tolles debian Forum - ganz großes Lob!

Sei mir nicht böse aber den ns02 hatte ich in 25 Minuten aufgesetzt und et voilà ES FUNKTIONIERT. Manchmal, zumindest ist das meine Erfahrung, macht es Sinn nicht die Ursache zu suchen und hoffentlich zu finden sondern neu zu machen. Klar mich hätte auch das Detail interessiert.

Herzlichen Dank an euch alle

[pixelpirat]

Schön, dass es jetzt funktioniert.

Ich habe heute auch eine Maschine neu aufgesetzt. Der Hoster bot Buster in der minimal Version an. Leider vergaß er dazu zu schreiben, dass er in der /etc/systemctl.conf in der letzten Zeile dieser Datei ipv6 disabled hat.
Und die net-utils fehlten auch.