Hallo, seit 2 Tagen kann ich mich auf meinem Rechner mit openSUSE 11.4 (32bit) nicht mehr _aus der Ferne_ mit ssh oder putty einloggen. Lokal klappt die Anmeldung ohne Probleme. Das äußert sich so, dass ich Benutzername und Kenntwort eingeben kann und dann sofort die Verbindung gekappt wird. In messages erscheint lediglich die Fehlermeldung May 10 14:46:25 server sshd[10595]: error: PAM: pam_open_session(): Permission denied Ich habe auch einige Fundstellen dazu gefunden. Die sagen aber alle bloß, dass es an pam liegt. Ich habe daher pam auf den Stand der DVD [1.1.3-4.7.1] zurückversetzt und dann wieder auf den Stand des update repos [1.1.3-4.9.1]. Das hat nichts gebracht. Bedauerlicher Weise kann ich nicht sagen, seit wann das der Fall ist und nach welchem Update. Die entsprechenden logs lösche ich immer mal wieder ... Ich habe auch AppArmor deaktiviert und - wie teilweise vorgeschlagen - in der Datein /etc/pam.d/sshd die Zeile mit "session required pam_loginuid.so" auskommentiert bzw. required durch optional ersetzt. Was mich auch verblüfft, ist der Umstand, dass die Dateien in /etc/pam.d scheinbar denselben Inhalt haben, wie auf meinem parallel-System mit openSUSE 11.4 (64bit). Dort gibt es das Problem eigenartiger Weise nicht. Was kann ich noch versuchen? Gruß, Alex -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Alex schrieb:
Hi, schraub mal in /etc/ssh/sshd_config den loglevel höher (z.B. auf verbose). Und probiere mal bei einer Remoteanmeldung unter Linux ssh -v ... . Bernd Helmholtz Zentrum München Deutsches Forschungszentrum für Gesundheit und Umwelt (GmbH) Ingolstädter Landstr. 1 85764 Neuherberg www.helmholtz-muenchen.de Aufsichtsratsvorsitzende: MinDir´in Bärbel Brumme-Bothe Geschäftsführer: Prof. Dr. Günther Wess und Dr. Nikolaus Blum Registergericht: Amtsgericht München HRB 6466 USt-IdNr: DE 129521671 -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am 11.05.2012 19:12, schrieb Lentes, Bernd:
Danke für den Tipp! Hochschrauben vermutlich am Server - oder auch am Client? Am Server hat es nichts gebracht. Es bleibt bei der einen lapidaren Zeile wie oben beschrieben. Am Client steht jetzt das: alex:~ # ssh 192.168.1.111 -v OpenSSH_5.8p1, OpenSSL 1.0.0c 2 Dec 2010 debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug1: Connecting to 192.168.1.111 [192.168.1.111] port 22. debug1: Connection established. debug1: permanently_set_uid: 0/0 debug1: identity file /root/.ssh/id_rsa type 1 debug1: identity file /root/.ssh/id_rsa-cert type -1 debug1: identity file /root/.ssh/id_dsa type -1 debug1: identity file /root/.ssh/id_dsa-cert type -1 debug1: identity file /root/.ssh/id_ecdsa type -1 debug1: identity file /root/.ssh/id_ecdsa-cert type -1 debug1: Remote protocol version 2.0, remote software version OpenSSH_5.8 debug1: match: OpenSSH_5.8 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_5.8 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: server->client aes128-ctr hmac-md5 none debug1: kex: client->server aes128-ctr hmac-md5 none debug1: sending SSH2_MSG_KEX_ECDH_INIT debug1: expecting SSH2_MSG_KEX_ECDH_REPLY debug1: Server host key: ECDSA 6c:36:00:99:95:f0:a5:4a:ec:a5:90:0f:32:bc:39:af debug1: Host '192.168.1.111' is known and matches the ECDSA host key. debug1: Found key in /root/.ssh/known_hosts:1 debug1: ssh_ecdsa_verify: signature correct debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: Roaming not allowed by server 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: Offering RSA public key: /root/.ssh/id_rsa debug1: Authentications that can continue: publickey,keyboard-interactive debug1: Trying private key: /root/.ssh/id_dsa debug1: Trying private key: /root/.ssh/id_ecdsa debug1: Next authentication method: keyboard-interactive Password: debug1: Authentication succeeded (keyboard-interactive). Authenticated to 192.168.1.111 ([192.168.1.111]:22). debug1: channel 0: new [client-session] debug1: Requesting no-more-sessions@openssh.com debug1: Entering interactive session. debug1: Sending environment. debug1: Sending env LANG = POSIX debug1: Sending env LC_CTYPE = de_DE.UTF-8 Last login: Fri May 11 18:22:43 2012 from 192.168.1.32 Have a lot of fun... debug1: client_input_channel_req: channel 0 rtype exit-status reply 0 debug1: client_input_channel_req: channel 0 rtype eow@openssh.com reply 0 debug1: channel 0: free: client-session, nchannels 1 Connection to 192.168.1.111 closed. Transferred: sent 2504, received 1728 bytes, in 0.0 seconds Bytes per second: sent 193121.7, received 133272.5 debug1: Exit status 254 Jetzt brauche ich bloß noch Hilfe, das auszuwerten. Würde es etwas bringen, wenn ich mit der Holzhammer-Methode alle Pakete neu installiere? sudo zypper in -f $(rpm -qa --qf "%{NAME} ") Dann müsste er doch theoretisch auch die Einstellungen wiederherstellen. Ich würde zuvor ausschließlich die DVD als repo definieren. Ich habe bloß ein bißchen Bammel, dass es dann mit den Kernel-Updates Schwierigkeiten geben könnte. Gruß, Alex -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am 11.05.2012 19:12, schrieb Lentes, Bernd:
session optional pam_lastlog.so silent noupdate showfailed Ich habe die Datei pam_lastlog.so aber in /lib/security gefunden, wie die anderen Module auch. Das bringt mich zu den nächsten Fragen: 1. Wieso klappt es nicht? 2. Wie "repariere" ich die Datei? 3. Wie bekomme ich heraus, wer sie kaputt gemacht hat? Danke für die Hilfe. Gruß, Alex -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Hallo Alex, hallo Leute, Am Freitag, 11. Mai 2012 schrieb Alex Winzer:
Überprüfe erstmal, ob eine der betreffenden Dateien verändert wurde. Mit rpm -qf /pfad/zur/datei bekommst Du heraus, zu welchem Paket eine Datei gehört. In diesem Fall ist das höchstwahrscheinlich "pam" oder "pam-32bit" (letzteres gibt es nur auf 64bit-Systemen). Mit rpm -V pam pam-32bit kannst Du dann überprüfen, ob Dateien aus diesem Paket nach der Installation verändert wurden. Wenn Du noch weißt, wann das Problem erstmals aufgetreten ist, kann /var/log/zypp/history hilfreich sein, um das "schuldige" Paket einzugrenzen. Gruß Christian Boltz --
-- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Hallo, ich möchte gleich voranstellen, dass ich die Probleme jetzt _auch_ auf meinem Haupt-Server mit openSUSE 11.4 64bit habe. Ich mache auf diesem immer Sonntags die Updates, um nicht mitten in der Woche die gesamte Firma lahmzulegen. Auch hier hat mir aber das Auskommentieren der letzten Zeile geholfen. Am 13.05.2012 16:52, schrieb Christian Boltz:
32bit: pam-1.1.3-4.9.1.i586 64bit: pam-32bit-1.1.3-4.9.1.x86_64 Da ich mich eher als Benutzer denn als Entwickler, Admin oder sonstwas sehe, muss ich an dieser Stelle fragen, was mir das jetzt sagt? Bedeutet das, dass ich die Pakete neu installieren sollte/muss?
In der Hilfe zu rpm (man rpm) steht dazu "L readLink(2) path missmatch". Mehr leider nicht. Wie jetzt weiter? 64bit: Es gibt keine Ausgabe. Also ist vermutlich alles OK? Bringt mich zur Frage: Warum geht es dann nicht _mehr_?
Beim 32bit System leider nicht mehr. Das ist mein Backup-Server, den ich notfalls neu aufsetzen kann. Die logs habe ich dort unglücklicher Weise schon gelöscht. Beim 64bit System ist die Datei noch vorhanden (ca. 13 KB). Darf man so was lt. Listenregeln als Anhang beifügen? Gruß & Dank, Alex -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Alex schrieb:
Hi, schraub mal in /etc/ssh/sshd_config den loglevel höher (z.B. auf verbose). Und probiere mal bei einer Remoteanmeldung unter Linux ssh -v ... . Bernd Helmholtz Zentrum München Deutsches Forschungszentrum für Gesundheit und Umwelt (GmbH) Ingolstädter Landstr. 1 85764 Neuherberg www.helmholtz-muenchen.de Aufsichtsratsvorsitzende: MinDir´in Bärbel Brumme-Bothe Geschäftsführer: Prof. Dr. Günther Wess und Dr. Nikolaus Blum Registergericht: Amtsgericht München HRB 6466 USt-IdNr: DE 129521671 -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am 11.05.2012 19:12, schrieb Lentes, Bernd:
Danke für den Tipp! Hochschrauben vermutlich am Server - oder auch am Client? Am Server hat es nichts gebracht. Es bleibt bei der einen lapidaren Zeile wie oben beschrieben. Am Client steht jetzt das: alex:~ # ssh 192.168.1.111 -v OpenSSH_5.8p1, OpenSSL 1.0.0c 2 Dec 2010 debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug1: Connecting to 192.168.1.111 [192.168.1.111] port 22. debug1: Connection established. debug1: permanently_set_uid: 0/0 debug1: identity file /root/.ssh/id_rsa type 1 debug1: identity file /root/.ssh/id_rsa-cert type -1 debug1: identity file /root/.ssh/id_dsa type -1 debug1: identity file /root/.ssh/id_dsa-cert type -1 debug1: identity file /root/.ssh/id_ecdsa type -1 debug1: identity file /root/.ssh/id_ecdsa-cert type -1 debug1: Remote protocol version 2.0, remote software version OpenSSH_5.8 debug1: match: OpenSSH_5.8 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_5.8 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: server->client aes128-ctr hmac-md5 none debug1: kex: client->server aes128-ctr hmac-md5 none debug1: sending SSH2_MSG_KEX_ECDH_INIT debug1: expecting SSH2_MSG_KEX_ECDH_REPLY debug1: Server host key: ECDSA 6c:36:00:99:95:f0:a5:4a:ec:a5:90:0f:32:bc:39:af debug1: Host '192.168.1.111' is known and matches the ECDSA host key. debug1: Found key in /root/.ssh/known_hosts:1 debug1: ssh_ecdsa_verify: signature correct debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: Roaming not allowed by server 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: Offering RSA public key: /root/.ssh/id_rsa debug1: Authentications that can continue: publickey,keyboard-interactive debug1: Trying private key: /root/.ssh/id_dsa debug1: Trying private key: /root/.ssh/id_ecdsa debug1: Next authentication method: keyboard-interactive Password: debug1: Authentication succeeded (keyboard-interactive). Authenticated to 192.168.1.111 ([192.168.1.111]:22). debug1: channel 0: new [client-session] debug1: Requesting no-more-sessions@openssh.com debug1: Entering interactive session. debug1: Sending environment. debug1: Sending env LANG = POSIX debug1: Sending env LC_CTYPE = de_DE.UTF-8 Last login: Fri May 11 18:22:43 2012 from 192.168.1.32 Have a lot of fun... debug1: client_input_channel_req: channel 0 rtype exit-status reply 0 debug1: client_input_channel_req: channel 0 rtype eow@openssh.com reply 0 debug1: channel 0: free: client-session, nchannels 1 Connection to 192.168.1.111 closed. Transferred: sent 2504, received 1728 bytes, in 0.0 seconds Bytes per second: sent 193121.7, received 133272.5 debug1: Exit status 254 Jetzt brauche ich bloß noch Hilfe, das auszuwerten. Würde es etwas bringen, wenn ich mit der Holzhammer-Methode alle Pakete neu installiere? sudo zypper in -f $(rpm -qa --qf "%{NAME} ") Dann müsste er doch theoretisch auch die Einstellungen wiederherstellen. Ich würde zuvor ausschließlich die DVD als repo definieren. Ich habe bloß ein bißchen Bammel, dass es dann mit den Kernel-Updates Schwierigkeiten geben könnte. Gruß, Alex -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am 11.05.2012 19:12, schrieb Lentes, Bernd:
session optional pam_lastlog.so silent noupdate showfailed Ich habe die Datei pam_lastlog.so aber in /lib/security gefunden, wie die anderen Module auch. Das bringt mich zu den nächsten Fragen: 1. Wieso klappt es nicht? 2. Wie "repariere" ich die Datei? 3. Wie bekomme ich heraus, wer sie kaputt gemacht hat? Danke für die Hilfe. Gruß, Alex -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Hallo Alex, hallo Leute, Am Freitag, 11. Mai 2012 schrieb Alex Winzer:
Überprüfe erstmal, ob eine der betreffenden Dateien verändert wurde. Mit rpm -qf /pfad/zur/datei bekommst Du heraus, zu welchem Paket eine Datei gehört. In diesem Fall ist das höchstwahrscheinlich "pam" oder "pam-32bit" (letzteres gibt es nur auf 64bit-Systemen). Mit rpm -V pam pam-32bit kannst Du dann überprüfen, ob Dateien aus diesem Paket nach der Installation verändert wurden. Wenn Du noch weißt, wann das Problem erstmals aufgetreten ist, kann /var/log/zypp/history hilfreich sein, um das "schuldige" Paket einzugrenzen. Gruß Christian Boltz --
-- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Hallo, ich möchte gleich voranstellen, dass ich die Probleme jetzt _auch_ auf meinem Haupt-Server mit openSUSE 11.4 64bit habe. Ich mache auf diesem immer Sonntags die Updates, um nicht mitten in der Woche die gesamte Firma lahmzulegen. Auch hier hat mir aber das Auskommentieren der letzten Zeile geholfen. Am 13.05.2012 16:52, schrieb Christian Boltz:
32bit: pam-1.1.3-4.9.1.i586 64bit: pam-32bit-1.1.3-4.9.1.x86_64 Da ich mich eher als Benutzer denn als Entwickler, Admin oder sonstwas sehe, muss ich an dieser Stelle fragen, was mir das jetzt sagt? Bedeutet das, dass ich die Pakete neu installieren sollte/muss?
In der Hilfe zu rpm (man rpm) steht dazu "L readLink(2) path missmatch". Mehr leider nicht. Wie jetzt weiter? 64bit: Es gibt keine Ausgabe. Also ist vermutlich alles OK? Bringt mich zur Frage: Warum geht es dann nicht _mehr_?
Beim 32bit System leider nicht mehr. Das ist mein Backup-Server, den ich notfalls neu aufsetzen kann. Die logs habe ich dort unglücklicher Weise schon gelöscht. Beim 64bit System ist die Datei noch vorhanden (ca. 13 KB). Darf man so was lt. Listenregeln als Anhang beifügen? Gruß & Dank, Alex -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
participants (3)
-
Alex Winzer -
Christian Boltz -
Lentes, Bernd