sudo fica me pedindo minha senha com casca de peixe

19

O sudo no Ubuntu continua me pedindo minha senha para cada comando. Antes, eu só precisava digitar a senha uma vez e, depois, ela seria lembrada por um período de tempo. Isso mudou recentemente, provavelmente após a "atualização" para o Natty.

Eu já fiz sudo visudoe configurei Defaults env_reset, timestamp_timeout = 60, tentei reiniciar, mas ainda não está funcionando. Como faço para corrigir isso?

Após as sugestões abaixo, minha /etc/sudoersaparência fica assim:

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

Atualizar:

Atualizei meu VirtualBox e ele começou a sofrer do mesmo problema. No palpite, executei o bash e tentei sudo nisso, e a senha é lembrada corretamente. É só quando eu uso o meu shell padrão de peixe que ele não se lembra. Foi o que aconteceu no lançamento anterior do Ubuntu, mas não mais.

Atualizar:

Atualizei para 13.05 e isso magicamente começou a funcionar novamente. Agora ele pede minha senha uma vez, para de pedir um tempo e depois pergunta novamente após um período de tempo.

— endólito
fonte

possível duplicado: superuser.com/questions/148665/…

— warren

3

@warren: Isso não é duplicado. Eu deveria ser solicitado a digitar a senha, mas depois de inseri-la uma vez, não preciso por um determinado período de tempo. Eu mudei essa quantidade de tempo com o visudo no passado, mas não está mais funcionando.

— endolith 21/07

Eu acho que você precisa usar várias instruções padrão, em vez de uma comum separada.

— 22711 Stephanie

@ Stephanie, tenho certeza de que ter uma única instrução Padrões com valores separados por vírgula funciona bem.

— Zoredache

Vejo que você adicionou uma linha como Defaults:endolith timestamp_timeout=60, mas você não está em nenhum grupo chamado endólito, de acordo com outro comentário aqui. então, qual nome de usuário você está usando? Verifique com whoami, e adicionar o nome de usuário no lugar de endolithem Defaults:endolith timestamp_timeout=60ouendolith ALL=(ALL) NOPASSWD: ALL

— Wim

15

@ endolith: Sim, parece apenas afetar peixes. Eu tive o mesmo problema, o problema é causado pela opção sudo "tty_tickets". Desabilitar isso no seu arquivo / etc / sudoers resolverá o problema.

O seguinte desabilitará o tty_tickets:

Defaults        env_reset,!tty_tickets

— Kadu
fonte

Isso tem ramificações negativas?

— endolith

1

"Tenha cuidado se você oferecer acesso SSH a usuários remotos, pois você pode acidentalmente permitir que eles compartilhem privilégios elevados com você se você desativar o tty_tickets." de ask.debian.net/questions/...

— endolith

Eu ofereço acesso SSH a um usuário remoto, mas é apenas para mim, portanto, presumo que isso não cause nenhuma vulnerabilidade?

— Endolith

5

Se nada mais funcionar, tente sudo -i(por si só). Isso lhe dará um shell raiz após uma senha.

— Broam
fonte

6

ótimo ponto, mas um pouco mais arriscado que o pedido.

— mbb

Considerando que este é o "caminho do Ubuntu" para obter um enraizamento, achei que era um trabalho arrumado em torno do problema. Todo comando ainda está registrado.

— Broam

1

Isso realmente não resolve o problema, é basicamente apenas uma maneira de ignorá-lo.

— Zoredache

Esta é uma solução alternativa, e não uma solução, mas é boa e não me importo se isso lhe der automaticamente metade da recompensa. :)

— endolith 26/07

1

Eu só precisei digitar a senha uma vez e, depois, ela seria lembrada por um período de tempo.

Se eu adivinhar, aposto que algo sobre o seu /var/run/sudodiretório está errado. Este diretório é onde os arquivos de carimbo de data / hora são armazenados. Talvez / var / run esteja cheio, talvez as permissões tenham sido erradas. De qualquer forma, olhe para o diretório, suspeito que seu problema possa estar lá.

As permissões na minha pasta são assim.

# 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

Por uma boa medida, você também pode tentar executar sudo -Kpara matar seus arquivos de carimbo de data / hora atuais.

— Zoredache
fonte

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

— Endolith

Bem, isso é um mau sinal, por que não tentar criá-lo e definir a propriedade / permissões como acima.

— Zoredache

Ou você pode apenas reinstalar o pacote.

— Zoredache

reinstalou o sudo com synaptic e ainda diz isso

— endolith

Eu recebo a mesma coisa em um VirtualBox executando o Ubuntu 10.10. não há nenhuma sudopasta /var/run. Nesta máquina virtual, ele lembra minha senha conforme o esperado, portanto isso não parece relevante. A única coisa no visudo nesta máquina virtual é Defaults env_reset. Também diz em %sudo ALL=(ALL) ALLvez de %sudo ALL=(ALL:ALL) ALL.

— endolith

0

Eu verificaria o diretório /etc/sudoers.d/.

Você também pode tentar fazer o downgrade do pacote sudo para a versão anterior.

— Michał Šrajer
fonte