sudo для пользователей с пустыми паролями
Так или иначе новые драйверы Realtek препятствовали тому, чтобы eth1 был обнаружен!
Своего рода позор, так как, очевидно, драйверы ядра в дереве работали во-первых. Почему Вы устанавливали новые?
Если интерфейс обнаруживается с ifconfig, затем ядру загрузили драйвер для nic. Это не обязательно означает, что драйвер будет работать отлично на то, что Вы планируете сделать с ним, но в 99% + случаев, он будет. Realtek микросхемы Ethernet распространены и ядро, имеет много поддержки их.
Может казаться, что "лучший" драйвер для использования был бы драйвером от производителя, но я думаю, что это на самом деле обычно не верно. Проблема состоит в том, что производители имеют мало или ничто инвестированное в драйверы Linux - оба с точки зрения того, насколько оно имеет значение для них (очень мало, так как Linux имеет незначительную долю рынка), и, следовательно, сколько ресурсов они выделят ему. Далее:
Поскольку они не часть официального дерева ядра, нет никакого непосредственного участия с фактическим ядром devs. При значении почти любой клоун, возможно, сделал это. Они за пределами нормальной проверки и экспертной оценки и т.д.
Поскольку они - закрытый исходный код, никто не может посмотреть на код и сказать, "Это неправильно", и т.д. Так независимо от того, что ошибки, там скрыты от представления. Если существует некоторая проблема, и производитель не может быть побеспокоен, чтобы заплатить кому-то для поддержания драйвера правильно, никто больше не может подойти к пластине, потому что пластина выходит за пределы.
Короче говоря, нет никакого контроля продукта и никакого обязательства от людей если это. Linux devs является довольно явным об этом: лучший драйвер для использования является официальным драйвером в дереве, НЕ собственным. Только если собственный драйвер ядра не работает, должен Вы начинать смотреть в другом месте.
]Это была ошибка в моем PAM "auth" сценарии: сценарий заканчивался без получения "ok" или "done".[
]. Я не думаю, что это возможно, потому что sudo не будет знать, что у пользователя нет пароля или что это пустая строка, пока он ( sudo ) не представит пароль, пустой или другой, в модуль PAM для проверки. Поэтому перед продолжением всегда нужно будет запрашивать пароль у пользователя.
Единственный выход - настроить пользователей, которым не требуется пароль, с помощью параметра NOPASSWD в файле sudoers. Но это очень небезопасно, и я бы порекомендовал вам серьезно подумать о вашей конечной цели, прежде чем переходить к этому методу.
... так что я не забочусь о безопасности ...
Сначала установите "пустой" пароль
Эти вопросы и ответы U&L озаглавлены: Как создать пользователя без пароля? предложил использовать этот метод, который у меня сработал.
$ sudo passwd --delete samtest
Removing password for user samtest.
passwd: Success
Теперь проверьте это.
Теперь добавьте такую строку в ваш файл / etc / sudoers . ПРИМЕЧАНИЕ: Всегда редактируйте этот файл, используя sudo visudo .
samtest ALL=(ALL) NOPASSWD: ALL
Теперь попробуйте войти в систему как пользователь samtest без пароля.
$ su - samtest
$
Теперь попробуйте использовать эту учетную запись, используя sudo :
$ whoami
samtest
$ sudo echo
$
Хотите знать, почему sudo через консоль работает, хотя запрашивает пароль через SSH?
По крайней мере, в Ubuntu 16.04 политика по умолчанию в /etc/pam.d/common-auth содержит:
auth [success=1 default=ignore] pam_unix.so nullok_secure
Руководство pam_unix(8) указывает, что nullok_secure разрешает пустые пароли только при использовании одного из TTY в /etc /securetty. Если это ограничение нежелательно, можно заменить nullok_secure на nullok.
В качестве альтернативы можно разрешить одному конкретному пользователю использовать пустые пароли с помощью файла NOPASSWD sudoers, как описано в slm.