Modern linux sistemlerinde, neden pam_unix.so böyle bir gecikmeye neden oluyor. Önceden bildirildiği gibi, bu değiştirerek iki saniye aşağı yapılandırılabilir FAIL_DELAYiçinde /etc/login.defs. Gecikmeyi daha da azaltmak istiyorsanız, "nodelay" seçeneğini pam_unix.so'ya vermelisiniz. Örneğin, sistemimden başlayarak dahil edilenleri /etc/pam.d/sudoizlerseniz, aşağıdaki satırları düzenlemek zorunda olduğunuzu görürsünüz /etc/pam.d/system-auth:
auth required pam_unix.so try_first_pass nullok
ve bunu şu şekilde değiştirin:
auth required pam_unix.so try_first_pass nullok nodelay
Ne yazık ki, linux distro'mun (arch) sshd tarafından kullanılan, aynı system-authdosyanın içerdiği şeyleri yapılandırma şekli system-remote-login.
Sudo'daki gecikmeyi ortadan kaldırmak güvenli olsa da, bu kaydedildi, yalnızca yerel kullanıcılar tarafından kullanıldı ve yine de yerel saldırganlar tarafından atlanabilir, muhtemelen uzaktaki girişler için bu gecikmeyi ortadan kaldırmak istemezsiniz. Elbette, yalnızca paylaşılan sistem-auth dosyalarını içermeyen özel bir sudo yazarak düzeltebilirsiniz.
Şahsen, sudo'daki gecikmeyi (ve SIGINT'i görmezden gelmeyi) büyük bir hata olduğunu düşünüyorum. Bu, şifreyi yanlış yazdıklarını bilen kullanıcıların işlemi öldüremediğini ve sinirlenemediğini gösterir. Tabii ki, sudo SIGTSTP'yi yakalamadığı için hala Ctrl-Z ile sudo durdurabilirsiniz ve durduktan sonra -9 ile öldürebilirsiniz (SIGKILL). Sadece yapmak can sıkıcı. Bu, otomatik bir saldırının sözde terminallerdeki sudoları çok yüksek bir hızda ateşleyebileceği anlamına gelir. Ancak gecikme meşru kullanıcıları rahatsız ediyor ve tekrar sudo yapmaktan kaçınmak için onları terk etmek yerine kök kabuklarını askıya almalarını teşvik ediyor.