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

Question

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

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

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

Answer 1

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

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

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

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

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

# adduser --disabled-password runscripts

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

# 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, потому что он доступен только как пользовательские скрипты, но люди могут запускать только заранее определенные скрипты с привилегиями этого пользователя.

Answer 2

Либо сгенерируйте ключ без ключевой фразы, либо создайте специальный скрипт, который будет считывать ключевую фразу с текущего терминала с помощью переменной 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)"

Answer 3

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

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

Answer 4

Вы сказали,

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

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

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

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

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

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