Fedora, SSH и Судо
Я должен запустить скрипт на нескольких машинах Fedora через ssh. Поскольку скрипт требует привилегий root, я делаю:
$ ssh me@remost_host "sudo touch test_sudo" #just a simple example
sudo: no tty present and no askpass program specified
Удаленные машины настроены таким образом, что пароль для sudo никогда не запрашивается. Для вышеуказанной ошибки наиболее распространенным решением является выделение псевдотерминала с -t
опция в ssh:
$ ssh -t me@remost_host "sudo touch test_sudo"
sudo: no tty present and no askpass program specified
Давайте попробуем форсировать это распределение -t -t
:
$ ssh -t -t me@remost_host "sudo touch test_sudo"
sudo: no tty present and no askpass program specified
Нет, это не работает.
В /etc/sudoers
конечно у меня есть эта строка:
#Defaults requiretty
... но я не могу вручную изменить это на десятках удаленных машин.
Я что-то здесь упускаю? Есть ли легкое исправление?
РЕДАКТИРОВАТЬ:
- Вот файл sudoers хоста, на котором
ssh me@host "sudo stat ."
работает. - Вот файл sudoers хоста, на котором он не работает.
РЕДАКТИРОВАТЬ 2: Бег tty
на хосте, где это работает:
$ ssh me@host_ok tty
not a tty
$ ssh -t me@host_ok tty
/dev/pts/12
Connection to host_ok closed.
$ ssh -t -t me@host_ok tty
/dev/pts/12
Connection to host_ok closed.
Теперь на хосте, где это не работает:
$ ssh me@host_ko tty
not a tty
$ ssh -t me@host_ko tty
not a tty
Connection to host_ko closed.
$ ssh -t -t me@host_ko tty
not a tty
Connection to host_ko closed.
РЕДАКТИРОВАТЬ 3 Разрешения для /dev/tty* на машине, где вышеописанное не работает:
$ stat /dev/tty*
File: `/dev/tty'
Size: 0 Blocks: 0 IO Block: 4096 character special file
Device: fd02h/64770d Inode: 17089401 Links: 1 Device type: 5,0
Access: (0666/crw-rw-rw-) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2013-12-11 11:44:01.000000000 +0000
Modify: 2013-12-11 11:44:01.000000000 +0000
Change: 2014-01-20 15:43:36.000000000 +0000
РЕДАКТИРОВАТЬ 4
Хорошо, так что в /var/log/
У меня есть следующее:
$ ls /var/log
btmp lastlog maillog messages secure spooler sudo tallylog wtmp yum.log
Я пробовал с messages
а также secure
, но они пусты. sudo
с другой стороны, содержит что-то... единственная проблема в том, что он отображает одно и то же сообщение журнала, использую ли я -t
, -t -t
или ничего:
Jun 4 17:38:52 : my_username : no tty present and no askpass program
specified ; TTY=unknown ; PWD=/home/my_username ; USER=root ;
COMMAND=/usr/bin/stat .
4 ответа
Попробуй это:
ssh root@remote_host "sed -ibak s/requiretty/\!requiretty/ /etc/sudoers"
ИЛИ еще лучше это:
echo 'Defaults:me !requiretty' > me
scp me root@remote:/etc/sudoers.d/
ssh me@remote whatever
* требуется один раз войти в систему с правами root *
Я бы написал скрипт, чтобы сделать то, что вам нужно (например, do_stuff.sh
), затем выполните его так:
ssh me@remote_host < do_stuff.sh
Вам может понадобиться ssh -t
там, но это эффективно выполняет do_stuff.sh
Сценарий удаленно без фактического копирования его на удаленные серверы.
У меня была такая же проблема при запуске команд sudo через агент zabbix. Чтобы решить мою проблему, я бросил следующий файл в sudoers.d
каталог.
# zabbix-specific additions to sudoers file
Cmnd_Alias ZABBIXCMDS = /usr/local/sbin/zabbix_user_*, /usr/local/sbin/zabbix_discovery_*
zabbix ALL=(ALL) NOPASSWD: ZABBIXCMDS
Defaults!ZABBIXCMDS !requiretty
Этот шаблон должен заботиться о ваших потребностях. Это не специфично для Zabbix, так что просто адаптируйте его к своему использованию - все части здесь.
Во-первых, я думаю, что вы, вероятно, решаете проблемы неправильно.
Если вы работаете с десятками удаленных машин, и вам нужно выполнять аналогичные действия на многих из них, и вы беспокоитесь о невозможности внесения изменений в конфигурацию вручную на них, то, похоже, пришло время приступить к использованию управления конфигурацией. Например, Puppet или Chef - более стандартные варианты. Или, может быть, Ansible, который имеет меньше установки на целевых машинах. Однако Ansible наиболее вероятно столкнется с той же проблемой.
Если вы хотите продолжить свой текущий подход, посмотрите на использование dsh для отправки команды в список машин. Вероятно, не поможет с проблемой sudo все же.
Это сказал...
Вы говорите, что "удаленные машины настроены таким образом, что пароль для sudo никогда не запрашивается", но похоже, что sudo хочет запросить пароль. Проверьте еще раз, что вы можете войти на эти машины, затем запустить sudo, и он работает нормально, без пароля. Если это работает, то проверьте, есть ли что-то другое в среде после входа в систему. Например, запустите 'ssh you@remotehost env' для хостов, где sudo работает и не работает.
Честно говоря, я больше озадачен тем, как sudo работает там, где вы говорите, чем работает, чем тем, как он терпит неудачу. Разве вы не должны использовать следующее?
my_account ALL=(ALL) NOPASSWD: ALL
Если не так, то как вы организовываете, чтобы не требовать пароль?