dennis93
Goto Top

OpenSSH Login mit Public Key schlägt fehl, mit Passwort funktioniert

Hallo zusammen,

ich hatte hier schon nach einer Anleitung für einen SFTP Server mit Linux gefragt, habe dort auch Antworten bekommen.

Ich habe jetzt nach folgender Anleitung mir mit OpenSSH unter Debian den SFTP Server installiert:
Debian SFTP-Server einrichten

Das ganze funktioniert mit Passwort einwandfrei. Anschließend habe ich mit Puttygen mir einen Public und Private Key erstellt.

Danach folgende Befehle über Putty auf dem Debian ausgeführt um das Login mittels Public Key zu ermöglichen:
cd /home/username
mkdir .ssh
chmod 700 .ssh
touch .ssh/authorized_keys
chmod 700 .ssh/authorized_keys

Anschließend habe ich den Inhalt aus dem Puttygen Fenster (für OpenSSH, steht extra dabei) mittels nano in die Datei authorized_keys geschrieben:

nano .ssh/authorized_keys

Anschließend habe ich den SSH Dienst neugestartet mit

/etc/init.d/ssh restart

Der Login mit meinem Private Key vom Client aus funktioniert allerdings leider trotzdem noch nicht. Ich habe auch versucht den Inhalt der authorized_keys Datei zu löschen und mit folgendem Befehl aus der Datei zu importieren:

cat /home/username/upload/public.pub >> /home/username/.ssh/authorized_keys

Dort hat er dann aber natürlich die SSH2 Version eingetragen, die durch Putty als Datei erstellt wurde. Auch das hat nicht funktioniert.

Ich habe mir nun mal das Log angeguckt und dort steht nur folgendes:

Jan 17 14:46:44 SFTP-Server sshd[2468]: error: Received disconnect from 192.168.80.205 port 58941:13: Unable to authenticate [preauth]
Jan 17 14:46:44 SFTP-Server sshd[2468]: Disconnected from 192.168.80.205 port 58941 [preauth]

Hat jemand eine Idee, woran es noch liegen könnte?

Danke im Voraus!

Content-Key: 398543

Url: https://administrator.de/contentid/398543

Ausgedruckt am: 19.03.2024 um 04:03 Uhr

Mitglied: bloodstix
bloodstix 17.01.2019 um 14:55:59 Uhr
Goto Top
Hallo,

lass doch die Verbindung mal mit -vvv laufen (geht beim linux-SSH-Client, mal schauen obs da bei Putty ähnliches gibt), dann siehst du besser, was genau schief läuft.

Wo liegt denn der public-Key vom verbindenden Benutzer? In /home/username/.ssh/* ?

Gruß
bloody
Mitglied: Dennis93
Dennis93 17.01.2019 um 14:58:25 Uhr
Goto Top
Wie genau mache ich das mit "-vvv"?
Ich möchte es ja nachher eigentlich mit WinSCP oder FileZilla nutzen. Kenne mich mit Linux leider nur sehr rudimentär aus face-confused

Der Public-Key vom verbindenden Benutzer liegt in /home/username/.ssh/authorized_keys

Also ist in der Datei eingetragen.
Mitglied: bloodstix
bloodstix 17.01.2019 aktualisiert um 15:03:28 Uhr
Goto Top
Mit "-vvv" meine ich: Du kannst den SSH-Client, zumindets unter Linux, mit "sehr verbosem logging" starten, so das er alle möglichen Details zum Verbindungsaufbau preis gibt. U.a. welcher key genutzt wird usw.

Nein ich meinte, wo der Key auf dem Windows-Rechner liegt. Putty muss den entsprechenden Key, den du in authorized_keys eingetragen hast, beim Verbinden vom Client an den Server mitgeben, sonst kann es nicht funktionieren. Sicher das hier die Pfade stimmen?

Question: 
How does one enable Putty debug in Centrify Putty/stock Putty?

Answer:
A) If you are using Centrify Putty or Stock Putty
Configuring PuTTY Debug Logs:

       From the PuTTY Configuration, in the left pane, click on  "Logging" under "Session".  
       On the right, ensure "Log all session output" or "Log SSH packet data" is selected.  
       Note the path to the log file which needs to be sent along with sshd logs.
Mitglied: Dennis93
Dennis93 17.01.2019 um 15:09:26 Uhr
Goto Top
Habe mal im FileZilla das Logging hochgeschraubt! Dabei kam folgendes:

Status:	Verbindung zum Server getrennt
Trace:	CControlSocket::DoClose(66)
Trace:	CControlSocket::DoClose(66)
Trace:	CControlSocket::DoClose(66)
Trace:	CFileZillaEnginePrivate::ResetOperation(0)
Status:	Verbinde mit 192.168.80.206...
Trace:	CControlSocket::SendNextCommand()
Trace:	CSftpDeleteOpData::Send() in state 0
Trace:	Going to execute C:\Program Files\FileZilla FTP Client\fzsftp.exe
Antwort:	fzSftp started, protocol_version=8
Trace:	CSftpDeleteOpData::ParseResponse() in state 0
Trace:	CControlSocket::SendNextCommand()
Trace:	CSftpDeleteOpData::Send() in state 2
Befehl:	keyfile "C:\SFTP\key\private.ppk"  
Trace:	CSftpDeleteOpData::ParseResponse() in state 2
Trace:	CControlSocket::SendNextCommand()
Trace:	CSftpDeleteOpData::Send() in state 3
Befehl:	open "username@192.168.80.206" 22  
Trace:	psftp: Implicit session load.
Trace:	Connecting to 192.168.80.206 port 22
Trace:	We claim version: SSH-2.0-FileZilla_3.39.0
Trace:	Server version: SSH-2.0-OpenSSH_7.4p1 Debian-10+deb9u4
Trace:	Using SSH protocol version 2
Trace:	Doing ECDH key exchange with curve Curve25519 and hash SHA-256
Trace:	Server also has ecdsa-sha2-nistp256/ssh-rsa host keys, but we don't know any of them  
Trace:	Host key fingerprint is:
Trace:	ssh-ed25519 256 03:fb:4f:9b:b9:3b:db:9c:65:6a:a4:f8:d1:54:e8:c9 xAoEd+mpA1+omd5IPcVsX56tGD1k++G0y7hODRIfH1o=
Trace:	Initialised AES-256 GCM client->server encryption
Trace:	Initialised AES256 GCM client->server MAC algorithm (in ETM mode) (required by cipher)
Trace:	Initialised AES-256 GCM server->client encryption
Trace:	Initialised AES256 GCM server->client MAC algorithm (in ETM mode) (required by cipher)
Trace:	Successfully loaded 1 key pair from file
Trace:	Offered public key from "C:\SFTP\key\private.ppk"  
Trace:	Server refused our key
Befehl:	Pass: 
Trace:	Sent password
Trace:	Password authentication failed
Fehler:	Authentifizierung fehlgeschlagen.
Trace:	CControlSocket::DoClose(1030)
Trace:	CControlSocket::ResetOperation(1094)
Trace:	CSftpDeleteOpData::Reset(1094) in state 3
Fehler:	Kritischer Fehler: Herstellen der Verbindung zum Server fehlgeschlagen
Trace:	CFileZillaEnginePrivate::ResetOperation(1094)
Mitglied: bloodstix
bloodstix 17.01.2019 um 15:11:33 Uhr
Goto Top
Offered public key from "C:\SFTP\key\private.ppk"  
Müsste das nicht auf eine public.ppk o.ä, zeigen? Immerhin soll der Public-Key geoffered werden und nicht der private.
Mitglied: Dennis93
Dennis93 17.01.2019 um 15:12:37 Uhr
Goto Top
Okay, es MUSS irgendein Berechtigungsproblem sein.
Ich habe etwas ausprobiert.

Habe folgendes getan:

chmod 0755 /home/username/.ssh
chmod 0755 /home/username/.ssh/authorized_keys
/etc/init.d/ssh restart

Anschließend funktioniert der Login mit Public & Private Key einwandfrei!

Komisch!
Mitglied: 129580
129580 17.01.2019 um 15:13:35 Uhr
Goto Top
Moin,

Nein ich meinte, wo der Key auf dem Windows-Rechner liegt.

das ist dann aber der private Key. face-wink

Wie genau mache ich das mit "-vvv"?

das geht nur mit dem OpenSSH-Client. Bei anderen SSH Clients musst du in den Einstellungen bzw. Dokumentation nachschauen, wo die das Log abspeichern.

Hier mal für WinSCP:
https://winscp.net/eng/docs/ui_pref_logging

Viele Grüße,
Exception
Mitglied: bloodstix
bloodstix 17.01.2019 um 15:14:17 Uhr
Goto Top
Ist ja auch nur logisch. Der SSH-Server läuft ja nicht als der Benutzer, als der du dich anmelden willst.
Wenn du dann wie im Eingangspost geschrieben "0700" gemacht hast, darf der Server da in die authorized_keys
gar nicht reinschauen.
DAS hätte aber aus dem Logfile am Server ersichtlich sein müssen!
Mitglied: Dennis93
Dennis93 17.01.2019 um 15:18:09 Uhr
Goto Top
Okay, also ist Berechtigung mit 755 richtig?

Dann wahrscheinlich nur noch eine kleine Frage.

Ich habe in der /etc/ssh/sshd_config Datei folgendes drinstehen:

Match User username
ChrootDirectory /home/username
ForceCommand internal-sftp

Nun sieht der User ja, wenn er sich mit WinSCP oder FileZilla einloggt folgende Dateien:
17-01-2019 15-17-32

Wie kann ich einstellen, dass er nur den Ordner "upload" sehen soll und auch nur dort drin etwas machen darf?
Mitglied: Dennis93
Dennis93 17.01.2019 um 15:23:09 Uhr
Goto Top
Wie kann ich einstellen, dass er nur den Ordner "upload" sehen soll und auch nur dort drin etwas machen darf?

Ich revidiere, erstellen und löschen kann der user dort nichts, er kann lediglich die Dateien sehen (und das auch nur im FileZilla, im WinSCP nicht). Also von mir aus eigentlich okay.
Mitglied: 137846
137846 17.01.2019 aktualisiert um 15:43:34 Uhr
Goto Top
Zitat von @bloodstix:

Ist ja auch nur logisch. Der SSH-Server läuft ja nicht als der Benutzer, als der du dich anmelden willst.
Wenn du dann wie im Eingangspost geschrieben "0700" gemacht hast, darf der Server da in die authorized_keys
gar nicht reinschauen.
Blödsinn!
Lesen: https://man.openbsd.org/sshd
~/.ssh/
    This directory is the default location for all user-specific configuration and authentication information. There is no general requirement to keep the entire contents of this directory secret, but the recommended permissions are read/write/execute for the user, and not accessible by others.

~/.ssh/authorized_keys
    Lists the public keys (DSA, ECDSA, Ed25519, RSA) that can be used for logging in as this user. The format of this file is described above. The content of the file is not highly sensitive, but the recommended permissions are read/write for the user, and not accessible by others.

    If this file, the ~/.ssh directory, or the user's home directory are writable by other users, then the file could be modified or replaced by unauthorized users. In this case, sshd will not allow it to be used unless the StrictModes option has been set to “no”.  
So ist es richtig:
chmod 700 /root/.ssh
chmod 600 /root/.ssh/authorized_keys
Besitzer checken.
Mitglied: Dennis93
Dennis93 17.01.2019 um 15:48:00 Uhr
Goto Top
Angelegt hatte ich den Benutzer und damit auch die Home-Ordner mit dem Benutzer "admin" bzw. mit su Befehl als root (gehe ich von aus?).

Muss ich dann den Besitzer ändern auf den User "username"? Wie genau mache ich das?
Mitglied: 137846
Lösung 137846 17.01.2019 aktualisiert um 15:56:13 Uhr
Goto Top
Zitat von @Dennis93:
Muss ich dann den Besitzer ändern auf den User "username"? Wie genau mache ich das?
Nur wenn du das .ssh Verzeichnis des Users auch mit Root angelegt hast, denn dann ist Root Besitzer von Ordner und file!
Ändern von Besitzern des dirs und des files machst du so:
chown username:username /home/username/.ssh/
chown username:username /home/username/.ssh/authorized_keys
Wenn du das ganze dagegen im Kontext des Users gemacht hast sind die Files schon im Besitz des jeweiligen Users, und du brauchst das Besitz übertragen nicht machen.

Ein ls -la oder ll zeigt dir die aktuellen Rechte und Besitzer.
Mitglied: 137846
137846 17.01.2019 aktualisiert um 15:59:01 Uhr
Goto Top
Und wo du dabei bist, einfach mal hier die Grundlagen anlesen! Dann sind auch solche "Rateaktionen" überflüssig.
https://en.wikibooks.org/wiki/OpenSSH/Cookbook/Public_Key_Authentication

Nur Anleitungen folgen ist zwar schön und gut, bringt dich aber ehrlich gesagt auf der Wissenbasis zum Thema keinen Schritt weiter. Gewisse Unix-Grundlagen sind einfach unverzichtbar.
Mitglied: Dennis93
Dennis93 17.01.2019 um 16:05:22 Uhr
Goto Top
So sieht es aktuell aus, also übertrage ich die Rechte auf den User und passe dann mit chmod die Berechtigung wieder dementsprechend an:
17-01-2019 16-04-03

Danke für die Hilfe @137846 !!

Ja, ich bin sonst zu 99,9% im Windows Umfeld aktiv, arbeite mich jetzt aber mal etwas mehr in die Marterie Linux ein.
Mitglied: 137846
137846 17.01.2019 aktualisiert um 16:15:14 Uhr
Goto Top
Noch als Hinweis wenn du mit chroot arbeitest, kann es je nach Pfad zur Situation kommen das der Pfad zur authorized_keys nicht mehr stimmt und du dann den Pfad in der sshd_config anpassen musst, weil dem User dann unter umständen der Zugriff auf die authorized_keys nicht mehr möglich ist wenn ein Pfad außerhalb des homes verpasst wird:
https://wiki.archlinux.org/index.php/SFTP_chroot
Dort den Hinweis unter Fixing path for authorized_keys lesen.
Mitglied: it-fraggle
it-fraggle 17.01.2019 um 17:45:07 Uhr
Goto Top
Der Klassiker. face-smile
Mitglied: the.other
the.other 17.01.2019 um 23:07:35 Uhr
Goto Top
moinsen,
ich habe auch lange rumgeschraubt damit...geholfen haben mir folgende Tips (und ja, die verfluchten Rechte sind für nicht linuxer oft ein Stolperstein...hier ist ja eigentlich schon alles, was die Rechte angeht, beantwortet)...trotzdem hier meine link-tips:

https://www.synology-wiki.de/index.php/Ssh_mit_Zertifikaten_absichern

https://forum.synology.com/enu/viewtopic.php?t=126166

https://wiki.ubuntuusers.de/chmod/

Zugegeben: bei den ersten beiden handelt es sich um Synology NAS Empfehlungen, die aber AFAIK generell wissenswert sind, der dritte link ist eher Basic-knowledge, was chmod angeht...

grüßle
th30ther
Mitglied: LordGurke
LordGurke 18.01.2019 aktualisiert um 00:05:32 Uhr
Goto Top
Um es nochmal zusammenzufassen:
Damit ein SSH-Key funktioniert müssen ALLE folgende Dinge erfüllt sein:
  • Der Key muss in ~/.ssh/authorized_keys des Benutzers hinterlegt sein
  • Die Datei authorized_keys muss dem Benutzer gehören, der sich mit dem Key einloggen soll (chown benutzername)
  • Die Datei authorized_keys darf nur vom Eigentümer verändert und gelesen werden (chmod 0600)
  • Das Verzeichnis ".ssh", in dem sich diese Datei befindet, darf nur vom Eigentümer geschrieben werden (chmod 0700)

Wenn du den Benutzer "geröllheimer" angelegt hast und dich als dieser Benutzer mit Key anmelden willst, muss dein Screenshot also aussehen:

Für das Verzeichnis ".ssh":
drwx------ 2 geröllheimer users 4096 Jan 17 15:45 .ssh

Für die darin liegende authorized_keys:
-rw------- 2 geröllheimer users 3,6k Jan 17 15:45 authorized_keys

Ist auch nur ein einziger der genannten Punkte nicht erfüllt, wird die authorized_keys aus Sicherheitsgründen ignoriert.
Denn wenn die Datei zum Beispiel aufgrund falscher Berechtigungen durch andere Benutzer des Systems verändert werden könnte, wäre das ein echtes Sicherheitsproblem (denn ein Nutzer könnte dadurch seinen Key hinterlegen und sich als der andere Nutzer anmelden) und das will man verhindern.