sudo continua a chiedermi la mia password in fish shell

19

sudo in Ubuntu continua a chiedermi la mia password per ogni comando. In precedenza, dovevo inserire la password una sola volta, quindi sarebbe stata ricordata per un periodo di tempo. Questo è cambiato di recente, probabilmente dopo "l'aggiornamento" a Natty.

Ho fatto sudo visudoe impostato Defaults env_reset, timestamp_timeout = 60, provato a riavviare, ma non funziona ancora. Come posso risolvere questo problema?

Dopo i suggerimenti di seguito, il mio /etc/sudoersaspetto è questo:

#
# 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

Aggiornare:

Ho aggiornato il mio VirtualBox e ha iniziato a soffrire dello stesso problema. A indovinare, ho eseguito bash, e ho provato a farlo, e la password è ricordata correttamente. E 'solo quando uso la mia shell di default di pesce che non ricorda. Lo ha fatto nella precedente versione di Ubuntu, ma non più.

Aggiornare:

Ho aggiornato alla 13.05 e questo ha magicamente iniziato a funzionare di nuovo. Ora richiede la mia password una volta, smette di chiedere per un po 'e poi chiede di nuovo dopo un periodo di tempo.

— endolith
fonte

possibile duplicato: superuser.com/questions/148665/…

— warren,

3

@warren: non è un duplicato. Dovrei essere tenuto a inserire la password, ma dopo averla inserita una volta, non è necessario per un determinato periodo di tempo. Ho cambiato questo periodo di tempo con visudo in passato, ma non funziona più.

— endolith,

Penso che devi usare più istruzioni Default, piuttosto che una comune separata.

— Stephanie,

@Stephanie, sono certo che avere una singola istruzione Default con valori separati da virgola funzioni bene.

— Zoredache,

vedo che hai aggiunto una riga come Defaults:endolith timestamp_timeout=60, ma non sei in nessun gruppo chiamato endolith, secondo un altro commento qui. quindi quale nome utente stai usando? Verificare con whoamie aggiungere quel nome utente al posto di endolithinDefaults:endolith timestamp_timeout=60endolith ALL=(ALL) NOPASSWD: ALL

— 25

15

@endolith: Sì, sembra influenzare solo i pesci. Ho avuto lo stesso problema, il problema è causato dall'opzione sudo "tty_tickets". Disabilitando questo nel tuo file / etc / sudoers risolverai il problema.

Quanto segue disabiliterà tty_tickets:

Defaults        env_reset,!tty_tickets

— Kadu
fonte

Questo ha delle conseguenze negative?

— endolith

1

"Fai attenzione se offri l'accesso SSH agli utenti remoti, poiché potresti inavvertitamente consentire loro di condividere privilegi elevati con te se disabiliti tty_tickets." da ask.debian.net/questions/...

— endolith

Offro l'accesso SSH a un utente remoto, ma è solo per me stesso, quindi presumo che ciò non causi alcuna vulnerabilità?

— endolith

5

Se nient'altro funziona, prova sudo -i(da solo). Questo ti darà una shell di root dopo una password.

— Broam
fonte

6

ottimo punto ma leggermente più rischioso della richiesta.

— mbb,

Considerando che questo è il "modo Ubuntu" per ottenere un roothell, ho pensato che fosse un bel lavoro intorno al problema. Ogni comando è ancora registrato.

— Broam,

1

In realtà non risolve il problema, è fondamentalmente solo un modo per ignorarlo.

— Zoredache,

Questa è una soluzione alternativa piuttosto che una soluzione, ma è buona e non mi dispiace se ti dà automaticamente la metà della taglia. :)

— endolith il

1

Ho dovuto inserire la password solo una volta, e poi sarebbe stata ricordata per un periodo di tempo.

Se dovessi indovinare, scommetterei che qualcosa nella tua /var/run/sudodirectory è rovinato. Questa directory è dove sono memorizzati i file timestamp. Forse / var / run è pieno, forse le autorizzazioni sono state rovinate. Comunque, guarda quella directory, sospetto che il tuo problema possa essere lì.

Le autorizzazioni sulla mia cartella sono simili a questa.

# 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

Per buona misura, potresti anche provare a correre sudo -Kper uccidere i tuoi file timestamp correnti.

— Zoredache
fonte

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

— endolith il

Bene, questo è un brutto segno, perché non provare a crearlo e impostare la proprietà / autorizzazioni come sopra.

— Zoredache,

Oppure potresti semplicemente reinstallare il pacchetto.

— Zoredache,

ha reinstallato sudo con synaptic e lo dice ancora

— endolito il

Ottengo la stessa cosa su un VirtualBox con Ubuntu 10.10. non c'è sudocartella in /var/run. In questa macchina virtuale, ricorda la mia password come previsto, quindi questo non sembra rilevante. L'unica cosa in visudo su questa macchina virtuale è Defaults env_reset. Dice anche %sudo ALL=(ALL) ALLinvece di %sudo ALL=(ALL:ALL) ALL.

— endolith,

0

Vorrei controllare la directory /etc/sudoers.d/.

Puoi anche provare a eseguire il downgrade del pacchetto sudo alla versione precedente.

— Michał Šrajer
fonte