ssl connection to aws serverless aurora

Question

This is actually a follow-up question of this.
I have created an Aurora Serverless database on AWS, created a VPC with 2 subnets as required by Serverless aurora and a Cloud9 connected to the subnet that the aurora is connected to. Then I created a private key from inside aws platform which i downloaded to my local computer.
Now I am trying to connect to my serverless DB but with no success. I have tried to create an ssh tunnel connection, for example like so ssh -i /path/to/file.pem] -N -L 3307:[DB endpoint].drds.amazonaws.com:3306 myAwsUser@[Cloud9 point] but didnt work, and neither did the simpler ssh -i /path/to/file.pem] myAwsUser@[Cloud9 point]
I am almost certain that i havent assigned the private key file that i created to a used on cloud9.

From what I have understood the only way to connect to a serverless db on AWS, outside of aws(ie local machine or other remote server), is by using a ssh tunnel, right? If so, how do I enable key connection to the DB?
Do I need the Cloud9 account or not?

---

UPDATE
Ok, it seems that some things are clearer now. thanks to @MLu. So I created a new EC2 instance, using the free tier t2.micro on a Amazon Linux 2 AMI.
I added the allowed access to the same security group that I used on the serverless rds. so both my Rds and EC2 have a common security group.
Now, I can connect to the EC2 instance by ssh -i file.pem ec2-user@[EC2 dns].compute.amazonaws.com But there I have no way to connect to mysql. mysql -h [db endpoint].rds.amazonaws.com -u user gives me a mysql: command not found error.

by doing what @MLu mentioned ssh -v -i test.pem -N -L 3307:[db endpoint].rds.amazonaws.com:3306 ec2-user@[EC2 dns].compute.amazonaws.com is giving me this

OpenSSH_6.6.1, OpenSSL 1.0.1f 6 Jan 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 hmac-sha1-etm@openssh.com none
debug1: kex: client->server aes128-ctr hmac-sha1-etm@openssh.com 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 no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: client_input_global_request: rtype hostkeys-00@openssh.com 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.

I have also seen that there is an api connection to the RDS. How does this work on serverless? can I do all the mysql commands from there? It would be useful on my java applications, instead of going through ssh and jdbc, i guess. Thanks

Answer 1

First and foremost: SSH is not SSL

SSH is used to login to target systems' shell predominantly for interactive use. I.e. you SSH to an EC2 instance and then run some Linux commands.

SSL is used to encrypt various application protocols - HTTP, SMTP, and in your case MySQL protocol.

In your case you'll need to use SSL, not SSH.

First enable SSL for Aurora first as described in Using SSL to Encrypt a Connection to a DB Instance

And then on the client side use mysql --ssl --ssl-cert=... --host=.... There is a number of parameters that you may need to use:

~ $ 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.

---

Actually after re-reading your question again I see you've got a different problem - you want to access Serverless Aurora from outside of your AWS VPC network, correct?

Serverless Aurora doesn't seem to support Public IP so yes, you will have to tunnel traffic from your laptop to the VPC. Couple of options:

• SSH Tunnel as you're trying to setup. Instead of tunnelling through Cloud9 it may be easier to spin up a new EC2 instance, even the smallest t3.nano will do, give it a public IP address and use Amazon Linux 2 AMI. Once it is up tunnel through it with:

  [you laptop] ~ $ ssh -v -i /path/to/file.pem -N -L 3307:[DB endpoint].drds.amazonaws.com:3306 ec2-user@IP.AD.DR.ES
  

• OpenVPN tunnel - that's a more transparent option but a little more complex to setup. Essentially you will get direct network access to the resources in the VPC.

In both cases make sure that your Aurora Security Group permits access from the EC2 instance! Otherwise you won't be able to connect.

Hope that helps :)