Я только что установил новый сервер Debian. Я отключил root SSH и пароль для аутентификации, поэтому вам нужно использовать ключевой файл.
У моего основного пользователя все работает точно так, как ожидалось. я использовал ssh-keygen -t dsa и получил открытый и закрытый ключ. Поместите один в авторизованные ключи, а другой поместите в файл PEM локально.
Я хотел создать пользователя, с которым я мог бы что-то развертывать, поэтому я проделал в основном тот же процесс. я adduserиздал это, сделал .ssh папка, запустил ssh-keygen -t dsa (Я также пробовал RSA), поместите ключи в соответствующие места.
Не повезло. Я получаю Permission denied (publickey) ошибка. Когда я использую те же ключи, что и учетная запись, которая работает, возникает та же ошибка. Когда я включаю аутентификацию по паролю, я могу войти в систему через SSH с паролем.
Как мне отладить это?
РЕДАКТИРОВАТЬ
Подробный вывод ssh (deployer.pem - правильный ключ):
debug2: key: /Users/eli/.ec2/deployer.pem (0x100126830) debug2: key: /Users/eli/.ec2/deployer.pem (0x100126b30) debug2: key: /Users/eli/.ec2/deployer.pem (0x0) debug1: Authentications that can continue: publickey debug3: start over, passed a different list publickey debug3: preferred publickey,keyboard-interactive,password debug3: authmethod_lookup publickey debug3: remaining preferred: keyboard-interactive,password debug3: authmethod_is_enabled publickey debug1: Next authentication method: publickey debug1: Offering public key: /Users/eli/.ssh/id_rsa debug3: send_pubkey_test debug2: we sent a publickey packet, wait for reply debug1: Authentications that can continue: publickey debug1: Offering public key: eli.pem debug3: send_pubkey_test debug2: we sent a publickey packet, wait for reply debug1: Authentications that can continue: publickey debug1: Offering public key: /Users/eli/.ec2/deployer.pem debug3: send_pubkey_test debug2: we sent a publickey packet, wait for reply debug1: Authentications that can continue: publickey debug1: Offering public key: /Users/eli/.ec2/deployer.pem debug3: send_pubkey_test debug2: we sent a publickey packet, wait for reply debug1: Authentications that can continue: publickey debug1: Trying private key: /Users/eli/.ec2/deployer.pem debug1: read PEM private key done: type DSA debug3: sign_and_send_pubkey debug2: we sent a publickey packet, wait for reply debug1: Authentications that can continue: publickey debug2: we did not send a packet, disable method debug1: No more authentication methods to try. Permission denied (publickey).
Две части: во-первых, включите отладку на вашем ssh-сервере. редактировать /etc/ssh/sshd_config и увеличьте LogLevel до DEBUG. Затем заставьте свой ssh-сервер перезагрузить его конфигурацию с помощью killall -HUP <sshd pid>.
Это заставит сервер добавить гораздо больше деталей в ваш /var/log/secure и / или /var/log/auth лог-файлы.
Во-вторых (на самом деле вы не можете попробовать это сначала), увеличьте уровень отладки на стороне клиента. ssh в ящик с
$ ssh -vvv hostname
и это распечатает намного больше информации о том, где происходит сбой процесса.
Если вы все же увеличите уровень отладки на своем ssh-сервере, не забудьте вернуть его обратно, когда закончите.
Вы проверяли права доступа к файлам ключей? В .ssh/id_dsa файл должен быть 600 и принадлежать пользователю. Бегать ssh -v root@host чтобы узнать, не в этом ли проблема.
Если домашний каталог пользователя, каталог .ssh в домашнем каталоге пользователя или файл authorized_keys пользователя доступны для записи кем-либо, кроме пользователя (либо группы, либо другого), аутентификация ключа полностью завершится неудачно, потому что файл .ssh / authorized_keys не может больше доверять (поскольку другой пользователь может затем заменить или изменить его и, таким образом, войти в систему как этот пользователь).
Пытаться:
chmod go-w ~USER ~USER/.ssh ~USER/.ssh/authorized_keys
и посмотрите, решит ли это вашу проблему.
chown -R username. /home/username/.ssh
chmod 700 /home/username/.ssh
chmod 400 /home/username/.ssh/id_dsa /home/username/.ssh/id_dsa.pub
chmod 600 /home/username/.ssh/authorized_keys
Вот несколько советов, основанных на проблемах, с которыми я столкнулся, пытаясь заставить работать ssh через Pubkey Authentication, то есть ssh rsa:
в дополнение к приведенным выше советам (разрешения, -vvv): - на конечном сервере проверьте информацию об учетной записи с помощью passwd -S username или passwd -s username. Результат будет иметь вид [имя пользователя] [статистика] [pwchg] [min] [max] [предупреждение]. если в столбце [stat] указано LK, вам необходимо разблокировать учетную запись passwd -u username. если дата [pwchg] старше [max] дней, вам необходимо изменить максимальное количество дней или изменить пароль для имени пользователя с помощью passwd -x 999 или passwd username
пример:
# uname -n
myserver
# pwd
/export/home/santac
# ls -l .ssh
-rw------- 1 santac users 796 Jul 8 00:27 authorized_keys
# cat .ssh/authorized_keys
ssh-rsa AAABBBCCCboogaboogaAAABBBCCCidonthinkyougetthatthisisbogusbutwhattheheck== santac@otherserv
# date
Wed Jul 8 00:55:10 GMT 2015
# passwd -S santac
santac LK 03/05/14 7 60 10
(note stat is LK or locked)
# passwd -u santac
# passwd -S santac
santac PS 03/05/14 7 60 10
(note [pwchg] date is older than 60 days)
# passwd santac
Enter New Password:
Confirm New Password:
# passwd -S santac
santac PS 07/08/15 7 60 10
(all good now)
FROM THE OTHER SERVER:
# uname -n
otherserv
# pwd
/export/home/santac
# ls -l .ssh
-rw------- 1 santa users 1675 Jul 6 20:23 id_rsa
-rw------- 1 santa users 394 Jul 6 20:23 id_rsa.pub
# cat .ssh/id_rsa.pub
ssh-rsa AAABBBCCCboogaboogaAAABBBCCCidonthinkyougetthatthisisbogusbutwhattheheck== santac@otherserv
LOOKS GOOD...