Итак, мы работали над конфигурациями для сервера, который скоро станет производственным. После внесения некоторых изменений в конфигурацию мы перезагрузили компьютер и получили ужасное сообщение «сервер отказал в соединении».
Я попытался создать AMI и перезапустить его, чтобы попытаться заменить сертификат. Это не сработало.
Я также выполнил инструкции по отключению жесткого диска и замене authorized_keys с последующим его повторным подключением. Я делал это несколько раз. Это не сработало.
Единственное, о чем я могу думать, это то, что мы недавно добавили человека в файл sudoer. С тех пор я заменил файл sudoers копией, которая, как я знаю, работает, но это тоже не помогает.
Как мне отладить и, возможно, решить проблему. Я просто подумал, что могу посмотреть журнал из консоли AWS, но особо не нашел. У меня есть более старая версия сервера, работающая как AMI, но в ней отсутствует большая часть работы, которую мы проделали недавно. Просто отвлекся, но был в моем списке дел - как видите, я делаю резервные копии - но не так часто, как следовало бы.
Может ли кто-нибудь помочь мне отладить, в чем может быть проблема.
Другие возможности Я проверил разрешения? Я считаю, что у меня 700 в папке .ssh 600 на authorized_keys
ключи находятся в папке / home / bitnami, хотя я использую пользовательский ubuntu для входа в систему. Это основано на AMI bitnami - я подтвердил, что действительно использую ubuntu для входа в систему, но есть только пользователь bitnami.
Я использую шпатлевку, но вот как выглядит журнал событий:
2016-03-18 21:31:12 Using SSH protocol version 2
2016-03-18 21:31:12 We claim version: SSH-2.0-PuTTY_Release_0.63
2016-03-18 21:31:12 Doing Diffie-Hellman group exchange
2016-03-18 21:31:12 Doing Diffie-Hellman key exchange with hash SHA-256
2016-03-18 21:31:12 Host key fingerprint is:
2016-03-18 21:31:12 ssh-rsa 2048 1f:25:5b:d4:af:e6:b8:b5:e2:97:a7:76:b7:bf:ca:b2
2016-03-18 21:31:12 Initialised AES-256 SDCTR client->server encryption
2016-03-18 21:31:12 Initialised HMAC-SHA-256 client->server MAC algorithm
2016-03-18 21:31:12 Initialised AES-256 SDCTR server->client encryption
2016-03-18 21:31:12 Initialised HMAC-SHA-256 server->client MAC algorithm
2016-03-18 21:31:12 Reading private key file "C:\Users\mzuniga\keys\abc.ppk"
2016-03-18 21:31:31 Offered public key
2016-03-18 21:31:31 Server refused our key
2016-03-18 21:31:31 Disconnected: No supported authentication methods available (server sent: publickey)
Журнал консоли AWS
/opt/bitnami/apache2/scripts/ctl.sh : httpd started at port 80
* Stopping System V runlevel compatibility[74G[ OK ]
* Starting execute cloud user/final scripts[74G[ OK ]Cloud-init v. 0.7.5 running 'modules:final' at
Sat, 19 Mar 2016 04:16:00 +0000. Up 99.63 seconds.
ci-info: +++++++++Authorized keys from /home/bitnami/.ssh/authorized_keys for user ubuntu++++++++++
Похоже, что ОС все еще работает. Есть ли стратегия, которую я могу применить для замены каталогов, чтобы восстановить то, что мне нужно? Я уже пробовал заменить весь каталог bitnmai, в котором, кажется, есть ключи - тогда, может быть, попробуйте каталог / etc и т. Д.?
В настоящее время у меня есть работающая более старая версия с текущей нерабочей версией, установленной в / data. Я убедился, что в рабочей версии нет папки / home / ubuntu. Изначально это bitnami ami для magento, а рабочая версия является последней после загрузки всего контента, но без основных конфигураций. Я проверил, что authorized_keys находятся в папке /home/bitnami/.ssh/, хотя я использую ubuntu для входа в систему, как указано в журнале консоли AWS, а также возился с этим в течение некоторого времени.
Я также могу проверить, что вы не можете войти в систему с помощью пользователя ubuntu или пользователя bitnami, но вы можете использовать либо более старую рабочую версию.
Чтобы исправить ситуацию, я использовал более старую ami и запустил эту машину. Затем я подключил текущий диск к старой машине в папку с именем / data.
Я использовал команду, которую я скопировал в папку / etc
sudo cp -a /etc /data/
Я также скопировал папку пользователя
sudo cp -a /home/bitnami /data/home
Я также скопировал корневую папку, так как заметил, что там были некоторые изменения
sudo cp -a /root /data
Я прошел через много итераций и понял, что, возможно, я неправильно устанавливал разрешения, когда раньше копировал, а затем наткнулся на сообщение, в котором мне предлагалось использовать параметр -a при запуске cp. После того, как я просмотрел и скопировал все эти папки (включая ключи), я снова смог войти в систему.
Сделав все это, я переустановил диск на исходную машину и снова смог войти в систему.