sudo sigue pidiéndome mi contraseña en fish shell

19

sudo en Ubuntu sigue pidiéndome mi contraseña para cada comando. Anteriormente, solo tenía que ingresar la contraseña una vez, y luego se recordaría por un período de tiempo. Esto cambió recientemente, probablemente después de "actualizar" a Natty.

Lo hice sudo visudoy configuré Defaults env_reset, timestamp_timeout = 60, intenté reiniciar, pero todavía no funciona. ¿Cómo puedo solucionar esto?

Después de las sugerencias a continuación, mi /etc/sudoersaspecto es el siguiente:

#
# This file MUST be edited with the 'visudo' command as root.
#
# Please consider adding local content in /etc/sudoers.d/ instead of
# directly modifying this file.
#
# See the man page for details on how to write a sudoers file.
#
Defaults        env_reset
Defaults:endolith timestamp_timeout=60

# Host alias specification

# User alias specification

# Cmnd alias specification

# User privilege specification
root    ALL=(ALL:ALL) ALL

# Members of the admin group may gain root privileges
%admin ALL=(ALL) ALL

# Allow members of group sudo to execute any command
%sudo   ALL=(ALL:ALL) ALL

#includedir /etc/sudoers.d

Actualizar:

Actualicé mi VirtualBox y comenzó a sufrir el mismo problema. Supongo que ejecuté bash e intenté sudo en eso, y la contraseña se recuerda correctamente. Es sólo cuando uso mi shell por defecto de pescado que no recuerda. Lo hizo en la versión anterior de Ubuntu, pero ya no.

Actualizar:

Actualicé a 13.05 y esto mágicamente comenzó a funcionar nuevamente. Ahora me pide mi contraseña una vez, deja de pedirla un momento y luego me la pide nuevamente después de un período de tiempo.

— endolito
fuente

posible duplicado: superuser.com/questions/148665/…

— warren

3

@warren: Eso no es un duplicado. Debería solicitarme que ingrese la contraseña, pero después de haberla ingresado una vez, no es necesario que lo haga por un período de tiempo determinado. He cambiado esta cantidad de tiempo con visudo en el pasado, pero ya no funciona.

— endolith

Creo que debe usar varias declaraciones predeterminadas, en lugar de una común separada.

— Stephanie

@Stephanie, estoy seguro de que tener una sola declaración de valores predeterminados con valores separados por comas funciona bien.

— Zoredache

veo que has agregado una línea como Defaults:endolith timestamp_timeout=60, pero no estás en ningún grupo llamado endolito, de acuerdo con otro comentario aquí. Entonces, ¿qué nombre de usuario estás usando? Verifique whoamiy agregue ese nombre de usuario en lugar de endolithen Defaults:endolith timestamp_timeout=60oendolith ALL=(ALL) NOPASSWD: ALL

— wim

15

@endolith: Sí, solo parece afectar a los peces. Tuve el mismo problema, el problema es causado por la opción sudo "tty_tickets". Deshabilitar esto en su archivo / etc / sudoers resolverá el problema.

Lo siguiente deshabilitará tty_tickets:

Defaults        env_reset,!tty_tickets

— Kadu
fuente

¿Tiene esto alguna ramificación negativa?

— endolito

1

"Tenga cuidado si ofrece acceso SSH a usuarios remotos, ya que involuntariamente podría permitirles compartir privilegios elevados con usted si deshabilita tty_tickets". de ask.debian.net/questions/…

— endolith

Ofrezco acceso SSH a un usuario remoto, pero es solo para mí, ¿así que supongo que esto no causa ninguna vulnerabilidad?

— endolito

5

Si nada más funciona, intente sudo -i(por sí mismo). Eso te dará un shell raíz después de una contraseña.

— Broam
fuente

66

gran punto pero un poco más arriesgado que la solicitud.

— mbb

Teniendo en cuenta que esta es la "forma de Ubuntu" para obtener una raíz, pensé que era una buena solución al problema. Todos los comandos aún están registrados.

— Broam

1

Sin embargo, en realidad no soluciona el problema, es básicamente una forma de ignorarlo.

— Zoredache

Esta es una solución alternativa en lugar de una solución, pero es buena y no me importa si automáticamente te da la mitad de la recompensa. :)

— endolith

1

Solo tuve que ingresar la contraseña una vez, y luego sería recordada por un período de tiempo.

Si supiera adivinar, apostaría a que algo sobre su /var/run/sudodirectorio está jodido. Este directorio es donde se almacenan los archivos de marca de tiempo. Tal vez / var / run está lleno, tal vez los permisos se han estropeado. De todos modos, mire ese directorio, sospecho que su problema puede estar allí.

Los permisos en mi carpeta se ven así.

# find /var/run/sudo/ -ls
1164242    4 drwx------   6 root     root         4096 Jan  1  1985 /var/run/sudo/
1179694    4 drwx------   2 root     www-data     4096 Jan  1  1985 /var/run/sudo/www-data
1164286    4 drwx------   2 root     myuser      4096 Jul 21 23:03 /var/run/sudo/myuser
1163399    0 -rw-------   1 root     myuser         0 Jul 13 22:42 /var/run/sudo/myuser/0
1163453    0 -rw-------   1 root     myuser         0 Jul 21 22:59 /var/run/sudo/myuser/2
1164309    0 -rw-------   1 root     myuser         0 Jul 21 23:03 /var/run/sudo/myuser/6
1163303    0 -rw-------   1 root     myuser         0 Jul 13 22:31 /var/run/sudo/myuser/5

Para una buena medida, también puede intentar ejecutar sudo -Kpara matar sus archivos de marca de tiempo actual.

— Zoredache
fuente

find: '/var/run/sudo': No such file or directory

— endolito el

Bueno, eso es una mala señal, ¿por qué no intentar crearlo y establecer la propiedad / permisos como se indica arriba?

— Zoredache

O simplemente podría reinstalar el paquete.

— Zoredache

reinstaló sudo con synaptic y todavía dice eso

— endolito el

Me sale lo mismo en un VirtualBox que ejecuta Ubuntu 10.10. no hay ninguna sudocarpeta en /var/run. En esta máquina virtual, recuerda mi contraseña como se esperaba, por lo que esto no parece relevante. Lo único en visudo en esta máquina virtual es Defaults env_reset. También dice en %sudo ALL=(ALL) ALLlugar de %sudo ALL=(ALL:ALL) ALL.

— endolito

0

Verificaría el directorio /etc/sudoers.d/.

También puede intentar degradar el paquete sudo a la versión anterior.

— Michał Šrajer
fuente