CentOS Scp без пароля не работает - PullRequest
Новая
       20

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

3 голосов
/ 09 марта 2011

Я пытался подключиться с одного 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

Ответы [ 7 ]

1 голос
/ 02 ноября 2012

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

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.

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

1 голос
/ 09 марта 2011

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

AuthorizedKeysFile     %h/.ssh/authorized_keys

Сервер ищет неправильный каталог для вашего сервера.

0 голосов
/ 06 февраля 2017

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

0 голосов
/ 08 февраля 2014

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

сначала измените мод доступа в папке .ssh удаленного хоста только для доступа пользователя. 

chmod 700 ~/.ssh

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

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

0 голосов
/ 04 ноября 2013

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

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

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

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

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

Работает!

Спасибо.Damian

0 голосов
/ 21 декабря 2011

Я думаю, что эта ссылка решит вашу проблему, и я использую ее, чтобы решить мою проблему с ssh not login.Ключевым моментом является запуск 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/

0 голосов
/ 09 марта 2011

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

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

...