LINUX.ORG.RU
ФорумAdmin

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


0

0

Помогите, пожалуйста, вот с какой проблемой. Никак не получается настроить доступ root-у между узлами по ssh без пароля. ssh-keygen -t и т. д. прекрасно работает, но только для непривилегированных пользователей. Ключи для всех без исключения генерируются при входе в систему с помощью скрипта, лежащего в /etc/profile.d (из OSCAR 4.2):

#!/bin/sh
user=`whoami`
home=`getent passwd | egrep "^$user\:" | awk -F: '{print $6}' | tail -1`
cd $home

file=$home/.ssh/id_rsa
type=rsa
if [ ! -e $file ] ; then
echo generating ssh file $file ...
ssh-keygen -t $type -N '' -f $file
fi

id="`cat $home/.ssh/id_rsa.pub`"
file=$home/.ssh/authorized_keys
if ! grep "^$id\$" $file >/dev/null 2>&1 ; then
echo adding id to ssh file $file
echo $id >> $file
fi

chmod 600 $home/.ssh/authorized_keys*

Картина следующая: для root:
#ssh -v s-cl1-01
[cut]
debug1: Host 's-cl1-01' is known and matches the RSA host key.
debug1: Found key in /root/.ssh/known_hosts:2
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Offering public key: /root/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Offering public key: /root/.ssh/id_dsa
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: keyboard-interactive
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: password

Для пользователя всё прекрасно:
$ ssh -v s-cl1-01
[cut]
debug1: Host 's-cl1-01' is known and matches the RSA host key.
debug1: Found key in /home/kurylev/.ssh/known_hosts:1
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Offering public key: /home/kurylev/.ssh/id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 149 lastkey 0x96ed3b8 hint 1
debug1: read PEM private key done: type RSA
debug1: Authentication succeeded (publickey).
debug1: channel 0: new [client-session]
debug1: Entering interactive session.

У меня FC1, OpenSSH - из дистрибутива OpenSSH_3.6.1p2, SSH protocols 1.5/2.0, OpenSSL 0x0090701f


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

anonymous
()

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

VPF
()
Ответ на: комментарий от VPF

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

KWiNTO
() автор топика
Ответ на: комментарий от KWiNTO

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

VPF
()
Ответ на: комментарий от VPF

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

KWiNTO
() автор топика
Ответ на: комментарий от anonymous

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

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

KWiNTO
() автор топика
Ответ на: комментарий от KWiNTO

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

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

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

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

wt
()
Ответ на: комментарий от wt

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

KWiNTO
() автор топика
Ответ на: комментарий от KWiNTO

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

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

moonflyer
()

Возможно, ответ на твой вопрос кроется в этих комментариях, взятых мною из /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

VPF
()
Ответ на: комментарий от KWiNTO

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

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

wt
()

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

sdio ★★★★★
()
Ответ на: комментарий от wt

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

spirit ★★★★★
()
Ответ на: комментарий от VPF

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

KWiNTO
() автор топика
Ответ на: комментарий от moonflyer

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

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

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

KWiNTO
() автор топика
Ответ на: комментарий от spirit

>> У меня подобные задачи решаются скриптами с владельцами 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.

wt
()
Ответ на: комментарий от KWiNTO

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

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

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

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

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

wt
()
Ответ на: комментарий от wt

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

spirit ★★★★★
()
Ответ на: комментарий от wt

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

KWiNTO
() автор топика

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

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 надо дописывать, а не заменять

AnyKey
()
Ответ на: комментарий от spirit

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

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

wt
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.