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

522
robross0606

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

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

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

5
Вы вводили ключевую фразу, когда генерировали ключ? DanteTheEgregore 10 лет назад 0

4 ответа на вопрос

3
Juliane Holzt

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

0
DanteTheEgregore

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

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

0
LSerni

You said,

as one of those same users

so I take it we're talking about more than one user.

If I'm correct, what it seems to me could be happening is this:

  • you log on to A as user foo
  • user bar on machine B has in B:/home/bar/.ssh/authorized_keys the public key of foo, whose identity is in A:/home/foo/.ssh/identity.rsa.
  • so of course foo from A can issue ssh bar@B and have it work passwordlessly.

Now if user bar from machine C logs onto machine A as himself ("one of those same users"), i.e. as bar, he becomes bar@A; not foo@A. And when he tries to log as bar@B, the identity key that is retrieved by ssh to perform the login is bar's; it is not A:/home/foo/.ssh/identity.rsa, but A:/home/bar/.ssh/identity.rsa . And maybe that file is locked by a passphrase.

So: check your users and what identities they are using.

0
kenorb

Either generate the key without a passphrase or create a special script which would read the passphrase from the current terminal by using SSH_ASKPASS variable. This is particularly useful when calling ssh-add from a related script. For example:

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

Notes:

  • Creating .ps script is just one-time work, the rest can be added into your rc files.
  • It won't work if ssh have a terminal associated with or DISPLAY is set.
  • In case your ssh-agent is not running, if not - run: eval "$(ssh-agent -s)"

Похожие вопросы