Я много искал по этой проблеме и не нашел ничего особенно актуального.
У меня много экземпляров, распределенных по зонам и сгруппированных в различные балансировщики нагрузки. Одна из групп - это «API», используемый различными приложениями для общих и безопасных задач.
В группе API у нас есть один экземпляр, который использует эластичный IP, чтобы мы могли надежно использовать crons для таких задач, как rsync и т.д. код если еще лесной моды ... короче, очень важный экземпляр.
Два дня назад я внезапно не смог подключиться к этому парню по SSH (он был создан более года назад). Ключ pem работает во ВСЕХ других экземплярах, которые существуют примерно такое же количество времени.
Это результат неудачных попыток подключения на домашнем компьютере (вчера) с использованием ssh -v -i путь / file.pem user @ ip
ssh -v -i <path>/<file>.pem <user>@<ip>
OpenSSH_5.8p1 Debian-7ubuntu1, OpenSSL 1.0.0e 6 Sep 2011
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to <ip> [<ip>] port 22.
debug1: Connection established.
debug1: identity file /home/<user>/.ssh/id_rsa type -1
debug1: identity file /home/<user>/.ssh/id_rsa-cert type -1
debug1: identity file /home/<user>/.ssh/id_dsa type -1
debug1: identity file /home/<user>/.ssh/id_dsa-cert type -1
debug1: identity file /home/<user>/.ssh/id_ecdsa type -1
debug1: identity file /home/<user>/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.9p1 Debian-5ubuntu1
debug1: match: OpenSSH_5.9p1 Debian-5ubuntu1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.8p1 Debian-7ubuntu1
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA 75:43:6d:03:43:f5:89:fa:8d:fe:64:e1:39:9a:73:26
debug1: Host '<ip>' is known and matches the ECDSA host key.
debug1: Found key in /home/<user>/.ssh/known_hosts:78
debug1: ssh_ecdsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: .ssh/<file>.pem
debug1: Authentications that can continue: publickey
debug1: Trying private key: /home/<user>/.ssh/id_rsa
debug1: Trying private key: /home/<user>/.ssh/id_dsa
debug1: Trying private key: /home/<user>/.ssh/id_ecdsa
debug1: No more authentication methods to try.
Permission denied (publickey).
Наконец, после нескольких часов поисков, что с этим делать, я побежал ssh -Tvvv -i путь / file.pem user @ ip и волшебным образом у меня было отладочное соединение с экземпляром.
Это было сделано из машины дома. Убил связь, подключился нормально. Без проблем. Подключился с сервера в офисе без проблем.
Сегодня я не могу подключиться к экземпляру по SSH со своей машины в офисе, и все преобразованные ключи также не работают на этом экземпляре (например, ключи ppk для filezilla и т. Д.)
Вот вывод отладки -v с рабочей машины (домашней машины)
ssh -v -i <path>/<file>.pem <user>@<ip>
OpenSSH_5.8p1 Debian-7ubuntu1, OpenSSL 1.0.0e 6 Sep 2011
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to <ip> [<ip>] port 22.
debug1: Connection established.
debug1: identity file /home/<user>/.ssh/<file>.pem type -1
debug1: identity file /home/<user>/.ssh/<file>.pem-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.9p1 Debian-5ubuntu1
debug1: match: OpenSSH_5.9p1 Debian-5ubuntu1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.8p1 Debian-7ubuntu1
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA 75:43:6d:03:43:f5:89:fa:8d:fe:64:e1:39:9a:73:26
debug1: Host '<ip>' is known and matches the ECDSA host key.
debug1: Found key in /home/<user>/.ssh/known_hosts:78
debug1: ssh_ecdsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: .ssh/<file>.pem
debug1: Authentications that can continue: publickey
debug1: Trying private key: /home/<user>/.ssh/<file>.pem
debug1: read PEM private key done: type RSA
debug1: Authentication succeeded (publickey).
Authenticated to <ip> ([<ip>]:22).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: Remote: Ignored authorized keys: bad ownership or modes for directory /home/<user>
debug1: Sending environment.
debug1: Sending env LANG = en_US.UTF-8
Welcome to blah...
Все разрешения на ключи идентичны для всех экземпляров и компьютеров, подключенных к экземплярам.
Кто-нибудь знает, что можно сделать, чтобы это исправить?
Спасибо, -Дэвид
--РЕДАКТИРОВАТЬ--
Это результат отладки -v рабочей машины, которая все еще не устанавливает SSH-соединение.
Я также недавно очистил известные хосты на этой машине.
ssh -v -i <path>/<file>.pem <user>@<ip>
OpenSSH_6.0p1 Debian-3ubuntu1, OpenSSL 1.0.1c 10 May 2012
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to <ip> [<ip>] port 22.
debug1: Connection established.
debug1: identity file /home/<user>/.ssh/<file>.pem type -1
debug1: identity file /home/<user>/.ssh/<file>.pem-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.9p1 Debian-5ubuntu1
debug1: match: OpenSSH_5.9p1 Debian-5ubuntu1 pat OpenSSH_5*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.0p1 Debian-3ubuntu1
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA 75:43:6d:03:43:f5:89:fa:8d:fe:64:e1:39:9a:73:26
debug1: Host '<ip>' is known and matches the ECDSA host key.
debug1: Found key in /home/<user>/.ssh/known_hosts:1
debug1: ssh_ecdsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /home/<user>/.ssh/<file>.pem
debug1: read PEM private key done: type RSA
debug1: Authentications that can continue: publickey
debug1: No more authentication methods to try.
Permission denied (publickey).
Я хотел бы повторить, что все преобразованные ключи не работают для sftp, несмотря на то, что соединение ssh может быть установлено. В частности, ключ .ppk преобразован для использования в filezilla. Из этого же следует, что .ppk работает на всех других экземплярах, кроме проблемного потомка ... и также работал ранее.
- РЕДАКТИРОВАНИЕ 2 -
Машина, к которой мне удалось подключиться, была перезапущена, и я больше не могу подключиться к ней.
Вот твоя проблема:
debug1: Remote: Ignored authorized keys: bad ownership or modes for directory /home/<user>
Домашний каталог вашего пользователя может быть недоступен для группы или всего мира, и .ssh каталог и .ssh/authorized_keys может быть прочитан только пользователем. Как только вы исправите разрешения, вы должны снова обнаружить, что ваши логины снова работают.
По моему опыту, я научился убивать некорректно работающие экземпляры ec2 с помощью крайний предубеждение. Поскольку ваш ключ работает на других ваших экземплярах, а не на этом конкретном экземпляре, я бы назвал это испорченным экземпляром. Если вам действительно нужны данные на этом сервере, вы всегда можете выключить его, смонтировать том ebs на другом экземпляре и оттуда выполнить восстановление.