Аутентификация Ключей SSH продолжает просить пароль
Вы могли бы взглянуть на Splunk для программного решения. Labs Q1 также делает аппаратные решения.
Хотя я должен признать, что немного удивлен, что способ, которым Вы в настоящее время делаете вещи, не может поддержать на высоком уровне.
Могло бы быть полезно быть более конкретным относительно Ваших потребностей (т.е.: # потенциальных транзакций, дополнительных типов файла журнала, и т.д.)
I don't think your keys have been properly copied, if you have ssh-copy-id available I would recommend you use that.
$ ssh-copy-id user@remote_server
Password:
Once you have entered the password, your SSH key will be copied over and you should be able to just ssh without providing the password again.
Also check your SSH configuration on ServerB and check a couple of things.
$ vi /etc/ssh/sshd_config
Another thing is to check these settings:
RSAAuthentication yes
PubKeyAuthentication yes
AuthorizedKeysFile %h/.ssh/authorized_keys
The value of AuthorizedKeysFile is where you need to paste your public ssh key.
You can collect your SSH-Key information by using: ssh-add -L
Updated
When ssh-copy-id doesn't exist you can do the old way:
$ cat ~/.ssh/id_rsa.pub | ssh user@remote_host 'cat >> /home/user/.ssh/authorized_keys'
Ваш журнал отладки показывает, что сервер не принял ни один из ваших личных ключей RSA. Вы должны либо указать конкретный правильный ключевой файл, либо проверить, что на сервере есть правильный файл открытого ключа.
Как сказал @Fredrik, разрешения на файлы также могут играть роль. SSH откажется использовать записи открытого ключа, которые другие могут записывать, и записи закрытого ключа, которые другие могут читать.
На основании вышесказанного я не могу сказать, в чем проблема. Однако в большинстве случаев я сталкивался с этим, причина заключалась в том, что для ключей были установлены права, которые были слишком удобочитаемыми (например, для чтения для группы или другого человека, а не только для пользователя). Вот где я бы начал искать.
These problems (which are usually permissions related) are much more easily debugged from the server side. I recommend that you start another sshd in debug mode with: /usr/sbin/sshd -d -p 2222 which will start another sshd on port 2222, then run ssh -p 2222 user@sshserver on the client side. Watch what comes out of the sshd when your client tries to authenticate.
Permissions problems don't have to be just /home/$USER/.ssh. it could also be a problem with /, /home, or /home/$USER. If any of those are group writable it can be a problem.
Another common problem is that you mis-paste and put linebreaks in the middle of your key in the authorized_keys file
Самый простой способ настроить ключи - запустить
ssh-copy-id <remotehost>
на машине, которая будет подключаться (например, на вашей рабочей станции).
Он должен запросить ваш пароль, а затем скопировать ваш ключ и настройте разрешения соответствующим образом.
Вы должны проверить права доступа к файлам на удаленном компьютере с помощью ls -l ~ / .ssh и установить разрешение:
chmod 600 ~ / .ssh / authorized_keys
chmod 600 ~ / .ssh / Пример: chmod 600 ~ / .ssh / id_rsa
chmod 700 ~ / .ssh / Пример: chmod 700 ~ / .ssh / id_rsa.pub
chmod 700 /home/vmirea/.ssh
Не забудьте указать это в ~/.ssh/config
Host *
ForwardAgent yes
# Or
Host yourhost
ForwardAgent yes