SSH без пароля не работает с терминала, когда мне предлагают ввести пароль RSA

Мы установили коробку CentOS 6.4 с SSH без пароля для нескольких других систем. Это прекрасно работает при использовании терминала в качестве правильного пользователя непосредственно на компьютере CentOS. Однако, если я войду в систему CentOS как один из тех же пользователей из другой системы, мне будет предложено ввести ключевую фразу RSA. Почему это необходимо, когда я вошел в систему как правильный пользователь?

Итак, если у нас есть три машины (A, B и C). A был настроен таким образом, что он может без пароля устанавливать соединение с машиной B по SSH. Это отлично работает. Однако, если мы подключаем SSH к A с компьютера C, а затем с этого удаленного терминала SSH пытаемся подключиться по SSH к B, для этого требуется пароль.

На машине А есть скрипты, которые обращаются к нескольким другим машинам (без пароля). Нам нужно иметь возможность удаленно войти в систему компьютера A с компьютера C, а затем запустить сценарии, которые обращаются к компьютеру B.

Источник

4 ответа

Ваш вопрос несколько неясен. Похоже, что вы используете ключ SSH, но ключ SSH защищен парольной фразой. Но тогда он должен на самом деле попросить вас эту фразу-пароль также, когда вы вошли в систему напрямую.

Что бы я сделал:

  1. Создайте специального пользователя (назовем его "runcripts") на компьютере A, который используется для запуска сценариев.
  2. Для этого пользователя создайте ключ SSH, который не зашифрован парольной фразой.
  3. Сконфигурируйте sudo, чтобы позволить "обычным" пользователям на машине A выполнять эти сценарии с правами пользователя "runcripts" и без необходимости вводить пароль.

Вот полный пример того, как это настроить:

Создайте нового пользователя, в которого невозможно войти (в моей системе это также создаст новую группу с тем же именем, которое я буду использовать в следующем):

# adduser --disabled-password runscripts

Станьте этим пользователем и создайте ключ ssh. Не устанавливайте ключевую фразу на ключе, просто нажмите Enter в ответ на приглашение.

# su runscripts
$ ssh-keygen

Добавьте открытый ключ (в ~/.ssh/id_rsa.pub) к авторизованным ключам на целевой машине (машина B в вашем примере), затем коротко попробуйте войти по ключу SSH (который также добавит удаленный открытый ключ к известному_хосту, так что это не подскажет позже).

$ ssh remoteuser@remote.host

Вернитесь к машине A: добавьте обычные учетные записи пользователя в группу:

# adduser kju runscripts

Создайте какой-нибудь скрипт, который будет использовать ключ SSH и что-то сделать на B:

# cat > /usr/local/bin/script1
#!/bin/sh
echo -n "Running as "
whoami
ssh remoteuser@machineB whoami
^D
# chmod +x /usr/local/bin/script1

Наконец, разрешите пользователям в групповых сценариях выполнения выполнять этот сценарий как пользовательский сценарий выполнения без пароля. Это строка из / etc / sudoers:

%runscripts  ALL=(runscripts) NOPASSWD:/usr/local/bin/script1

Теперь, когда один из пользователей в группе запускает скрипты, попробуйте запустить скрипт:

$ sudo -u runscripts /user/local/bin/script1
Running as user runscripts
remoteuser
$

Как видно из этого вывода, сценарий выполнялся как пользовательские сценарии выполнения. Затем он вошел на компьютер B как пользователь "remoteuser" и выполнил команду "whoami" (которая затем, конечно, вернула "remoteuser").

Такое действие имеет то преимущество, что никто не сможет украсть (незащищенный) ключ SSH, потому что он доступен только как пользовательские скрипты, но люди могут запускать только предопределенные сценарии с привилегиями этого пользователя.

Источник

Либо сгенерируйте ключ без ключевой фразы, либо создайте специальный скрипт, который будет считывать ключевую фразу с текущего терминала с помощью SSH_ASKPASS переменная. Это особенно полезно при вызове ssh-add из связанного скрипта. Например:

install -vm700 <(echo "echo 'my_passphrase'") $HOME/.ps
cat /path/id_rsa | ssh-add DISPLAY= SSH_ASKPASS=$HOME/.ps -

Заметки:

  • Создание .ps Скрипт - это просто разовая работа, остальное можно добавить в ваши rc файлы.
  • Это не сработает, если ssh иметь терминал, связанный с или DISPLAY установлено.
  • Если ваш ssh-агент не запущен, если нет - запустите: eval "$(ssh-agent -s)"
Источник

Вам нужно сгенерировать ключ без ключевой фразы и использовать аутентификацию с открытым ключом, если вы хотите избежать этого. Сделать что-то вроде:

a@A:~> ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/a/.ssh/id_rsa): 
Created directory '/home/a/.ssh'.
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/a/.ssh/id_rsa.
Your public key has been saved in /home/a/.ssh/id_rsa.pub.
The key fingerprint is:
3e:4f:05:79:3a:9f:96:7c:3b:ad:e9:58:37:bc:37:e4 a@A

Другими словами, просто нажмите Enter, когда он предложит вам Enter passphrase (empty for no passphrase):

https://hkn.eecs.berkeley.edu/~dhsu/ssh_public_key_howto.html

Источник

Вы сказали,

как один из тех же пользователей

я так понимаю, мы говорим о нескольких пользователях.

Если я прав, то, как мне кажется, могло произойти следующее:

  • вы входите в систему как пользователь foo
  • пользователь bar на машине Б имеет в B:/home/bar/.ssh/authorized_keys открытый ключ foo чья личность находится в A:/home/foo/.ssh/identity.rsa,
  • так конечно foo из А может выдать ssh bar@B и заставить его работать без пароля.

Теперь, если пользователь bar с машины C входит на машину A как он сам ("один из тех же пользователей"), то есть как bar, он становится bar@A; не foo@A, И когда он пытается войти как bar@B, идентификационный ключ, который извлекается ssh выполнить логин bar "S; это не A: / home / foo /.ssh/identity.rsa, а A: / home / bar /.ssh/identity.rsa. И, возможно, этот файл заблокирован парольной фразой.

Итак: проверьте ваших пользователей и какие личности они используют.

Источник
Другие вопросы по тегам