Добавление открытого ключа в~/.ssh / авторизованные ключи не входят в систему автоматически

SELinux также может заставить authorized_keys не работать. Особенно для root в CentOS 6 и 7. Не нужно отключать. После того, как вы проверили свои разрешения правильно, вы можете исправить это так:

chmod 700 /root/.ssh
chmod 600 /root/.ssh/authorized_keys
restorecon -R -v /root/.ssh

задание по SSH authorized_keys кажется простым, но скрывает некоторые ловушки, которые я пытаюсь понять

-- сервер --

на /и т. д./по ssh/sshd_config в set passwordAuthentication yes чтобы позволить серверу временно принять аутентификацию пароля

-- клиент --

считают cygwin как эмуляция linux и установка и запуск openssh

1. создание частных и открытые ключи (клиентская сторона) # ssh-keygen

здесь нажав просто введите вы получите по умолчанию 2 файлы "id_rsa" и "id_rsa.паб" в ~/.ssh/ но если вы дадите name_for_the_key сгенерированные файлы сохраняются в вашем pwd

2. место your_key.паб на целевой машине ssh-copy-id user_name@host_name

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

ssh-copy-id -i path/to/key_name.pub user_name@host_name

3. лесозаготовки ssh user_name@host_name будет работать только для id_rsa по умолчанию, так что вот 2-я ловушка для вас нужно ssh -i path/to/key_name user@host

(использовать ssh-v ... возможность увидеть, что происходит)

если сервер по-прежнему запрашивает пароль затем вы дали smth. к введите пароль: когда вы создали ключи ( так это нормально)

если ssh не прослушивает порт по умолчанию 22 должен использовать ssh -p port_nr

-- сервера -----

4. изменить /и т. д./по ssh/sshd_config в иметь

RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile  %h/.ssh/authorized_keys

(uncoment если случай)

это говорит ssh принять authorized_keys и искать в домашнем каталоге пользователя для key_name sting, написанного В.ssh / authorized_keys file

5 установить разрешения в target машина!--14-->

chmod 755 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

также выключите pass auth

passwordAuthentication no

чтобы закрыть ворота для всех SSH root / admin/....@ваш_домен попытки

6 убедитесь, что владение и групповое владение всеми некорневыми домашними каталогами являются подходящими.

chown -R ~ usernamehere
chgrp -R ~/.ssh/ user 

===============================================

7. рассмотрим excelent http://www.fail2ban.org

8. дополнительные ssh туннель для доступа к MySQL (bind = 127.0.0.1) разорвать

также убедитесь, что ваш домашний каталог не доступен для записи другим

chmod g-w,o-w /home/USERNAME

ответ украден из здесь

перечисление открытого ключа .ssh / authorized_keys необходим, но недостаточно для sshd (сервера), чтобы принять его. Если ваш закрытый ключ защищен парольной фразой, Вам нужно будет каждый раз давать SSH (client) парольную фразу. Или вы можете использовать ssh-agent или эквивалент gnome.

трассировка обновления соответствует закрытому ключу, защищенному парольной фразой. См. ssh-agent или ssh-keygen-p.

остерегайтесь, что SELinux также может вызвать эту ошибку, даже если все разрешения кажутся ок. Отключение его сделало трюк для меня (вставьте обычные оговорки об отключении его).

отчаянные также могут убедиться, что у них нет дополнительных новых строк в файле authorized_keys из-за копирования id_rsa.паб текст из запутанного терминала.

пользователь-ваше имя пользователя

mkdir -p /home/user/.ssh
ssh-keygen -t rsa
touch /home/user/.ssh/authorized_keys
touch /home/user/.ssh/known_hosts
chown -R user:user /home/user/.ssh
chmod 700 /home/user/.ssh
chmod 600 /home/user/.ssh/id*
chmod 644 /home/user/.ssh/id*.pub
chmod 644 /home/user/.ssh/authorized_keys
chmod 644 /home/user/.ssh/known_hosts

то, что сделало трюк для меня, наконец, было убедиться, что владелец/группа не были root, но пользователь:

chown -R ~/.ssh/ user
chgrp -R ~/.ssh/ user 

попробуйте "ssh-add", который работал для меня.

команду пишем:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

после того, как вы это сделаете, убедитесь, что ваш dir таков:

drwx------ 2 lab lab 4.0K Mar 13 08:33 .
drwx------ 8 lab lab 4.0K Mar 13 08:07 ..
-rw------- 1 lab lab  436 Mar 13 08:33 authorized_keys
-rw------- 1 lab lab 1.7K Mar 13 07:35 id_rsa
-rw-r--r-- 1 lab lab  413 Mar 13 07:35 id_rsa.pub

еще один совет, чтобы помнить. Начиная с v7.0 OpenSSH запрещает DSS/DSA ssh ключи по умолчанию из-за их наследования слабости. Поэтому, если у вас есть OpenSSH v7.0+, убедитесь, что ваш ключ не ssh-dss.

если вы застряли с ключами DSA, вы можете повторно включить поддержку локально обновление sshd_config и ~/.ssh/config файлы с такими строками:PubkeyAcceptedKeyTypes=+ssh-dss

убедитесь, что у целевого пользователя установлен пароль. Запустить passwd username установить один. Это было необходимо для меня, даже если пароль SSH login был отключен.

еще один вопрос, который вы должны позаботиться. Если созданный файл не используется по умолчанию id_rsa и id_rsa.pub

вы должны создать .ssh / config file и определите вручную, какой id-файл вы собираетесь использовать с подключением.

пример здесь:

host remote_host_name
hostname 172.xx.xx.xx
user my_user
IdentityFile /home/my_user/.ssh/my_user_custom.pub

в моем случае мне нужно было поставить мой на .openssh.

это местоположение указано в /etc/ssh/sshd_config согласно варианту AuthorizedKeysFile %h/.ssh/authorized_keys.

я издал sudo chmod 700 ~/.ssh и chmod 600 ~/.ssh/authorized_keys и chmod go-w $HOME $HOME/.ssh сверху, и это исправило мою проблему на коробке CentOS7, на которой я испортил разрешения, пытаясь заставить работать акции samba. Спасибо

это похоже на проблему с разрешением. Обычно это происходит, если разрешение некоторого файла / каталога настроено неправильно. В большинстве случаев они ~/.ssh и ~/.ssh/*. В моем случае они /home/xxx.

вы можете изменить уровень журнала sshd, изменив /etc/ssh/sshd_config(поиск LogLevel, установить DEBUG), затем проверьте выход в /var/log/auth.log чтобы увидеть, что произошло.

Это решает мою проблему

ssh-agent bash

ssh-add

убедитесь, что вы скопировали весь публичный ключ authorized_keys; the ssh rsa префикс необходим для работы ключа.

необходимо проверить свойства файлов. для назначения необходимого свойства используйте:

$ chmod 600 ~/.ssh/sshKey
$ chmod 644 ~/.ssh/sshKey.pub

на этой ноте убедитесь, что у конфигурации sshd есть -;

PermitRootLogin without-password

установите как указано выше, затем перезапустите sshd (/etc/init.перезапуск d/sshd)

выйдите из системы и попробуйте снова войти в систему!

по умолчанию я считаю -;

PermitRootLogin no

в моем случае это потому, что группа пользователя не установлена в AllowGroups файла конфигурации /etc/ssh/sshd_config. После добавления все работает нормально.

моей проблемой был модифицированный файл AuthorizedKeysFile, когда автоматизация для заполнения /etc/ssh / authorized_keys еще не была запущена.

$sudo grep AuthorizedKeysFile /etc/ssh/sshd_config
#AuthorizedKeysFile .ssh/authorized_keys
AuthorizedKeysFile  /etc/ssh/authorized_keys/%u

у меня есть домашний каталог в нестандартном месте и в sshd журналы у меня есть эта строка:

Could not open authorized keys '/data/home/user1/.ssh/authorized_keys': Permission denied

даже если все разрешения были в порядке (см. другие ответы).

Я нашел решение здесь: http://arstechnica.com/civis/viewtopic.php?p=25813191&sid=0876f069ec2aa5fdcd691a2e2e7242c2#p25813191

в моем конкретном случае:

• добавлена новая строка в /etc/selinux/targeted/contexts/files/file_contexts.homedirs:

  • это исходная строка для обычных домашних каталогов:

    /home/[^/]*/\.ssh(/.*)? unconfined_u:object_r:ssh_home_t:s0

  • это моя новая строка:

    /data/home/[^/]*/\.ssh(/.*)? unconfined_u:object_r:ssh_home_t:s0

• затем restorecon -r /data/ и sshd перезагрузка

просто посмотри на /var / log / auth.log на сервер. Установка дополнительной многословности с помощью - vv на стороне клиента не поможет, потому что сервер вряд ли предложит слишком много информации для возможного злоумышленника.

у меня была эта проблема, и ни один из других ответов не решил ее, хотя, конечно, другие ответы are правильно.

в моем случае, оказалось, что /root сам каталог (не например /root/.ssh) имели неправильные разрешения. Мне нужно было:

chown root.root /root
chmod 700 /root

конечно, эти разрешения должны быть чем-то вроде этого (возможно chmod 770) независимо от. Однако это специально помешало sshd работать, хотя /root/.ssh и /root/.ssh/authorized_keys как правильно разрешения и владельцы.