Hallo,
ich will mich als user über eine ssh einloggen und bekomme eine authentification failure. Ich habe kürzlich auf dem Rechner das Passwort mit passwd geändert. Wenn ich über einen anderen login eingeloggt bin, wird das neue Passwort bei einloggen mittels su erkannt. Auch das Löschen des Passworts in /etc/shadow schafft keine Abhilfe. Bei dem System handelt es sich um ein gentoo System.
Weiß jemand, woran es liegt?
Gruss, Orm
Orm Finnendahl finnendahl@folkwang-hochschule.de wrote:
Hallo,
ich will mich als user über eine ssh einloggen und bekomme eine authentification failure. Ich habe kürzlich auf dem Rechner das Passwort mit passwd geändert. Wenn ich über einen anderen login eingeloggt bin, wird das neue Passwort bei einloggen mittels su
Über einen login anderen per ssh? Oder lokal?
erkannt. Auch das Löschen des Passworts in /etc/shadow schafft keine Abhilfe. Bei dem System handelt es sich um ein gentoo System.
Weiß jemand, woran es liegt?
Ich tippe mal am PAM. Über PAM melden sich alle Benutzer am System an. Für jeden Service gibt es eine PAM-config-Datei in /etc/pam.d
Entweder gibt es für sshd keine, oder in der steht: lass niemanden außer $irgendwer zu.
Meine /etc/pam.d/sshd (Gentoo 1.2): ==== #%PAM-1.0
auth required /lib/security/pam_securetty.so auth required /lib/security/pam_stack.so service=system-auth auth required /lib/security/pam_nologin.so
account required /lib/security/pam_stack.so service=system-auth
password required /lib/security/pam_stack.so service=system-auth
session required /lib/security/pam_stack.so service=system-auth session optional /lib/security/pam_console.so ====
Mit dieser config kann sich jeder reguläre Systembenutzer am Rechner mittels ssh anmelden.
mfg, Fabian
On Fri, Jun 20, 2003 at 09:56:33AM +0200, Orm Finnendahl wrote:
ich will mich als user über eine ssh einloggen und bekomme eine authentification failure. Ich habe kürzlich auf dem Rechner das Passwort mit passwd geändert. Wenn ich über einen anderen login eingeloggt bin, wird das neue Passwort bei einloggen mittels su erkannt. Auch das Löschen des Passworts in /etc/shadow schafft keine Abhilfe. Bei dem System handelt es sich um ein gentoo System.
Als welcher user? root? Da gibt's manchmal Beschränkungen. Ging es vor der Passwort-Änderung? Wurden noch andere Dinge geändert (PAM, LIBC, ...)?
Was ist zu erkennen bei 'ssh -v user@remote-host'?
Heiko
Am Freitag, den 20. Juni 2003 um 10:30:33 Uhr (+0200) schrieb Heiko Schlittermann:
Was ist zu erkennen bei 'ssh -v user@remote-host'?
<xterm_dump>
orm@grisey:~$ ssh -v orm@audio OpenSSH_3.4p1 Debian 1:3.4p1-2, SSH protocols 1.5/2.0, OpenSSL 0x0090607f debug1: Reading configuration data /etc/ssh/ssh_config debug1: Rhosts Authentication disabled, originating port will not be trusted. debug1: ssh_connect: needpriv 0 debug1: Connecting to audio [192.168.77.8] port 22. debug1: Connection established. debug1: identity file /home/orm/.ssh/identity type 0 debug1: identity file /home/orm/.ssh/id_rsa type -1 debug1: identity file /home/orm/.ssh/id_dsa type -1 debug1: Remote protocol version 1.99, remote software version OpenSSH_3.5p1 debug1: match: OpenSSH_3.5p1 pat OpenSSH* Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_3.4p1 Debian 1:3.4p1-2 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: dh_gen_key: priv key bits set: 128/256 debug1: bits set: 1570/3191 debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug1: Host 'audio' is known and matches the RSA host key. debug1: Found key in /home/orm/.ssh/known_hosts:28 debug1: bits set: 1627/3191 debug1: ssh_rsa_verify: signature correct debug1: kex_derive_keys debug1: newkeys: mode 1 debug1: SSH2_MSG_NEWKEYS sent debug1: waiting for SSH2_MSG_NEWKEYS debug1: newkeys: mode 0 debug1: SSH2_MSG_NEWKEYS received debug1: done: ssh_kex2. debug1: send SSH2_MSG_SERVICE_REQUEST debug1: service_accept: ssh-userauth debug1: got SSH2_MSG_SERVICE_ACCEPT debug1: authentications that can continue: publickey,password,keyboard-interacti ve debug1: next auth method to try is publickey debug1: try privkey: /home/orm/.ssh/id_rsa debug1: try privkey: /home/orm/.ssh/id_dsa debug1: next auth method to try is keyboard-interactive debug1: authentications that can continue: publickey,password,keyboard-interacti ve debug1: next auth method to try is password orm@audio's password: debug1: authentications that can continue: publickey,password,keyboard-interacti ve Permission denied, please try again. orm@audio's password: debug1: authentications that can continue: publickey,password,keyboard-interacti ve Permission denied, please try again. orm@audio's password: debug1: authentications that can continue: publickey,password,keyboard-interactive debug1: no more auth methods to try Permission denied (publickey,password,keyboard-interactive). debug1: Calling cleanup 0x8063a9c(0x0) orm@grisey:~$
</xterm_dump>
Gruss, Orm
Hallo,
On 06/20/03 09:56, Orm Finnendahl wrote:
Hallo,
ich will mich als user über eine ssh einloggen und bekomme eine authentification failure. Ich habe kürzlich auf dem Rechner das Passwort mit passwd geändert. Wenn ich über einen anderen login eingeloggt bin, wird das neue Passwort bei einloggen mittels su erkannt. Auch das Löschen des Passworts in /etc/shadow schafft keine Abhilfe. Bei dem System handelt es sich um ein gentoo System.
Was sagt denn ssh -v?
Gruß
On Fri, 20 Jun 2003 09:56:33 +0200 Orm Finnendahl finnendahl@folkwang-hochschule.de wrote:
Hallo,
ich will mich als user über eine ssh einloggen und bekomme eine authentification failure. Ich habe kürzlich auf dem Rechner das
Hallo,
falls dir ssh -v nicht weiterhilft, ich hatte schon mal einen Fall, der ähnlich aussah und -v brachte nichts brauchbares an den Tag. Die Lösung stand bei mir damals in der /var/log/auth.log.
Folke
lug-dd@mailman.schlittermann.de