ssl conexão para aws serverless aurora

1

Esta é realmente uma pergunta de acompanhamento de esta .
Eu criei um banco de dados Aurora sem servidor na AWS, criei uma VPC com 2 sub-redes conforme exigido pela Aurora sem servidor e uma Cloud9 conectada à sub-rede à qual a aurora está conectada. Então eu criei uma chave privada dentro da plataforma aws que baixei no meu computador local.
Agora estou tentando conectar ao meu banco de dados sem servidor, mas sem sucesso. Eu tentei criar uma conexão de túnel ssh, por exemplo, assim ssh -i /path/to/file.pem] -N -L 3307:[DB endpoint].drds.amazonaws.com:3306 myAwsUser@[Cloud9 point] , mas não funcionou, e nem o mais simples ssh -i /path/to/file.pem] myAwsUser@[Cloud9 point]
Estou quase certo de que eu não tenho atribuído o arquivo de chave privada que eu criei para um usado na nuvem9.

Pelo que entendi, a única maneira de se conectar a um banco de dados sem servidor na AWS, fora do aws (ou seja, máquina local ou outro servidor remoto), é usando um túnel ssh, certo? Em caso afirmativo, como habilitar a conexão de chave para o banco de dados?
Preciso da conta Cloud9 ou não?

UPDATE
Ok, parece que algumas coisas estão mais claras agora. obrigado a @MLu. Então criei uma nova instância do EC2, usando a camada livre t2.micro em Amazon Linux 2 AMI .
Eu adicionei o acesso permitido ao mesmo grupo de segurança que usei nos rds sem servidor. para que meus Rds e EC2 tenham um grupo de segurança comum. Agora, posso conectar-me à instância do EC2 ssh -i file.pem ec2-usuário @ [EC2 dns] .compute.amazonaws.com Mas não tenho como conectar ao mysql. mysql -h [db endpoint].rds.amazonaws.com -u user me dá um erro mysql: command not found .

fazendo o que @MLu mencionou ssh -v -i test.pem -N -L 3307:[db endpoint].rds.amazonaws.com:3306 ec2-user@[EC2 dns].compute.amazonaws.com está me dando isso

OpenSSH_6.6.1, OpenSSL 1.0.1f 6 de janeiro de 2014

debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to [EC2 PUBLIC DNS][xx.xx.xx.xx] port 22.
debug1: Connection established.
debug1: identity file test.pem type -1
debug1: identity file test.pem-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.10
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.4
debug1: match: OpenSSH_7.4 pat OpenSSH* compat 0x04000000
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr [email protected] none
debug1: kex: client->server aes128-ctr [email protected] none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA debug1: Host 'EC2 host' is known and matches the ECDSA host key.
debug1: Found key in .../.ssh/known_hosts:24
debug1: ssh_ecdsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic
debug1: Next authentication method: gssapi-keyex
debug1: No valid Key exchange context
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure. Minor code may provide more information
No Kerberos credentials available

debug1: Unspecified GSS failure. Minor code may provide more information
No Kerberos credentials available

debug1: Unspecified GSS failure. Minor code may provide more information

debug1: Unspecified GSS failure. Minor code may provide more information
No Kerberos credentials available

debug1: Next authentication method: publickey
debug1: Trying private key: test.pem
debug1: key_parse_private2: missing begin marker
debug1: read PEM private key done: type RSA
debug1: Authentication succeeded (publickey).
Authenticated to [EC2 public dns] ([xx.xx.xx.xx]:22).
debug1: Local connections to LOCALHOST:3307 forwarded to remote address [DB end point]:3306
debug1: Local forwarding listening on ::1 port 3307.
debug1: channel 0: new [port listener]
debug1: Local forwarding listening on 127.0.0.1 port 3307.
debug1: channel 1: new [port listener]
debug1: Requesting [email protected]
debug1: Entering interactive session.
debug1: client_input_global_request: rtype [email protected] want_reply 0
and then the terminal just hangs. The curson is working, but there is nothing I can do excel Ctrl+C thats just closes the connection.

Eu também vi que existe uma conexão de API para o RDS. Como isso funciona no serverless? posso fazer todos os comandos mysql de lá? Seria útil em meus aplicativos java, em vez de passar por ssh e jdbc, eu acho. Obrigado

    
por Skaros Ilias 17.10.2018 / 14:56

1 resposta

1

Primeiramente: o SSH não é SSL

O

SSH é usado para acessar o shell dos sistemas de destino predominantemente para uso interativo. Ou seja você SSH para uma instância do EC2 e, em seguida, execute alguns comandos do Linux.

SSL é usado para criptografar vários protocolos de aplicativos - HTTP, SMTP e, no seu caso, protocolo MySQL.

No seu caso, você precisará usar SSL , não SSH .

Primeiro, ative o SSL para o Aurora primeiro, conforme descrito em Usando SSL para criptografar um Conexão com uma instância de banco de dados

E, no lado do cliente, use mysql --ssl --ssl-cert=... --host=... . Há vários parâmetros que você pode precisar usar:

~ $ mysql --help | grep ssl 
  --ssl               Enable SSL for connection (automatically enabled with
                      other flags).
  --ssl-ca=name       CA file in PEM format (check OpenSSL docs, implies
                      --ssl).
  --ssl-capath=name   CA directory (check OpenSSL docs, implies --ssl).
  --ssl-cert=name     X509 cert in PEM format (implies --ssl).
  --ssl-cipher=name   SSL cipher to use (implies --ssl).
  --ssl-key=name      X509 key in PEM format (implies --ssl).
  --ssl-crl=name      Certificate revocation list (implies --ssl).
  --ssl-crlpath=name  Certificate revocation list path (implies --ssl).
  --ssl-verify-server-cert 
                      Verify server's "Common Name" in its cert against
                      hostname used when connecting. This option is disabled by default.

Na verdade, depois de reler sua pergunta novamente, vejo que você tem um problema diferente: deseja acessar o Aurora sem servidor de fora da sua rede AWS VPC , correto?

Aurora sem servidor não parece suportar IP público, então sim, você terá que direcionar o tráfego do seu laptop para o VPC. Algumas opções:

  • Túnel SSH enquanto você está tentando configurar. Em vez de tunelamento através do Cloud9, pode ser mais fácil criar uma nova instância do EC2, até mesmo o menor t3.nano fará, fornecer um endereço IP público e usar o Amazon Linux 2 AMI . Uma vez que está em túnel através dele com:

    [you laptop] ~ $ ssh -v -i /path/to/file.pem -N -L 3307:[DB endpoint].drds.amazonaws.com:3306 [email protected]
    
  • Túnel OpenVPN - é uma opção mais transparente, mas um pouco mais complexa de configurar. Essencialmente, você obterá acesso direto à rede para os recursos no VPC.

Em ambos os casos, certifique-se de que o Grupo de segurança Aurora permita o acesso da instância EC2 ! Caso contrário, você não poderá se conectar.

Espero que ajude:)

    
por 17.10.2018 / 20:38