Ubuntu pide contraseña dos veces

Todo lo que tengas que decir sobre Gnu/Linux y SSOO alternativos.

Moderador: Moderadores

Ubuntu pide contraseña dos veces

Notapor Anouk » Vie Nov 28, 2008 4:20 am

Wenas...

Tengo una Ubuntu en un laptot, y desde hace un par de días (o uno y medio, no se) me pide dos veces el pass para iniciar sesión (esto es: nombre usuario-contraseña-contraseña).

Tambien me lo hace a veces con sudo (por ejemplo, ahora mismo con sudo apt-get update).

En ningún caso me da un mensaje de error ni nada, simplemente parece que no me ha oido...

Salute!!!
Anouk
:-)
:-)
 
Mensajes: 22
Registrado: Jue Nov 23, 2006 12:39 am

Notapor Metro » Mié Dic 03, 2008 12:00 am

¿Podría ser alguna línea de sobra en los archivos de configuración de los módulos PAM? La verdad es que no tengo ni idea, si lo has estado tocando igual está el tema por ahí, y si no lo has estado tocando veo complicado que sea eso...

[edito]

Después de trastear con los módulos pam (están en /etc/pam.d/*) confirmo que esto puede ser un motivo por el cual te pida la contraseña dos veces. Pon en el foro la configuración de tus módullos (los archivos gdm, common-auth, common-session, common-password y common-account) y podré ayudarte.
Metro
:-)
:-)
 
Mensajes: 41
Registrado: Mar Abr 04, 2006 7:12 pm
Ubicación: Aquí

Notapor Anouk » Vie Dic 05, 2008 9:25 pm

Ahora veo, me pide siempre la contraseña dos veces. Cada vez que uso sudo, sudo^2.

gdm escribió:#%PAM-1.0
auth requisite pam_nologin.so
auth required pam_env.so readenv=1
auth required pam_env.so readenv=1 envfile=/etc/default/locale
@include common-auth
auth optional pam_gnome_keyring.so
@include common-account
session required pam_limits.so
@include common-session
session optional pam_gnome_keyring.so auto_start
@include common-password


common-auth escribió:#
# /etc/pam.d/common-auth - authentication settings common to all services
#
# This file is included from other service-specific PAM config files,
# and should contain a list of the authentication modules that define
# the central authentication scheme for use on the system
# (e.g., /etc/shadow, LDAP, Kerberos, etc.). The default is to use the
# traditional Unix authentication mechanisms.
#
# As of pam 1.0.1-5, this file is managed by pam-auth-update by default.
# To take advantage of this, it is recommended that you configure any
# local modules either before or after the default block, and use
# pam-auth-update to manage selection of other modules. See
# pam-auth-update(8) for details.

# here are the per-package modules (the "Primary" block)
auth [success=1 default=ignore] pam_unix.so nullok_secure
# here's the fallback if no module succeeds
auth requisite pam_deny.so
# prime the stack with a positive return value if there isn't one already;
# this avoids us returning an error just because nothing sets a success code
# since the modules above will each just jump around
auth required pam_permit.so
# and here are more per-package modules (the "Additional" block)
# end of pam-auth-update config

auth sufficient pam_fprint.so
auth required pam_unix.so nullok_secure


common-session escribió:#
# /etc/pam.d/common-session - session-related modules common to all services
#
# This file is included from other service-specific PAM config files,
# and should contain a list of modules that define tasks to be performed
# at the start and end of sessions of *any* kind (both interactive and
# non-interactive).
#
# As of pam 1.0.1-5, this file is managed by pam-auth-update by default.
# To take advantage of this, it is recommended that you configure any
# local modules either before or after the default block, and use
# pam-auth-update to manage selection of other modules. See
# pam-auth-update(8) for details.

# here are the per-package modules (the "Primary" block)
session [default=1] pam_permit.so
# here's the fallback if no module succeeds
session requisite pam_deny.so
# prime the stack with a positive return value if there isn't one already;
# this avoids us returning an error just because nothing sets a success code
# since the modules above will each just jump around
session required pam_permit.so
# and here are more per-package modules (the "Additional" block)
session required pam_unix.so
session optional pam_ck_connector.so nox11
# end of pam-auth-update config


common-password escribió:#
# /etc/pam.d/common-password - password-related modules common to all services
#
# This file is included from other service-specific PAM config files,
# and should contain a list of modules that define the services to be
# used to change user passwords. The default is pam_unix.

# Explanation of pam_unix options:
#
# The "sha512" option enables salted SHA512 passwords. Without this option,
# the default is Unix crypt. Prior releases used the option "md5".
#
# The "obscure" option replaces the old `OBSCURE_CHECKS_ENAB' option in
# login.defs.
#
# See the pam_unix manpage for other options.

# As of pam 1.0.1-5, this file is managed by pam-auth-update by default.
# To take advantage of this, it is recommended that you configure any
# local modules either before or after the default block, and use
# pam-auth-update to manage selection of other modules. See
# pam-auth-update(8) for details.

# here are the per-package modules (the "Primary" block)
password [success=1 default=ignore] pam_unix.so obscure sha512
# here's the fallback if no module succeeds
password requisite pam_deny.so
# prime the stack with a positive return value if there isn't one already;
# this avoids us returning an error just because nothing sets a success code
# since the modules above will each just jump around
password required pam_permit.so
# and here are more per-package modules (the "Additional" block)
# end of pam-auth-update config


common-account escribió:#
# /etc/pam.d/common-account - authorization settings common to all services
#
# This file is included from other service-specific PAM config files,
# and should contain a list of the authorization modules that define
# the central access policy for use on the system. The default is to
# only deny service to users whose accounts are expired in /etc/shadow.
#
# As of pam 1.0.1-5, this file is managed by pam-auth-update by default.
# To take advantage of this, it is recommended that you configure any
# local modules either before or after the default block, and use
# pam-auth-update to manage selection of other modules. See
# pam-auth-update(8) for details.
#

# here are the per-package modules (the "Primary" block)
account [success=1 new_authtok_reqd=done default=ignore] pam_unix.so
# here's the fallback if no module succeeds
account requisite pam_deny.so
# prime the stack with a positive return value if there isn't one already;
# this avoids us returning an error just because nothing sets a success code
# since the modules above will each just jump around
account required pam_permit.so
# and here are more per-package modules (the "Additional" block)
# end of pam-auth-update config


Què dius?
Anouk
:-)
:-)
 
Mensajes: 22
Registrado: Jue Nov 23, 2006 12:39 am

Notapor Metro » Mié Dic 10, 2008 3:39 pm

Que què dic?

Pues que no lo pillo muy bien ahora mismo. Debería ir bien pero hay algo que se me escapa :S
Creo que pam_unix.so pide contraseña y pam_gnome_keyring también (no veo que los demás módulos pidan contraseña aunque puede ser.

Yo pondría en gdm y en la línea de pam_gnome keyring lo siguiente

auth optional pam_gnome_keyring.so try_first_pass

El caso es que cuando varios módulos te piden contraseña se puede usar try_first_pass o use_first_pass para que usen la contraseña que pones al principio (la que pide el módulo pam_unix.so). Prueba lo que te he dicho y si no pon el try_first_pass por todas partes hasta encontrar al culpable.
Yo empezaría probando abriendo un terminal para editar los archivos y otro para hacer su usuario (que sea diferente del tuyo y diferente de root) para ver si te la pide dos veces. Si cuando arregles este trozo (puede que también haya que modificar /etc/pam.d/su aunque lo dudo) ya no te la pide para su pero sí para gdm el problema está en el /etc/pam.d/gdm, que es el que te digo que modifiques.

Espero que te sirva, ya nos cuentas cómo te funciona y dónde estaba el problema. :)
Metro
:-)
:-)
 
Mensajes: 41
Registrado: Mar Abr 04, 2006 7:12 pm
Ubicación: Aquí

Notapor Anouk » Vie Dic 19, 2008 12:08 am

Probé a añadir "try_first_pam" en el gdm y nada...
Por cierto, creo que los problemas me vinieron al instalar Compiz... tendrá algo que ver? O_o
Anouk
:-)
:-)
 
Mensajes: 22
Registrado: Jue Nov 23, 2006 12:39 am

Notapor Metro » Mar Dic 30, 2008 4:45 pm

Bueno, vamos a enfocar el problema desde otro sitio. Prueba a iniciar sesión otra vez, pero la segunda contraseña ponla mal. Luego inicia sesión normalmente y busca el archivo /var/log/auth.log.

En este archivo están todas las entradas que se han hecho al sistema y también están las entradas en las que se ha fallado. En todos los casos indica qué módulo pam ha permitido o denegado la entrada al sistema. Busca la hora y fecha en la que has entrado y mira qué módulo ha fallado antes, por ejemplo:
Código: Seleccionar todo
Dec 30 15:40:31 pc027Debian su[9098]: pam_authenticate: Authentication failure
Dec 30 15:40:31 pc027Debian su[9098]: FAILED su for marketing by informatica
Dec 30 15:40:31 pc027Debian su[9098]: - pts/0 informatica:marketing
Dec 30 15:40:37 pc027Debian su[9099]: pam_unix(su:auth): authentication failure; logname=informatica uid=10000 euid=0 tty=pts/0 ruser=informatica rhost=  user=marketing
Dec 30 15:40:37 pc027Debian su[9099]: Successful su for marketing by informatica
Dec 30 15:40:37 pc027Debian su[9099]: + pts/0 informatica:marketing
Dec 30 15:40:37 pc027Debian su[9099]: pam_unix(su:session): session opened for user marketing by informatica(uid=10000)
Dec 30 15:40:37 pc027Debian su[9099]: pam_mount(mount.c:146): realpath of volume "/home/******/marketing/datos" is "/home/*****/marketing/datos"



Por ejemplo, aquí he intentado entrar con el usuario marketing y he puesto mal la contraseña, me dice que ha fallado y que es el módulo pam_unix en su:auth donde me ha fallado. Luego lo he puesto bien y todo perfecto.
Busca la línea donde te falla y pones el try_fist_pass o use_first_pass. En caso de que no funcione por lo menos ya sabemos qué módulo tiene la culpa y podemos seguir indagando.

Espero noticias ;)

PD: No sé si tiene algo que ver el compiz, pero no "debería" tener nada que ver...
Metro
:-)
:-)
 
Mensajes: 41
Registrado: Mar Abr 04, 2006 7:12 pm
Ubicación: Aquí


Volver a Gnu/Linux y SSOO alternativos

¿Quién está conectado?

Usuarios navegando por este Foro: No hay usuarios registrados visitando el Foro y 2 invitados

cron