Hallo Thorsten, hallo Leute, Am Sonntag, 26. Dezember 2004 15:57 schrieb Dr. Thorsten Brandau:

...

Warum nicht per ssh und hinterlegtem key?

weils nicht geht.

ich hatte frueher keinerlei probleme mit Suse <9.1 mit ssh ohne passwort zuzugreifen (schluessel angelegt, authorized_keys etc. etc.). seit die server auf 9.1 laufen geht das nicht mehr. ich habe das schon mehrfach hier gepostet, aber alles was als antwort kommt ist das was sowieso in jeder howto steht. ich habe mittlerweile alles versucht von schluessel neu anlegen, jegliche einstellungen der sshd_config und ssh_config zu manipulieren und sshd zu erneuern.

Zeigst Du mal das Ergebnis von grep "^[^#]" /etc/ssh/sshd_config her? Vielleicht ist ja irgendwo die Konfiguration defekt. Außerdem wäre ein Loginversuch mit SSH-Key interessant - probier das bitte mal mit ssh -vv user@suse91 ("user@suse91" entsprechend anpassen). BTW: Ich habe gerade etwas getestet und mich erfolgreich von SuSE 9.2 auf eine 9.0 (mein Server) und von dort "zurück" auf die 9.2 unter Verwendung meines SSH-Keys einloggen können. Login auf SuSE 9.1 geht mit dem SSH-Key auch, sonst hätte ich gewisse Schwierigkeiten bei Wartungsarbeiten für die FAQ ;-) Das Ganze ist also kein generelles Problem bei der 9.[12].

leider keinerlei erfolg. mir scheint, das suse damit gewaltigen mist gebaut hat. wohlgemerkt: wenn ich aus demselben homeverzeichnis aus von irgenwelchen linux rechnern auf irgendwelche anderen mit suse <9.1 gehe, gibt es keinerlei probleme. von 9.1 auf 9.1 gehts auch nicht. auch nicht mit cygwin/w32 oder putty auf den server - wohl aber an aeltere suse linuxsysteme. es ist einfach zum kotzen.

Der Hinweis auf die Protokollversion kam ja schon, auch das wäre eine Möglichkeit.

leider hatte ich alle meine backupscripte über -e ssh aufgebaut. da das nicht mehr funktioniert, will ich den eh vorhandenen VPN tunnel nutzen und die daten halt unverschluesselt rueberschicken...

danker brauche ich aber rsyncd auf der einen seite und rsync auf der anderen. und das ohne passwortabfrage.

Alternativ: per NFS mounten und "lokal" rsyncen (oder bei der Gelegenheit gleich auf StoreBackup umstellen ;-) siehe dazu 5.3. Storebackup: Backup auf Festplatte http://suse-linux-faq.koehntopp.de/q/q-backup-storebackup.html Frohe Weihnachten! Christian Boltz --

if ( ! ifdef $root ) { [...] } ifdef? Da hat einer zusammengerollte Makefiles geraucht... [> Christian Boltz und Ratti in fontlinge-devel]

Hallo Thorsten, hallo Leute, Am Montag, 27. Dezember 2004 09:10 schrieb Dr. Thorsten Brandau:

...

Zeigst Du mal das Ergebnis von grep "^[^#]" /etc/ssh/sshd_config her? Vielleicht ist ja irgendwo die Konfiguration defekt.

vorweg: Du hast im Vergleich zu meiner Config sehr viele Einträge. Ich kommentiere es mal durch:

Port 22 Protocol 2,1 HostKey /etc/ssh/ssh_host_key HostKey /etc/ssh/ssh_host_rsa_key HostKey /etc/ssh/ssh_host_dsa_key KeyRegenerationInterval 3600

Soweit default.

ServerKeyBits 1536

Default scheint 768 zu sein.

SyslogFacility AUTH

Default.

LogLevel DEBUG3

Default ist wohl INFO.

LoginGraceTime 2m

Default.

PermitRootLogin no

Default ist "yes", aber auch mit "no" funktioniert der Login per SSH-Key (nur root-Logins gehen natürlich nicht ;-)

RSAAuthentication yes PubkeyAuthentication yes

Default.

AuthorizedKeysFile %h/.ssh/authorized_keys

Bei mir steht da als Default-Value einfach nur .ssh/authorized_keys - also ohne das %h/ davor. Teste das mal (oder kommentiere die Zeile aus)

RhostsRSAAuthentication no HostbasedAuthentication no IgnoreUserKnownHosts no IgnoreRhosts yes

Soweit Default.

PasswordAuthentication yes

Steht bei mir auf no, yes dürfte aber Default sein.

UsePAM yes

BTW: Solange UsePAM aktiv ist, geht auch Login mit Passwort.

X11Forwarding yes

Ist bei mir auch an - ich weiß aber nicht, was Default ist.

X11DisplayOffset 10 X11UseLocalhost yes PrintMotd yes PrintLastLog yes TCPKeepAlive yes UsePrivilegeSeparation yes Compression yes ClientAliveInterval 0 ClientAliveCountMax 3 UseDNS yes PidFile /var/run/sshd.pid MaxStartups 10

Soweit alles Default.

Subsystem sftp /usr/lib/ssh/sftp-server

Steht bei mir auch drin. Gegenprobe: # grep "^[^#]" sshd_config PermitRootLogin no PasswordAuthentication no UsePAM yes X11Forwarding yes Subsystem sftp /usr/lib/ssh/sftp-server Probiers mal mit meiner Config. Die ist zwar recht minimalistisch, läuft aber ;-)

...

Außerdem wäre ein Loginversuch mit SSH-Key interessant - probier das bitte mal mit ssh -vv user@suse91 ("user@suse91" entsprechend anpassen).

Wenn ich versuche mich von dem rechner auf sich selbst einzuloggen (9.1):

crash@zoidberg:~> ssh -vv zoidberg OpenSSH_3.8p1, SSH protocols 1.5/2.0, OpenSSL 0.9.7d 17 Mar 2004 [...] debug1: identity file /home/crash/.ssh/identity type 0 [...] debug1: identity file /home/crash/.ssh/id_rsa type 0

Bei mir gibt es beide genannten Dateien nicht. Moment: Kann es sein, dass Du einen recht alten Key hast? Möglicherweise ist der auf Protokollversion 1 beschränkt...

[...] debug1: identity file /home/crash/.ssh/id_dsa type 2 debug1: Remote protocol version 1.99, remote software version OpenSSH_3.8p1 debug1: match: OpenSSH_3.8p1 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0

compatibility mode? Erscheint bei mir (auf der 9.2) nicht.

[...] debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc

Bei mir zusätzlich: rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr Auch weiter unten wird bei mir die ein oder andere Verschlüsselungsmethode (?) zusätzlich gelistet.

[...] debug2: dh_gen_key: priv key bits set: 141/256 debug2: bits set: 543/1024

Hier: debug2: dh_gen_key: priv key bits set: 134/256 debug2: bits set: 524/1024

debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug1: Host 'zoidberg' is known and matches the RSA host key. debug1: Found key in /home/crash/.ssh/known_hosts:3 debug2: bits set: 478/1024

Hier: debug2: bits set: 525/1024

debug2: key: /home/crash/.ssh/id_rsa (0x808a140) debug2: key: /home/crash/.ssh/id_dsa (0x808a158)

Ich biete: debug2: key: /home/cb/.ssh/id_dsa (0x808f188) debug2: key: /home/cb/.ssh/identity ((nil)) debug2: key: /home/cb/.ssh/id_rsa ((nil)) Bei mir existiert also nur ~/.ssh/id_dsa

debug1: Authentications that can continue: publickey,password,keyboard-interactive debug1: Next authentication method: publickey debug1: Offering public key: /home/crash/.ssh/id_rsa

Es wird also erstmal mit id_rsa probiert.

debug2: we sent a publickey packet, wait for reply debug1: Authentications that can continue: publickey,password,keyboard-interactive debug1: Offering public key: /home/crash/.ssh/id_dsa

Jetzt ist id_dsa an der Reihe.

debug2: we sent a publickey packet, wait for reply

... und hier sollte wohl irgendwas kommen. Bei mir: debug1: Offering public key: /home/cb/.ssh/id_dsa debug2: we sent a publickey packet, wait for reply debug1: Server accepts key: pkalg ssh-dss blen 817 debug2: input_userauth_pk_ok: fp db:7d:...................... debug1: Authentication succeeded (publickey).

...

BTW: Ich habe gerade etwas getestet und mich erfolgreich von SuSE 9.2 auf eine 9.0 (mein Server) und von dort "zurück" auf die 9.2 unter Verwendung meines SSH-Keys einloggen können.

ja, das geht bei einigen leute. nur bei mir reproduzierbar mit keiner einzigen version >9.0

Haben diese "einige Leute" in letzter Zeit einen neuen SSH-Key generiert? (und keine "alten" Keys in ~/.ssh rumliegen?) Vorschlag: mv ~/.ssh ~/.ssh_orig ssh-keygen -t dsa -b 2048 cat ~/.ssh/id_dsa.pub | ssh zieluser@zielrechner \ "mkdir .ssh; cat >> .ssh/authorized_keys" obiges stammt übrigens aus: 8.3. Wie erstellt man einen SSH-Key? Wie kommt der Key auf den Zielrechner? http://suse-linux-faq.koehntopp.de/q/q-ssh-keygen.html und hat bei mir unter einem Testuser gerade funktioniert. Mit dem neuen Key und frischem ~/.ssh testest Du dann nochmal. Zum Testen geht auch cat ~/.ssh/id_dsa.pub >> ~/.ssh/authorized_keys und anschließend ssh localhost

...

Login auf SuSE 9.1 geht mit dem SSH-Key auch, sonst hätte ich gewisse Schwierigkeiten bei Wartungsarbeiten für die FAQ ;-) Das Ganze ist also kein generelles Problem bei der 9.[12].

jetzt sag bloss! probleme? ach iwo...

;-)

...

Alternativ: per NFS mounten und "lokal" rsyncen (oder bei der Gelegenheit gleich auf StoreBackup umstellen ;-)

das ist scheisse. irgendwas geht mit der zeichenkonvertierung dann schief.

NFS-Mounts dürften wohl auch mit utf8-Problemen zu kämpfen haben... Ungetestet: gibt es für NFS die Mount-Option iocharset?

ausserdem ist rsync wesentlich schneller. ich hatte jetzt fuer eine uebergangszeit mal ein cp -u auf ein gemountetes laufwerk, aber rsync ist doch wesentlich besser und schneller.

Gegenüber cp: klar ;-)

...

5.3. Storebackup: Backup auf Festplatte http://suse-linux-faq.koehntopp.de/q/q-backup-storebackup.html

werde ich mir mal reinziehen und testen.

Vorteil gegenüber rsync ist übrigens, dass Du mehrere Instanzen des Backups hast, wobei nur geänderte Dateien zusätzlich Platz verbrauchen (der Rest sind Hardlinks). Gruß Christian Boltz --

WO du debian nimmst, hast du kein Yast ;-) Gut, da hat Debian also schonmal die Nase vorn. :-) [> Hajo C Jeske und Ratti in suse-linux]

Hi!

vorweg: Du hast im Vergleich zu meiner Config sehr viele Einträge. Ich kommentiere es mal durch:

ich bevorzuge es auch die default werte fest einzustellen. dann ist normalerweise bei einem versionswechsel (wenn sich der default aendert) von einer gleichen konfiguration auszugehen...

...

ServerKeyBits 1536 Default scheint 768 zu sein.

richtig. das habe ich seit der 6.2er erhoeht. bisher nie probleme.

...

LogLevel DEBUG3 Default ist wohl INFO.

ja, aber debug3 bringt auch keine erleuchtung...

...

AuthorizedKeysFile %h/.ssh/authorized_keys Bei mir steht da als Default-Value einfach nur .ssh/authorized_keys - also ohne das %h/ davor. Teste das mal (oder kommentiere die Zeile aus)

ja, funktioniert aber auch nicht.

BTW: Solange UsePAM aktiv ist, geht auch Login mit Passwort.

das ist gewollt.

...

X11Forwarding yes Ist bei mir auch an - ich weiß aber nicht, was Default ist.

IMHO "no"

Probiers mal mit meiner Config. Die ist zwar recht minimalistisch, läuft aber ;-)

keine aenderung...

Bei mir gibt es beide genannten Dateien nicht.

das sind halt RSA keys.

Moment: Kann es sein, dass Du einen recht alten Key hast? Möglicherweise ist der auf Protokollversion 1 beschränkt...

naja, ich habe zumindest einen neuen (bzw. mehrere) erstellt. rsa ist bei mir standard, das war ein weiterer verzweifelter versuch.

compatibility mode? Erscheint bei mir (auf der 9.2) nicht.

das ist eine frage des clients. sollte aber keinen unterschied machen.

...

debug2: we sent a publickey packet, wait for reply

.. und hier sollte wohl irgendwas kommen. Bei mir:

debug1: Offering public key: /home/cb/.ssh/id_dsa debug2: we sent a publickey packet, wait for reply debug1: Server accepts key: pkalg ssh-dss blen 817 debug2: input_userauth_pk_ok: fp db:7d:...................... debug1: Authentication succeeded (publickey).

richtig, und genau das ist das problem. ich verstehe es aber nicht, ist aber reproduzierbar auf allen rechner mit suse >9.0 hier so. weiss der geier warum...

Haben diese "einige Leute" in letzter Zeit einen neuen SSH-Key generiert? (und keine "alten" Keys in ~/.ssh rumliegen?)

meine keys sind ganz frisch. noch warm sozusagen. das war eine der ersten sachen, die ich probiert habe, neue keys zu erstellen.

Mit dem neuen Key und frischem ~/.ssh testest Du dann nochmal.

macht keinen unterschied.

NFS-Mounts dürften wohl auch mit utf8-Problemen zu kämpfen haben... Ungetestet: gibt es für NFS die Mount-Option iocharset?

ja, wohl schon. aber irgendwie kommt dann bei mir immer noch kaese raus.

Vorteil gegenüber rsync ist übrigens, dass Du mehrere Instanzen des Backups hast, wobei nur geänderte Dateien zusätzlich Platz verbrauchen (der Rest sind Hardlinks).

habe ich gelesen. muss ich mich mal mit beschaeftigen... ciao T

Hi!

...

prinzipiell wuerde es mir reichen, wenn ich von einem bestimmten rechner aus eine reihe von verzeichnissen synchronisieren kann.

Dann lies mal

http://suse-linux-faq.koehntopp.de/q/q-backup-rsync.html

das bezieht sich auf rsync mit ssh. und das funktioniert hier nicht, wie schon mehrfach gepostet (ohne lösung). bei ssh wird hier IMMER ein passwort abgefragt. der 9.1er server akzeptiert die zertifikate ohne erkennbaren grund nicht. daher: rsync aber ohne ssh. ciao T