AWS EC2 Servidor recusou conexão - desmontado substituído authorized_keys - ainda não é possível conectar

2

Então, estávamos trabalhando em configurações para um servidor de produção em breve. Depois de fazer algumas alterações na configuração, reiniciamos a máquina e recebemos a temida mensagem "conexão recusada pelo servidor".

Eu tentei criar uma AMI e relançar para tentar substituir o certificado. Isso não funcionou.

Também segui as instruções para desmontar o disco rígido e substituir as authorized_keys e, em seguida, voltar a ligá-lo. Eu fiz isso várias vezes. Isso não funcionou.

A única coisa em que consigo pensar é que adicionamos uma pessoa ao arquivo do sudo há algum tempo. Desde então, substituí o arquivo sudoers por uma cópia que sei que funciona, mas isso também não parece ajudar.

Como faço para depurar e talvez corrigir o problema. Eu apenas pensei que poderia procurar no log do console da AWS, mas realmente não encontrei muito. Eu tenho uma versão mais antiga do servidor que funciona como uma AMI, mas falta muito trabalho que fizemos recentemente. Acabei de me distrair, mas estava na minha lista de coisas para fazer - como você pode ver, eu faço backups - não com a mesma frequência que deveria.

Alguém pode me ajudar a depurar o que pode ser o problema.

Outras possibilidades que verifiquei permissões? Eu acredito que tenho 700 na pasta .ssh 600 em authorized_keys

as chaves estão em uma pasta / home / bitnami embora eu use o usuário ubuntu para efetuar o login. Isto é baseado em um bitnami AMI - Eu verifiquei que eu de fato uso o Ubuntu para login, mas existe apenas um usuário bitnami.

Eu uso putty, mas é assim que o Event Log se parece:

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)

Log de console da 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++++++++++

Parece que o sistema operacional ainda está um pouco intacto. Existe uma estratégia que posso tomar para substituir diretórios para recuperar o que preciso? Eu já tentei substituir o diretório bitnmai inteiro que parece ter as chaves, então talvez tente o diretório / etc, etc?

Atualmente, tenho uma versão antiga de trabalho com a versão não operacional atual montada em / data. Eu verifiquei que na versão de trabalho não há pasta / home / ubuntu. Inicialmente, é um bitnami ami para o magento e a versão de trabalho é recente após o upload de todo o conteúdo, mas sem grandes configurações. Verifiquei que as authorized_keys são encontradas na pasta /home/bitnami/.ssh/, embora eu use o ubuntu para efetuar login, conforme observado no log do console da AWS, e também por consertar isso por algum tempo.

Eu também posso verificar que você não pode fazer login com o usuário ubuntu ou bitnami do usuário, mas você pode usar tanto em uma versão de trabalho antiga.

    
por Mauricio Zuniga 21.03.2016 / 01:31

1 resposta

1

Para corrigir a situação, usei um ami antigo e iniciei essa máquina. Eu então montei a unidade atual para a máquina antiga em uma pasta chamada / data

Eu usei o comando Copiei a pasta / etc

sudo cp -a /etc /data/

Eu também copiei a pasta do usuário

sudo cp -a /home/bitnami /data/home

Eu também copiei a pasta raiz, pois notei que havia algumas alterações lá

sudo cp -a /root /data

Eu passei por muitas iterações e percebi que talvez eu não estivesse configurando as permissões corretamente quando eu estava copiando anteriormente e depois me deparei com uma postagem que me dizia para usar a opção -a ao executar o cp. Depois que eu copiei todas essas pastas (incluindo as chaves), consegui fazer o login novamente.

Depois que fiz tudo isso, remontei a unidade na máquina original e consegui fazer o login novamente.

    
por 21.03.2016 / 07:10