Rsync über ssh Problem

Simon_Martinelli · 7. November 2019 um 16:27

Hallo zusammen,

Ich versuche mittels rsync und ssh Daten zwischen 2 Servern zu synchronisieren. Ich habe das schon mal gemacht, leider habe ich jetzt aber die Anleitung die zum Ziel führte nicht mehr griffbereit.

Habe die Keys generier und auf den Slave kopiert inkl. anfügen in authorized_keys

Wenn ich ssh user@master eingegeben habe kam auch die Abfrage und es hat einen Eintrag in known_hosts erstellt.

Wenn ich aber jetzt wieder ssh user@master eingeben kommt trotzdem immer eine Passwortabfrage. Leider auch bei rsync (welches tiptop funktioniert.

Was habe ich falsch gemacht?

Vielen Dank und Gruss
Simon

Malte_4b1c84 · 7. November 2019 um 16:27

Hi,

Habe die Keys generier und auf den Slave kopiert inkl. anfügen
in authorized_keys

Hast Du auch die authorized_keys im Home-Dir von $USER benutzt?
Wie sieht Deine sshd_config aus?

Wenn ich aber jetzt wieder ssh user@master eingeben kommt
trotzdem immer eine Passwortabfrage. Leider auch bei rsync

Gruß,

Malte.

Simon_Martinelli · 7. November 2019 um 16:27

Hast Du auch die authorized_keys im Home-Dir von $USER
benutzt?

Ja.

Wie sieht Deine sshd_config aus?

Port 22
ListenAddress 0.0.0.0
HostKey /etc/ssh_host_key
RandomSeed /etc/ssh_random_seed
ServerKeyBits 768
LoginGraceTime 600
KeyRegenerationInterval 3600
PermitRootLogin yes
IgnoreRhosts no
StrictModes yes
QuietMode no
X11Forwarding yes
X11DisplayOffset 10
FascistLogging no
PrintMotd yes
KeepAlive yes
SyslogFacility DAEMON
RhostsAuthentication no
RhostsRSAAuthentication yes
RSAAuthentication yes
PasswordAuthentication yes
PermitEmptyPasswords yes
UseLogin no

Malte_4b1c84 · 7. November 2019 um 16:27

Hi,

das müssten eigentlich die default Einstellungen sein, aber wer weiß, wie das auf Deinem System aussieht, deshalb probier mal folgende Zeilen zusätzlich:

RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized\_keys

Gruß,

Malte.

Simon_Martinelli · 7. November 2019 um 16:28

Hallo Malte,

Schon mal vielen Dank für Deine Hilfe.
Das hat aber leider auch nichts gebracht.

Viele Grüsse aus der Schweiz
Simon

Sebastian · 7. November 2019 um 16:28

Hallo,

Habe die Keys generier und auf den Slave kopiert inkl. anfügen
in authorized_keys

Was hast Du genau wo angefügt?

Ansonsten: „machmal“ wird der key auch in ~/.ssh/authorized_keys2 geschuct. Einfach mal einen Link anlegen.

Leider auch bei rsync

Ja. Erstmal SSH reparieren.

Gruß,

Sebastian

Stefan_Schustereit · 7. November 2019 um 16:28

Wenn ich aber jetzt wieder ssh user@master eingeben kommt
trotzdem immer eine Passwortabfrage. Leider auch bei rsync
(welches tiptop funktioniert.

Versuchs mal mit ssh -v user@master und ssh -vv user@master. Das gibt direkt ein Log aus. Bitte überprüfe auch, ob /home/user auf master die richtigen Rechte hat - ich hatte mal das Problem, dass die Authentifizierung per Keys nur dann ging, wenn das Homeverzeichnis des Users auf der Zielmaschine nur für den User zu lesen war und nicht für die Gruppe (chmod 700 /home/user).

Stefan

Simon_Martinelli · 7. November 2019 um 16:28

authorized_keys scheint in Ordnung zu sein.
Angefügt: cat xy.idendity.pub > authorized_keys

Simon_Martinelli · 7. November 2019 um 16:28

Hallo Stefan,

Das sieht dann so aus:

OpenSSH\_3.5p1, SSH protocols 1.5/2.0, OpenSSL 0x0090609f
16789: debug1: Reading configuration data /etc/ssh/ssh\_config
16789: debug1: Applying options for \*
16789: debug1: Rhosts Authentication disabled, originating port will not be trusted.
16789: debug1: ssh\_connect: needpriv 0
16789: debug1: Connecting to master [192.168.1.101] port 22.
16789: debug1: Connection established.
16789: debug1: identity file /root/.ssh/identity type -1
16789: debug1: identity file /root/.ssh/id\_rsa type -1
16789: debug1: identity file /root/.ssh/id\_dsa type -1
16789: debug1: Remote protocol version 1.5, remote software version 1.2.26
16789: debug1: match: 1.2.26 pat 1.2.1\*,1.2.2\*,1.2.3\*
16789: debug1: Local version string SSH-1.5-OpenSSH\_3.5p1
16789: debug1: Waiting for server public key.
16789: debug1: Received server public key (768 bits) and host key (1024 bits).
16789: debug1: Host 'master' is known and matches the RSA1 host key.
16789: debug1: Found key in /root/.ssh/known\_hosts:3
16789: debug1: Encryption type: 3des
16789: debug1: Sent encrypted session key.
16789: debug1: cipher\_init: set keylen (16 -\> 32)
16789: debug1: cipher\_init: set keylen (16 -\> 32)
16789: debug1: Installing crc compensation attack detector.
16789: debug1: Received encrypted confirmation.
16789: debug1: Doing password authentication.
user@master's password:

Sieht doch alles gut aus, oder?
Warum kommt dann die Passwortabfrage?

Gruss, Simon

Malte_4b1c84 · 7. November 2019 um 16:28

Hi,

offenbar steht Public Key-AUTH in der Reihenfolge hinter der Passwort-AUTH. Bei mir sieht entsprechendes so aus:

[docvalde@sharra /usr/home/docvalde]$ ssh -v docvalde@lilith
OpenSSH\_3.6.1p1 FreeBSD-20030924, SSH protocols 1.5/2.0, OpenSSL 0x0090703f
debug1: Reading configuration data /etc/ssh/ssh\_config
debug1: Rhosts Authentication disabled, originating port will not be trusted.
debug1: Connecting to lilith.docvalde.local [192.168.0.1] port 22.
debug1: Connection established.
debug1: identity file /home/docvalde/.ssh/identity type -1
debug1: identity file /home/docvalde/.ssh/id\_rsa type 1
debug1: identity file /home/docvalde/.ssh/id\_dsa type -1
debug1: Remote protocol version 1.99, remote software version OpenSSH\_3.6.1p1 FreeBSD-20030924
debug1: match: OpenSSH\_3.6.1p1 FreeBSD-20030924 pat OpenSSH\*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH\_3.6.1p1 FreeBSD-20030924
debug1: SSH2\_MSG\_KEXINIT sent
debug1: SSH2\_MSG\_KEXINIT received
debug1: kex: server-\>client aes128-cbc hmac-md5 none
debug1: kex: client-\>server aes128-cbc hmac-md5 none
debug1: SSH2\_MSG\_KEX\_DH\_GEX\_REQUEST sent
debug1: expecting SSH2\_MSG\_KEX\_DH\_GEX\_GROUP
debug1: SSH2\_MSG\_KEX\_DH\_GEX\_INIT sent
debug1: expecting SSH2\_MSG\_KEX\_DH\_GEX\_REPLY
debug1: Host 'lilith.docvalde.local' is known and matches the DSA host key.
debug1: Found key in /home/docvalde/.ssh/known\_hosts:2
debug1: ssh\_dss\_verify: signature correct
debug1: SSH2\_MSG\_NEWKEYS sent
debug1: expecting SSH2\_MSG\_NEWKEYS
debug1: SSH2\_MSG\_NEWKEYS received
debug1: SSH2\_MSG\_SERVICE\_REQUEST sent
debug1: SSH2\_MSG\_SERVICE\_ACCEPT received
**debug1: Authentications that can continue: publickey,password,keyboard-interactive  
debug1: Next authentication method: publickey  
debug1: Trying private key: /home/docvalde/.ssh/identity  
debug1: Offering public key: /home/docvalde/.ssh/id\_rsa  
debug1: Server accepts key: pkalg ssh-rsa blen 277 lastkey 0x806b250 hint 1  
debug1: read PEM private key done: type RSA  
debug1: Authentication succeeded (publickey).**  
debug1: channel 0: new [client-session]
debug1: Entering interactive session.
debug1: channel 0: request pty-req
debug1: channel 0: request shell
debug1: channel 0: open confirm rwindow 0 rmax 32768
Last login: Wed Feb 25 18:37:11 2004 from sharra.docvalde
Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994
 The Regents of the University of California. All rights reserved.
 
FreeBSD 5.2.1-RC2 (LILITH) #2: Sat Feb 21 19:57:51 CET 2004
 
\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*
\* \*
\* Welcome on lilith.docvalde.local \*
\* \*
\* This system is running FreeBSD 5.2 \*
\* \*
\* Available services are: \*
\* \*
\* ssh http ftp \*
\* \*
\* Use them wisely! \*
\* \*
\* In case of emergency, mailto:[email protected] \*
\* \*
\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*
[docvalde@lilith ~]$

Du siehst den Unterschied?

WARUM das so ist, kann ich grad nicht sagen, ich schau aber vielleicht noch mal weiter…

Gruß,

Malte.

Sebastian · 7. November 2019 um 16:28

authorized_keys scheint in Ordnung zu sein.

Sagt Dir was genau?

Angefügt: cat xy.idendity.pub > authorized_keys

Auf dem gleichen Rechner? Dan wird das nix.

Naja, so sehr, wie Du Dir die Fakten aus der Nase ziehen läßt, ist es sowieso eher öde, sich für Dich zu verrenken.

Tschüß,

Sebastian

Malte_4b1c84 · 7. November 2019 um 16:28

Ich glaub, ich hab’s…
Hi,

> 16789: debug1: Remote **protocol version 1.5** , remote software version 1.2.26

Sieht doch alles gut aus, oder?

Geht so. Ich zitiere:

$ man sshd\_config
(...)
 PubkeyAuthentication
 Specifies whether public key authentication is allowed. The
 default is ``yes''. **Note that this option applies to protocol  
 version 2 only.**

Aaaaaaha! Füge mal in der sshd_config folgende Zeile hinzu:

Protocol 2

Damit schaltest Du Protokoll-Version 1.x aus. Die Entscheidung, welches gewählt wird, wenn v1 und v2 zur Verfügung stehen, trifft der Client - Du kannst das manuell ausprobieren mittels

$ ssh -2 user@host

Gruß,

Malte.

Simon_Martinelli · 7. November 2019 um 16:28

Hey Malte,

Genau das war’s!
Leider geht’s nicht aber jetzt weiss ich wieder wo das Problem liegt!

Ich habe ein Suse Linux 8.1 mit:
OpenSSH_3.5p1, SSH protocols 1.5/2.0, OpenSSL 0x0090609f

Und ein PowerBSD mit:
SSH Version 1.2.26 [i386-unknown-freebsd3.0], protocol version 1.5.

D.h. der Rechner mit PowerBSD kann kein 2.0!

Nun müsste ich nur rausfinden, wie der das trotzdem könnte, denn leider kann ich keine andere SSH Version installieren.

Gruss und schon mal vielen Dank.
Simon

Malte_4b1c84 · 7. November 2019 um 16:29

Für’s nächste Mal…
Hallo,

Ich habe ein Suse Linux 8.1 mit:
OpenSSH_3.5p1, SSH protocols 1.5/2.0, OpenSSL 0x0090609f

Und ein PowerBSD mit:
SSH Version 1.2.26 [i386-unknown-freebsd3.0], protocol version
1.5.

Es wäre sicher sehr hilfreich gewesen, wenn Du uns das gleich erzählt hättest - unsere Glaskugeln haben sich darüber nämlich ausgeschwiegen. Generell ist es sinnvoll, bei solchen Problemen

die verwendeten Betriebssysteme (uname -a)
die betroffenen Softwareversionen (meist command --version oder -V)
die betr. Config-Dateien

mit anzugeben. Bzgl. Deines Problems kann ich Dir leider nicht weiterhelfen. Und was ist eigentlich PowerBSD?

Gruß,

Malte.

Simon_Martinelli · 7. November 2019 um 16:29

Hallo Malte,

Es tut mir leid, dass ich das nicht von Anfgang an gesagt habe.
Ich war der Meinung, dass ich die selben SSH-Versionen verwende.
Aber das war bei zwei andern Rechner.

Und was ist eigentlich PowerBSD?

Das ist ein BSD-Derivat das in den USA sehr häufig für VirtualHosting eingesetzt wird. Man kann damit einfach auf einer Maschine mehrere Instanzen laufen lassen.

Gruss, Simon