ssh для root без пароля

Может быть доступ root-у по ssh запрещен?

Из соображений безопасности root по умолчанию отключён в конфиге /etc/ssh/sshd_config -> PermitRootLogin -> no. Поставь yes, но это категорически не рекомендуется. Безопаснее войти по обычным пользователем и получить права root через команду su.

К сожалению, cat /etc/ssh/sshd_config | grep PermitRootLogin говорит: PermitRootLogin yes на обоих узлах. Что касается решения с su - оно не подходит т. к. для su потребуется вводить пароль, а мне как раз этого и надо избежать.

Может быть эта строка просто закомментированна. Что касается передачи пароля, так ведь он передаётся по шифрованному каналу, это везде так происходит. Почему такая боязнь?

Не, ну, если бы там было бы #PermitRootLogin yes grep, вроде бы, так бы и сказал: #PermitRootLogin yes. Что касается боязни - дело в том, что мне необходимо выполнять одинаковые команды на многих узлах (это легко делается, например, cexec-ом из c3), но вводить при этом 20 раз пароль root-а не сильно автоматизирует процесс. Единственное, что приходит в голову - дать через sudo права исполнять какому-нибудь фиктивному пользователю то, что надо, но это выглядит как обман трудящихся, а не как решение проблемы.

внимательно читаем man su и входим без ввода пароля

>внимательно читаем man su и входим без ввода пароля

Извините, anonymous, я не совсем осознал, как man su может мне помочь. Вы предлагаете на узлы заходить с помощью ssh от имени пользователя, там делать su и то, что нужно? su из пользователя в root не будет спрашивать пароль? Невероятно! Или в Вашем сообщении, все-таки, был заложен более глубокий смысл?

> Что касается решения с su - оно не подходит т. к. для su потребуется
> вводить пароль, а мне как раз этого и надо избежать.

вызывающе неверная информация(тм).
man sudo

Например:
dennis@beast:~
$ sudo su -
root@beast:~
#

у меня и однострочник где-то валяется, который пускает ssh и сразу после логина выполняет 'sudo su -'. Редко пользуюсь, sudo всяко удобнее.

Большое спасибо за совет. Примерно тоже самое я делал с sudo для пользователя maint, но ведь это тоже обходной маневр! Вопрос, собственно, заключался не в том, как выполнить что-нибудь с привилегиями root на удаленном узле (Ваше решение и решение с пользователем, которому можно делать всё через sudo помогают здесь), а как разрешить root-у заходить без пароля. Впрочем, я не знаю, почему одно лучше, чем другое, по-видимому, придется пользоваться sudo. Тем не менее, на второй вопрос ответ не ясен, хотя принципиально это возможно (приходилось наблюдать).

Если я не ошибаюсь, то есть така вещь как
sudo
в политике можно прописать NOPASSWD на разные действия, в.т. числе выполнение различных комманд. Дальше, надеюсь, можно додумать.

P.S. При первом запуске sudo чего-то спрашивает, дальше уже все делает молча.

Возможно, ответ на твой вопрос кроется в этих комментариях, взятых мною из /etc/ssh/sshd_config:

# Set this to 'yes' to enable PAM authentication, account processing, # and session processing. If this is enabled, PAM authentication will # be allowed through the ChallengeResponseAuthentication mechanism. # Depending on your PAM configuration, this may bypass the setting of # PasswordAuthentication, PermitEmptyPasswords, and # "PermitRootLogin without-password". If you just want the PAM account and # session checks to run without PAM authentication, then enable this but set # ChallengeResponseAuthentication=no #UsePAM no

> Вопрос... как разрешить root-у заходить без пароля
встречный вопрос: а зачем?
У меня подобные задачи решаются скриптами с владельцами root:wheel и правами 4750 (-rwsr-x---). Рутом даже становиться не надо. Как не нужно и sudo.

Заходить рутом удалённо не позволю никогда.

1. ---------------------------------------------------------
На сервере запусти sshd в debug режиме
sshd -d -e #вывод прямо на консоль
Сразу станет ясно что ему (sshd) не нравится.
2. ---------------------------------------------------------
Да и с клиента попробуй из под юзера зайти рутом на сервер
[kurylev]$ ssh -v root@s-cl1-01

> У меня подобные задачи решаются скриптами с владельцами root:wheel и правами 4750 (-rwsr-x---).
С каких это пор скрипты с suid битами запускаются под владельцем файла, а не под запустившим ???

Спасибо всем принявшим участие в обсуждении. По итогам дискуссии могу сформулировать два ответа: 1. делай так, как и делал (sudo), 2. используй setuid бит, но никогда ssh под root без пароля. Но возникает следующий, в чем-то связанный с предыдущим, вопрос: а как запретить определенному пользователю вход по ssh (с возможностью открывать ему такой доступ в определенное время)? Насколько я понимаю, это можно решить с помощью PAM, но документация по этому механизму мне показалась несколько невнятной, нет ли у кого готового решения?

>Если я не ошибаюсь, то есть така вещь как sudo в политике можно прописать NOPASSWD на разные действия, в.т. числе выполнение различных комманд. Дальше, надеюсь, можно додумать.

Спасибо, если бы Вы были чуть внимательнее, то заметили бы, что чуть раньше я писал, что именно так я и делаю в настоящий момент, а спрашивал я немного другое. Дальше можно додумать.

P.S.: При первом запуске sudo может ничего и не спрашивать, если сильно этого захотеть.

>> У меня подобные задачи решаются скриптами с владельцами root:wheel и правами 4750 (-rwsr-x---).
> С каких это пор скрипты с suid битами запускаются под владельцем файла, а не под запустившим ???
Отрывок из пособия по юниксу для начинающих:

A so-called setuid piece of software changes the effective user ID whilst it is being run, typically software is setuid(root) allowing the command to be run by a normal user as if it was being invoked by the superuser, root.

/usr/bin/passwd is traditionally a setuid binary, it runs as the root user so that it may update the system wide password file regardless of who invokes it.

Similarly setgid affects the effective group identity of the user who invokes it. For the duration of the command the user is treated as if they are a member of the given group.

> Насколько я понимаю, это можно решить с помощью PAM,
> но документация по этому механизму мне показалась несколько невнятной,
> нет ли у кого готового решения?

не PAM, но готовое и работает:

скрипт из рутового кронтаба:
#! /bin/sh

for i in `cat /home/dennis/local/workers.txt`
do
/usr/bin/chsh -s /bin/false $i
done

в файлике перечислены пользователи.

2 wt: прошу не путать готовые бинарники (типа /usr/bin/passwd) и скрипты ! При запуске бинарника, запускается он сам, при запуске скрипта - его интерпретатор (/bin/bash, /usr/bin/perl, ...), на котором нет suid бита и которому по барабану есть ли suid на текстовом скрипте. Так что пока незачет ! А если у вас на подобных интерпретаторах стоят suid, тогда вдвойне незачет !

>скрипт из рутового кронтаба: [cut]

Ну что ж, и на этом спасибо, правда, это не то, на что я рассчитывал. В конце концов, мне надо следующее: по умолчанию вход по ssh запрещен, а при наступлении определенного события кто-то с правами root заходит на удаленный узел и разрешает вход на него по ssh для определенного пользователя, а потом возвращает всё назад. Для rsh - очевидно надо править /etc/hosts.equiv, а вот как это примерно аналогично сделать для ssh?

Пардон, забыл залогиниться, итак:

>скрипт из рутового кронтаба: [cut] Ну что ж, и на этом спасибо, правда, это не то, на что я рассчитывал. В конце концов, мне надо следующее: по умолчанию вход по ssh запрещен, а при наступлении определенного события кто-то с правами root заходит на удаленный узел и разрешает вход на него по ssh для определенного пользователя, а потом возвращает всё назад. Для rsh - очевидно надо править /etc/hosts.equiv, а вот как это примерно аналогично сделать для ssh?

Ну не знаю почему у тебя не работает... У меня всё по умолчанию настроено и вот так всё на ура катит:

user@ws ~ $ ssh-keygen -t dsa

user@ws ~ $ scp .ssh/id_dsa.pub root@server:/root/.ssh/authorized_keys
password: ********

user@ws ~ $ ssh server -lroot

server ~ #


Естественно, что с нескольких хостов на сервак так ходить то .ssh/authorized_keys надо дописывать, а не заменять

моя вина, нечётко выразился.

под "скриптами" в данном конкретном случае понимался результат работы perlcc.