Mailinglist Archive: opensuse-de (2118 mails)

[Alexander Jäger <alex@xxxxxxxxxx>]

Guten Morgen Liste, hallo Hans, Hallo Michael,

> Am Mittwoch, 31. August 2005 00:08 schrieb Christian Boltz:
> > Hallo Hans-Martin, hallo Michael, hallo Alexander, hallo Leute,
> >
> > Am Montag, 29. August 2005 18:50 schrieb Hans-Martin Flesch:
> > > Michael Raab schrieb:
> > > > Am Mo, den 29.08.2005 schrieb Alexander Jäger um 18:27:
> > > >>server2:/var/backup/.ssh # ll
> > > >>drwxrwxrwx    2 backup   www          4096 Aug 29 13:50
> >
> > ~/.ssh ist also für *alle* schreibbar. Das dürfte die Ursache für das
> > Problem sein. Reduziere die Rechte mal auf 755 oder sogar 700.

sowohl 700 als auch 755 funktionierte nicht
>
> was mich hier wundert, ist dass das ll in /var/backup/.ssh
> gemacht wurde und
> eben nicht in ~/.ssh - oder ist /var/backup das Home-Verzeichnis des
> Backup-Users?
>

ja ist es

> Ich hab jetzt gerade noch mal bei mir geschaut, meine keys (dsa) stehen
> alle in der authorized_keys2. Ich bin mir jetzt nicht sicher, aber kann
> es sein, dass authorized_keys nur für das veraltete, unsichere und
> standardmässig deaktivierte ssh1 verwendet wird, während für ssh2 die
> authorized_keys2 genutzt wird?
> Ansonsten wirf auch auf /var/log/messages, während des loginversuchs,
> ich hatte mal das Problem, dass die Rechte des .ssh Verzeichnisses zu
> großzügig gewählt waren, ssh hat darauf hin verweigert die
> authorized_keys2 daraus zu verwenden.

habe jetzt auf 700 geändert, problem besteht weiterhin, auch eine
umbenennung funktioniert nicht

ssh backup@server2 -v-v gibt folgendes aus:
server1:~ # ssh backup@server2 -v-v
OpenSSH_3.7.1p2, SSH protocols 1.5/2.0, OpenSSL 0.9.7b 10 Apr 2003
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to server2 [81.169.142.181] port 22.
debug1: Connection established.
debug1: identity file /root/.ssh/identity type -1
debug1: identity file /root/.ssh/id_rsa type -1
debug1: identity file /root/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_3.7.1p2
debug1: match: OpenSSH_3.7.1p2 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.7.1p2
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 'server2' is known and matches the RSA host key.
debug1: Found key in /root/.ssh/known_hosts:2
debug1: ssh_rsa_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,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Trying private key: /root/.ssh/identity
debug1: Trying private key: /root/.ssh/id_rsa
debug1: Trying private key: /root/.ssh/id_dsa
debug1: Next authentication method: keyboard-interactive

wobei der private key zu dem passenden key in der authorized_keys der key
rootkey.pub ist, welcher korrekt in /root/.ssh und heißt "rootkey"
was ich jetzt auch mal versucht habe "rootkey" in d"identity" umzubenennen,
funktioniert auch nich, langsam verzweifle ich ...

Gruß Alex