CentOS scp без пароля не работает

Я пытался подключиться с одного экземпляра EC2 к другому, используя открытые ключи ssh, и у меня были очень тяжелые времена.

Вот сценарий: мне нужно иметь ящик 2 scp файл из ящика 1 в скрипте. Этот скрипт должен иметь возможность использовать scp без пароля, поэтому мне нужно настроить открытые ключи.

На ящике 2 я запустил ssh-keygen –t rsa и сгенерировал id_rsa и id_rsa.pub Я скопировал id_rsa.pub в ящик 1 Я переместил id_rsa.pub в .ssh и запустил cat id_rsa.pug >> authorized_keys Я изменил разрешения для всех каталогов .ssh на 700 для обоих ящиков и самих файлов до 600. Я изменил настройки sshd_config в поле 1 на:

RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile      .ssh/authorized_keys

А потом перезапустил ssh

/sbin/service sshd restart

Когда я пытаюсь запустить scp или ssh в box1 из box1, я получаю сообщение об ошибке:

Address 67.22.33.1 maps to ec2-67-22-33-1.compute-1.amazonaws.com, but this does not map back to the address - POSSIBLE BREAK-IN ATTEMPT!
tomcat@tomcat1.****.com's password:

Любые идеи?

Я внес это изменение и попытался использовать scp для tomcat1, но это не удалось. Вот результат:

debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to tomcat1.****.com [67.22.33.15] port 22.
debug1: Connection established.
debug1: identity file /home/tomcat/.ssh/identity type -1
debug1: identity file /home/tomcat/.ssh/id_rsa type 1
debug1: identity file /home/tomcat/.ssh/id_dsa type -1
debug1: loaded 3 keys
debug1: Remote protocol version 2.0, remote software version OpenSSH_4.3
debug1: match: OpenSSH_4.3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.3
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
The authenticity of host 'tomcat1.****.com (67.22.33.15)' can't be established.
RSA key fingerprint is 5a:3e:fe:be:b8:0e:05:63:bf:ab:c8:4f:e5:91:db:a0.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'tomcat1.****.com,67.22.33.15' (RSA) to the list of known hosts.
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
debug1: Next authentication method: publickey
debug1: Trying private key: /home/tomcat/.ssh/identity
debug1: Offering public key: /home/tomcat/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /home/tomcat/.ssh/id_dsa
debug1: Next authentication method: password

ssh amazon-web-services amazon-ec2 centos public-key
person matsientst    schedule 09.03.2011    source источник
comment
Для какого пользователя вы настроили авторизованные ключи. На удаленном блоке это должно быть для пользователя, которого вы пытаетесь подключить. Авторизованный ключ для root работает НЕ со всеми пользователями.   -  person Tyler Eaves    schedule 09.03.2011
comment
Вы изменили ssh_config блока 2, чтобы ssh попытался выполнить аутентификацию по ключу?   -  person Erik    schedule 09.03.2011
comment
Кроме того, я бы запустил scp с флагом -v, чтобы получить подробный вывод. Это очень полезно при отладке.   -  person Rob Di Marco    schedule 09.03.2011
comment
Как вы меняете конфигурацию, чтобы попытаться использовать pubkey?   -  person matsientst    schedule 09.03.2011

Ответы (7)


arrow_upward
1
arrow_downward

Ваша авторизованная строка ключей должна быть

AuthorizedKeysFile     %h/.ssh/authorized_keys

Сервер ищет не в том каталоге для вашего сервера.

person Tyler Eaves    schedule 09.03.2011
comment
Спасибо за этот улов. Я внес это изменение в свой /etc/ssh/sshd_config и перезапустил /sbin/service sshd restart, но я все еще не могу подключиться. - person matsientst; 09.03.2011

arrow_upward
1
arrow_downward

ОБНОВЛЕНИЕ – ИСПРАВЛЕНО

restorecon -R -v -d /root/.ssh

Это известная проблема с RH, когда каталоги неправильно помечаются, а PAM не позволяет sshd читать author_hosts при запуске в качестве сценария инициализации. Вы увидите ошибки, если наткнетесь на /var/log/audit/audit.log. Редко это кажется, но больно, когда это происходит!

Подробнее на https://bugzilla.redhat.com/show_bug.cgi?id=499343< /а>

ИСХОДНОЕ СООБЩЕНИЕ

Я только что столкнулся с тем, что похоже именно на эту проблему. У меня был плохо настроенный VirtualBox (я не сказал vbox использовать 64-битную версию), который, когда я клонировал и перезапустил (в 64-битном режиме vbox RedHat), начал запрашивать у меня пароль.

Исходное изображение было в порядке — с идентичными настройками — поэтому я думаю, что предположение о том, что оно связано с сетью, может быть уместным или связано с серверными ключами.

Странная вещь, однако, заключается в том, что если я убиваю процесс sshd, который запускается автоматически, а затем вручную запускаю /usr/sbin/sshd от имени пользователя root, я могу войти в систему без пароля. Глупый обходной путь, но его можно использовать.

Так что это проблема /etc/init.d/sshd. Но я не смог отследить, что это такое... пытался выкинуть большую часть материала из этого скрипта, но он по-прежнему запрашивает пароль при вызове как /etc/init.d/sshd start, но не при вызове /usr/sbin/sshd.

Может быть, эти комментарии могут помочь, и кто-то может помочь дальше!?

person Partly Cloudy    schedule 02.11.2012

arrow_upward
0
arrow_downward

Попробуйте удалить IP-адрес box1 из ~/.ssh/known_hosts, чтобы он обновился. Возможно, ssh отключает аутентификацию по ключу из-за возможной атаки «человек посередине».

Если это не поможет, добавьте строку GSSAPIAuthentication no в файл /etc/ssh/ssh_config.

person Dmitry Alexeyev    schedule 09.03.2011
comment
его вывод отладки не упоминает GSS. Я не думаю, что это проблема. - person eaykin; 19.04.2012

arrow_upward
0
arrow_downward

Я думаю, что эта ссылка решит вашу проблему, и я использую ее, чтобы решить мою проблему с входом в систему по ssh. Ключевым моментом является запуск ssh root@node02 'restorecon -R -v /root/.ssh', эта команда исправит SE http://blog.firedaemon.com/2011/07/27/passwordless-root-ssh-public-key-authentication-on-centos-6/

person Tom Shen    schedule 21.12.2011

arrow_upward
0
arrow_downward

После выполнения предыдущих шагов мне пришлось установить разрешение «..» в папке .ssh:

Однажды у меня было для ~/.ssh:

drwx------ 2 build build 4096 4 ноября 14:35 .

drwx------ 6 build build 4096 4 ноября 14:34 ..

-rw------- 1 build build 400 4 ноября 14:35 авторизованные_ключи

Это сработало!

Спасибо. Дамиан

person user2952887    schedule 04.11.2013

arrow_upward
0
arrow_downward

У меня была точно такая же проблема, и я чесал голову весь день. Оказалось, что это небольшая проблема с файлом sshd_config.

во-первых, измените мод доступа в папке .ssh на удаленном хосте на доступ только пользователя.

chmod 700 ~/.ssh

затем перейдите в /etc/ssh/sshd_config, измените StrictModes yes на StrictModes no. Если он закомментирован, то специально добавьте StrictModes no в файл.

Это решило проблему.

person ssgao    schedule 08.02.2014

arrow_upward
0
arrow_downward

И еще одна вещь, которую я только что обнаружил, мне пришлось отредактировать файл .ssh/authorized_keys и сделать полное имя хоста. В противном случае я не мог бы использовать полное имя в команде scp/ssh. Теперь работают как полное (например, «host.company.com»), так и относительное имя («host»), учитывая, что оба хоста находятся в домене «company.com». ssh-keygen создал файл открытого ключа только с именем хоста.

person SoloPilot    schedule 06.02.2017