☰

rsync: Berechtigung verweigert (öffentlicher Schlüssel) mit SSH

tag-icon • tag-icon linux ssh permissions rsync cron
rsync: Berechtigung verweigert (öffentlicher Schlüssel) mit SSH

Ich habe einen Server, mit dem ich mich per SSH mit meinen Schlüsseldateien verbinde, z. B. id_rsa.pub. Ich verwende Debian auf der Client- und Serverseite.

Ich habe ein Tutorial befolgt, um die Root-Authentifizierung und die Kennwortverwendung für mehr Sicherheit zu deaktivieren (durch Konfigurieren der /etc/ssh/sshd/sshd_configDatei auf dem Server).

Bisher konnte ich rsyncmeine Dateien problemlos von meinem Computer mit dem Server synchronisieren.

Vor ein paar Tagen, Ich habe einen Cron-Job verwendetJob und dafür musste ich mein Root-Passwort auf der Serverseite zurücksetzen.

Seitdem ist mir die Nutzung von nicht mehr möglich rsync, SSHich erhalte folgende Meldung:

[email protected]: Permission denied (publickey).
rsync: connection unexpectedly closed (0 bytes received so far)[sender]
rsync error: unexplained error (code 255) at io.c(235)[sender=3.1.3]

Es gibt einige ähnliche Themen, aber ich denke, mein Fall ist etwas anders, weil ich denke, das Problem liegt daran, dass mein Passwort auf dem Server zurückgesetzt wurde. Ich habe auch eine Frage auf der Ask Ubuntu-Site gestellt, aber ich denke, dass die Leute hier vielleicht mehr Experten in Berechtigungsfragen sind.

Ich habe keine Ahnung, wie ich das Problem beheben kann (ich komme ein bisschen mit Terminalbefehlen klar, bin aber kein Computerexperte). Können Sie mir bitte helfen?

Nur zu Ihrer Information: Hier ist das Tutorial zum Deaktivieren des /etc/ssh/sshd_configKennworts:

#Uncomment or add the following line. 
#This allows the server to give its DSA footprint in case of an ssh connection.
HostKey /etc/ssh/ssh/ssh_host_dsa_key

#Then set the next parameter to 20s (for example). 
#This is the time during which a connection without being logged in will be opened. 
#If we had kept the good old password technique, leave 2 or 3 minutes to type it, it's not too much. 
#But since we're using the key now, we'll be logged in immediately. #So we can really reduce the thing and put it down to 20 seconds for example.
LoginGraceTime 20s

#this is the maximum number of attempts before being thrown by the server.... 
#Since with the key, no possible error, you can put it to 1 possible test.
MaxAuthTries 1

#Then, we will tell the SSH server where the keys are and tell it that we will use them as an authentication method
PubkeyAuthentication yes
AuthorizedKeysFile.ssh/authorized_keys

#And of course, we'll disable all other authentication methods
RSAAuthentication no.
UsePAM no
KerberosAuthentication no
GSSAPIA Authentication no.
PasswordAuthentication no

#Then, we will tell that we only allow users of the sshusers group (for more security)
AllowGroups sshusers

#The MaxStartups setting indicates the number of un-authenticated ssh connections you can launch at the same time. 
#2 is more than enough, knowing that with the keys, it's instantaneous.
MaxStartups 2

Antwort1

Ach nein!

Ich habe gerade die Lösung gefunden ... Mein Befehl war:

sudo rsync -avz -e "ssh -p <port>" <source> <destination>

Aber ich musste es einfach machen (ohne sudo):

rsync -avz -e "ssh -p <port>" <source> <destination>

Ich bin mir über die Ursache nicht sicher, aber ich glaube, dass der rootBenutzer meines Desktop-Computers nicht per SSH auf meinen Server zugreifen durfte, da der Schlüssel nur für meinen classicDesktop-Benutzer (also ohne sudo) war.

Kann das bitte jemand bestätigen? Danke.

verwandte Informationen