Ogni volta che uso sudo si blocca prima del completamento

12

Indipendentemente dal fatto che mi venga richiesta una password o meno, dipende dall'accettazione dell'autenticazione e dall'esecuzione di ciò che ho richiesto. In altre parole, si sudo lsbloccherà per circa 60 secondi.

Sono confuso su ciò che potrebbe causare questo. Questo è su Centos 5, e l'ho visto selinuxe impostato sia su disabilitato che abilitato, ma non sembra avere alcun effetto.

linux centos sudo

— dlamblin
fonte

15

Dalla risposta di @ TheAndruu a questa domanda:

Ciò accade se si modifica il nome host durante il processo di installazione. Per risolvere il problema, modificare il file / etc / hosts

127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 [ADD_YOURS_HERE] 
:: 1 localhost localhost.localdomain localhost6 localhost6.localdomain6 [ADD_YOURS_HERE]

Ho avuto esattamente lo stesso problema su Fedora 11 e questo l'ha risolto.

— gareth_bowles
fonte

Ho appena fatto in modo che il mio $HOSTNAMEfosse in 127.0.0.1linea. Ha funzionato. Grazie.

— dlamblin,

1

BTW sudo lsutilizza la rete in che modo?

— dlamblin,

Questo ha funzionato anche per Ubuntu 16.04 - tranne per il fatto che dovevo cambiare il nome per 127.0.1.1 - 127.0.0.1 era localhost

— Bill Ryder,

1

A volte quando il percorso predefinito non è impostato, i comandi come sudo si bloccano.

Prova netstat -ra verificare se il percorso è impostato correttamente.

Questa macchina ottiene le sue password dal file / etc / passwd locale o qualcosa come ldap?

— egorgry
fonte

Non sta usando ldap; Penso che stia usando/etc/passwd

— dlamblin il

/etc/passwdnon è usato per auth, è usato per id per la risoluzione dei nomi. /etc/shadowviene utilizzato per l'autenticazione.

— LiraNuna,

1

L'unica altra cosa che potresti voler controllare è il tuo file /etc/resolv.conf per assicurarti di avere una voce dns corretta. Ho visto in passato dove ciò può causare ritardi.

— mike Sands
fonte

1

Dovresti controllare tre cose. 1. / etc / hostname 2. / etc / hosts 3. /etc/resolv.conf

Ho scoperto che il mio nome host era corretto, che il file hosts non era corretto e che il file resolv.conf doveva essere aggiornato.

— Paul J. Barrett
fonte

1

Per me era krb5-user / config da installare. Ho notato questo esaminando /var/log/auth.log e vedendo i tentativi di pam_krb5 prima di pam_unix. Usando apt-get remove per disinstallare quei pacchetti risolti. Non rimuovere quei pacchetti se ci si trova su un computer che richiede Kerberos (pam_krb5) ovviamente. Il mio hang sudo è passato da un costante 30s a 0s.

— Halsafar
fonte

1

Questo è accennato in Halsafar 's risposta , ho Kerberos abilitato sul mio lavoro di VPN, ma è inutile quando sono fuori di esso, così ho cambiato l'ordine del modulo di autenticazione in /etc/pam.d/common-authuso pam_unixprima di pam_krb5:

Prima:

auth [success=4 default=ignore] pam_krb5.so ...
auth [success=3 default=ignore] pam_unix.so ...

Dopo:

auth [success=4 default=ignore] pam_unix.so ...
auth [success=3 default=ignore] pam_krb5.so ...

Questo ha cambiato il mio sudo da 30 a 0 come nella risposta di Halsafar.

— dcmorse
fonte

0

Su Solaris 10 sudo è rimasto sospeso per circa 30 secondi. Con l'aiuto della capriata sono stato finalmente in grado di determinare che era appeso al comando quota che era appeso su un mount NFS. Smontare la condivisione NFS ha eliminato il blocco. Non ho ancora determinato cosa c'è che non va nella condivisione.

— otislafayette
fonte

0

In Fedora 30, Snapd fa sì che sudo, su, ecc. Diventino molto lenti e anche altri problemi relativi alla sessione.

La disinstallazione di snapd, se sei su Fedora, è un'alternativa consigliata.

— notcarlsatan
fonte