Datensicherung / scp ohne Passworteingabe

[ulipie]

Guten Morgen,
ich besitze eine DS212+ und eine DS214, beide mit der neuesten DSM-Version 5.x. Zur Datensicherung packe ich die relevanten Verzeichnisse auf beiden Geräten per Cron mit Zip und möchte die Archive auf die jeweils andere Maschine mit scp kopieren. Natürlich ohne Passworteingabe (nachts schlafe ich).
Dazu habe ich natürlich im Netz die verfügbaren Anleitungen gelesen und den RSA-Public-Key(ssh-keygen -t rsa) der anderen NAS (DS212 -> DS214 und umgekehrt) in ~/.ssh/autohorized_keys geschrieben (einiger Eintrag). In /etc/ssh/sshd_config habe ich die 3 relevanten Zeilen entkommentiert.

RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys

Gleichzeitig habe ich logging aktiviert
# Logging
# obsoletes QuietMode and FascistLogging
SyslogFacility AUTH
#LogLevel INFO
LogLevel DEBUG

Leider klappt das nur teilweise: Ich kann von DS212 nach 214 ohne Passworteingabe kopieren. Beim scp von DS214 nach DS212 wird ein Passwort verlangt. Der Aufruf von ssh auf der jeweils anderen NAS zeigt die gleichen Probleme.

Neben der allgemeinen Ratlosigkeit habe ich konkrete Fragen:
Wie kann ich das Logging wirksam einschalten und in genau welche Datei wird geloggt? Ich habe in /var/log/messages und /var/log/synolog keine ordentlichen Einträge gefunden.
Ich führe nachts das Sicherungsscript aus ( /bin/su -c "/usr/local/bin/backupDB.sh" sicherung). sicherung ist der User, dessen RSA-Key ich in authorized_keys geschrieben haben. Ist das so korrekt.
Könnt ihr euch per Ferndiagose vorstellen, was da falsch läuft?

Hinweis: vor dem Update auf eine vor etwa 2 Monaten aktuelle 4.x-Version hat das Ganze mit unveränderten Scripten funktioniert. Bei der Anlage hat mir damals jemand geholfen, auf den ich momentan nicht zurückgreifen kann. Nach dem Update auf DSM5.x habe ich die Keys und authorized_key neu erzeugt. Die Rechte 700 auf .ssh und 640 auf authorized_keys habe ich gesetzt.

Bin für jede Hilfe dankbar und kann natürlich weiter Infos liefern.

Uli

 

[Ameisentaetowierer]

1. prüfe, ob die Rechte für .ssh auf 700 stehen
2. prüfe, ob die Rechte für authorized_keys auf 600 stehen
3. als User root kannst du normalerweise einen zweiten sshd starten, wenn du beim Aufruf einen anderen Port vorgibst und am besten gleich den sshd im Vordergrund laufen lässt. Dazu noch Debugging einschalten und dann gehts...

Das sieht dann ungefähr so aus.
Das Beispiel ist von einem Linuxrechner, der Pfad für sshd ist bei der Syno uU anders...

/usr/sbin/sshd -p 22222 -Dd
debug1: sshd version OpenSSH_4.1p1
debug1: private host key: #0 type 0 RSA1
debug1: read PEM private key done: type RSA
debug1: private host key: #1 type 1 RSA
debug1: read PEM private key done: type DSA
debug1: private host key: #2 type 2 DSA
debug1: rexec_argv[0]='/usr/sbin/sshd'
debug1: rexec_argv[1]='-p'
debug1: rexec_argv[2]='22222'
debug1: rexec_argv[3]='-Dd'
debug1: Bind to port 22222 on ::.
getnameinfo failed
Server listening on :: port 22222.
debug1: Bind to port 22222 on 0.0.0.0.
Bind to port 22222 on 0.0.0.0 failed: Address already in use.
Generating 768 bit RSA key.
RSA key generation complete.
debug1: Server will not fork when running in debugging mode.
debug1: rexec start in 4 out 4 newsock 4 pipe -1 sock 7
debug1: inetd sockets after dupping: 3, 3

---- Hier kommt jetzt ein Client und will sich am sshd anmelden

Connection from 127.0.0.1 port 41992
debug1: Client protocol version 2.0; client software version OpenSSH_4.1
debug1: match: OpenSSH_4.1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-1.99-OpenSSH_4.1
debug1: permanently_set_uid: 71/65
debug1: list_hostkey_types: ssh-rsa,ssh-dss
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received
debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT
debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
Connection closed by 127.0.0.1
debug1: do_cleanup
debug1: PAM: cleanup
debug1: do_cleanup
debug1: PAM: cleanup

 

[ulipie]

Hallo,
danke für die schnelle Antwort. Die Rechte sind auf beiden Systemen gleich 700 für .ssh und 640 auf auto.. Ich habe von auf dem nichtfunktionieren Remotesystem (ds212) testweise 600 auf autho.. eingestellt und den sshd neu gestartet. Keine Änderung.

Deine Hinweise zum Loggin und Starten eines weiteren sshd verstehe ich fachlich leider nicht, bin trotz meines Alters zu jung in dem Theam. Wohin logged denn der sshd und ist die configdatei /etc/ssh/sshd_config die richtige?
danke

 

[ulipie]

Hallo Ameisentätowierer,
danke für deine Hilfe. Ich habe das Problem gelöst:

Es reicht nicht, die Rechte für das Verzeichnis .ssh auf 700 und die Datei auth... auf 600 oder 640 zu setzten. Vielmehr muss auch das Recht auf das Userverzeichnis auf 755 stehen. Ich hatte weitreichendere Recht. Nach dem chmod auf 755 für das user-Verzeichnis hat alles geklappt.

Dadurch ist natürlich mein Wunsch, die LogLevel für sshd zu erhöhen, immer noch nicht gelöst. Das hat jetzt aber keine hohe Prio mehr.

Danke UliPie

 

[Ameisentaetowierer]

Das mit dem Loglevel wird dich nicht weiterbringen, wenn du nicht erkennst, dass ein Log vor dir steht

Das, was du da oben siehst, ist das Logging, es wird einfach auf den Bildschirm geschrieben.
Ich habe das jetzt nochmal synogerecht gemacht, der korrekte Befehl (als root) lautet:
"/usr/syno/sbin/sshd -p 22222 -Dd"

Dabei steht "-p 22222" für "Port 22222" (statt normalerweise Port 22)
"-D" steht für "Do not detach", also läuft der sshd im Vordergrund und du kannst ihn mit CTRL-C beenden
"-d" steht für "debug" und schreibt die ganzen Meldungen raus, die du da oben siehst

Du musst dann nur bei Putty den Port 22222 angeben, um dich mit diesem sshd zu verbinden.

Ich habe gerade mal das Home von admin auf 777 gesetzt und den ssh wie oben beschrieben gestartet.
Im Debug steht dann auch:

---->
debug1: trying public key file /var/services/homes/admin/.ssh/authorized_keys
debug1: fd 5 clearing O_NONBLOCK
Authentication refused: bad ownership or modes for directory /volume1/homes/admin
<-----

Komischerweise sind aber die Rechte für .ssh und authorized_keys nicht so wichtig.
Ich habe das gerade auch mal ausprobiert.
Aus Erfahrung mit anderen Unixen bin ich mir aber ziemlich sicher, dass das nicht normal ist...seltsam.

 

[ulipie]

Vielen Dank für deine Mühe!!!!!!!!
Ich habe schon verstanden, dass du mir ein Logschnippsel kopiert hast. Mein Wunsch wäre nur, Logeinträge wie in deinem Beispiel von gerade, in meiner Umgebung zu sehen.

Das mit dem zweiten sshd habe ich nun verstanden und würde es beim nächsten Mal so machen.
Danke
UliPie