rsnapshot mit ssh ohne Password scheitert

[goetz]

mach das, mein englisch ist zumindest beim schreiben/reden mächtig eingerostet.

Götz

 

[wired2051]

ja so sollte es sein. Ich hab das mal geprüft und mit einer einfachen Nutzeranmeldung zeigt ~ nach /root, bB->böser Bug.

Erst so kurz Besitzer einer DS und schon einen fiesen Bug entdeckt. Aber der lässt sich ja recht leicht umgehen (ich bevorzuge sowieso immer ganze Pfade) Auf jeden Fall Danke für den Hinweis!

Leider komme ich dennoch noch nicht ganz ans Ziel: wenn ich die Verbindung von DS auf den PC testen will, werde ich ohne weitere Meldungen aufgefordert das PW von user einzugeben. Wenn das richtig ist, komme ich scheinbar auch via ssh auf den PC.

Das ist das Ergebnis in /var/log/auth.log auf dem PC beim Test:

ssh -i /volume2/homes/user/.ssh/id_rsa_DSPC user@IP_DES_PC
May 1 21:25:57 Rechner sshd[9118]: Accepted password for user from IP_DER_DS port 54471 ssh2
May 1 21:25:57 Rechner sshd[9124]: pam_unix(sshd:session): session opened for user user by (uid=0)
May 1 21:25:57 Rechner sshd[9124]: pam_env(sshd:setcred): Unable to open env file: /etc/default/locale: No such file or directory

Das ist das Ergebnis in /var/log/auth.log auf dem PC beim Ende der Verbindung:

exit
May 1 21:26:37 Rechner sshd[9124]: Received disconnect from IP_DER_DS: 11: disconnected by user
May 1 21:26:37 Rechner sshd[9124]: pam_env(sshd:setcred): Unable to open env file: /etc/default/locale: No such file or directory
May 1 21:26:37 Rechner sshd[9124]: pam_unix(sshd:session): session closed for user user

Auf dem PC in /etc/default ist tatsächlich keine Datei namens locale.

Es ist übrigens egal, ob ich die IP_DES_PC oder den NAMEN_DES_PC verwende.


Übrigens: die Verbindung von PC zu DS funktioniert zwar mit ssh -i id_rsa_PCDS user@IP_DER_DS müsste sie nicht aber auch mit ssh user@IP_DER_DS funktionieren? Tut sie aber nicht, ich werde auch hier nach den PW von user gefragt, erst dann geht's...

 

[jahlives]

Aber der lässt sich ja recht leicht umgehen (ich bevorzuge sowieso immer ganze Pfade) Auf jeden Fall Danke für den Hinweis!

Es gibt aber Programme z.B. ssh, die in ihren Configs ebenfalls ~ verwenden. Diese fallen auf der DS alle auch auf die Schnauze. Du wirst dich also nicht mittels Zertifikat als non-root Users auf der DS beim ssh anmelden können.
Ich habe das an Syno gemailt mit der Bitte das schnellstmöglich zu fixen. Sollte wirklich nicht sein, dass alle User nach /root gemappt werden

Übrigens: die Verbindung von PC zu DS funktioniert zwar mit ssh -i id_rsa_PCDS user@IP_DER_DS müsste sie nicht aber auch mit ssh user@IP_DER_DS funktionieren? Tut sie aber nicht, ich werde auch hier nach den PW von user gefragt, erst dann geht's...

Finde ich ehrlich gesagt komisch, dass die Verbindung als non-root user mittels Zertifikat funzt. Denn eigentlich müsste der ssh auf der DS nach ~/.ssh/authorized_keys suchen. Damit sollte die DS aber versuchen auf auth_keys von root zuzugreifen. Hast du geprüft, dass du wirklich user und nicht doch root bist?

whoami

ergibt das wirklich user und nicht root?

Wenn du das Schlüsselfile nicht mit -i angibst, dann wird ssh immer eine Anmeldung mit PW versuchen und dieses muss ssh erst von dir abfragen. Daher die PW-Abfrage

 

[itari]

Zur Tilden~Diskussion:

Synology> egrep '(root|admin)' /etc/passwd
root:x:0:0:root:/root:/bin/ash
admin:x:1024:100:System default user:/var/services/homes/admin:/bin/sh
Synology> id
uid=0(root) gid=0(root)
Synology> echo ~
/root
Synology> su admin


BusyBox v1.1.0 (2010.04.19-13:36+0000) Built-in shell (ash)
Enter 'help' for a list of built-in commands.

$ id
uid=1024(admin) gid=100(users)
$ echo ~
/var/services/homes/admin

Itari

 

[wired2051]

Um nicht durcheinander zu kommen: Die ssh-Verbindung von PC auf DS funktioniert. Folgende Änderungen habe ich dafür gemacht:

auf DS: authorized_keys enthält id_rsa_PCDS.pub mit NAME_DES_PC
auf PC: id_rsa_PCDS ertellt
auf PC: known_hosts erstellen lassen

Nicht funktionieren tut die ssh-Verbindung von DS auf PC. Dafür habe ich folgende Änderungen vorgenommen:

auf PC: authorized_keys enthält id_rsa_DSPC.pub mit IP_DER_DS
auf DS: id_rsa_DSPC erstellt
auf DS: known_hosts erstellen lassen

Warum?

Finde ich ehrlich gesagt komisch, dass die Verbindung als non-root user mittels Zertifikat funzt. Denn eigentlich müsste der ssh auf der DS nach ~/.ssh/authorized_keys suchen. Damit sollte die DS aber versuchen auf auth_keys von root zuzugreifen. Hast du geprüft, dass du wirklich user und nicht doch root bist?

In Anbetracht des Bugs stimmt das eigentlich (die Ausführungen von itari verstehe ich nicht richtig). Ich habe mich also noch einmal vom PC auf der DS angemeldet mit ssh -i id_rsa_PCDS user@IP_DER_DS und whoami ergab: user und ich landete auch im home-Verzeichnis von user. Das .ssh im home-Verzeichnis von root ist übrigens leer.

 

[jahlives]

@itari
Bei mir wird auch admin nach /root gemappt

webserver> id
uid=1024(admin) gid=100(users) groups=100(users)
webserver> echo ~
/root

und dies obwohl admin ein anderes Homeverzeichnis in /etc/passwd hat

webserver> cat /etc/passwd | grep admin
admin:x:1024:100:System default user:/var/services/homes/admin:/bin/sh

 

[wired2051]

Kann mit niemand sagen, was mir diese Meldung aus /var/log/auth.log auf dem PC sagen will?

May 2 15:18:48 Rechner sshd[19731]: Accepted password for user from IP_DER_DS port 46338 ssh2
May 2 15:18:48 Rechner sshd[19738]: pam_unix(sshd:session): session opened for user user by (uid=0)
May 2 15:18:48 Rechner sshd[19738]: pam_env(sshd:setcred): Unable to open env file: /etc/default/locale: No such file or directory

Sie wird eingetragen, wenn ich mit ssh -i /volume2/homes/user/.ssh/id_rsa_DSPC user@IP_DES_PC mich via ssh von der DS auf dem PC anmelden will... Warum muss ich immer wieder das PW von user angeben?

 

[itari]

@itari
Bei mir wird auch admin nach /root gemappt

webserver> id
uid=1024(admin) gid=100(users) groups=100(users)
webserver> echo ~
/root

und dies obwohl admin ein anderes Homeverzeichnis in /etc/passwd hat

webserver> cat /etc/passwd | grep admin
admin:x:1024:100:System default user:/var/services/homes/admin:/bin/sh

Wahrscheinlich hast du auf deiner DS was gemoddet

Ich wollte mit meinem Beispiel nur zeigen, dass ich im Moment kein Problem mit der Tilde hab ... wo auch immer die Unterschiede herkommen, sie sind nicht ganz so einfach zu verallgemeinern.

Itari

 

[jahlives]

Ich wollte mit meinem Beispiel nur zeigen, dass ich im Moment kein Problem mit der Tilde hab ... wo auch immer die Unterschiede herkommen, sie sind nicht ganz so einfach zu verallgemeinern.

Itari

@itari
Es scheint nur so zu gehen wie du geschrieben hast, wenn man su benutzt. Bei einer direkten Anmeldung als admin führt echo ~ zu /root
Mein "Mod" ist also su ned zu benutzen
Hab's gerade getestet mit su ist ~ korrekt, bei direkter Anmeldung als admin an der Shell ist der Pfad falsch.

 

[goetz]

Hallo,
@jahlives
genau so ist es, kann ich genau so nachvollziehen, per su ist es OK, per user-login nicht.

Gruß Götz

 

[itari]

Hab's gerade getestet mit su ist ~ korrekt, bei direkter Anmeldung als admin an der Shell ist der Pfad falsch.

Kann ich nachvollziehen, ist bei mir auch so. Selbst wenn du das Home-Dir vom root änderst, ist das Verhalten bei root-Login so, dass die ~ auf /root weist. Hat jemand die bash als Login-Shell? Ist das da auch so?

Itari

 

[jahlives]

Kann ich nachvollziehen, ist bei mir auch so. Selbst wenn du das Home-Dir vom root änderst, ist das Verhalten bei root-Login so, dass die ~ auf /root weist. Hat jemand die bash als Login-Shell? Ist das da auch so?

Itari

Habs gerade mit meinem Root probiert, der hat bei mir die bash. Dazu habe ich das Home auf /home/root gesetzt. Nach dem Anmelden sieht das so aus

webserver> cat /etc/passwd | grep root
root:x:0:0:root:/home/root:/opt/bin/bash
webserver> pwd
/home/root
webserver> echo ~
/root

Ich hab das mal an Synology gemeldet, mal gucken was die dazu meinen. Aber für mich ist das schon ein Bug und kein Feature

Gruss

tobi