Ssl connection to aws serverless aurora

amazon-web-servicesssh-tunnel

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

Best Answer

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 :)

Related Solutions

Linux – Can’t SSH into Amazon EC2

Most likely you have this in your /etc/ssh/sshd_config:

PermitRootLogin no

This is a good thing, however. If you want to perform privileged actions, you should do them with sudo or at least start a root shell with sudo -s.

There will likely be a reason for the failed login in /var/log/auth.log on the server. It doesn't look like you put the public key in /root/.ssh/authorized_keys on your server, which is where it needs to be for root to log in.

Buried in the fine print here is the titbit that the default user is admin, not root in the Debian AMI. That's where Amazon will have put the public key that matches the private key you downloaded. Use this:

ssh -i /Users/James/Documents/sshkeys/aws.pem admin@myec2ip

The default user is ec2-user in the Amazon AMI and ubuntu in the Ubuntu AMI. I don't know about any others.

Mysql – AWS RDS MySQL vs Aurora

The technical differences are summarised nicely in this SlideShare - http://www.slideshare.net/AmazonWebServices/amazon-aurora-amazons-new-relational-database-engine

It's really quite a different architecture/implementation under the covers from standard MySQL, and one that is fundamentally closed.

Amazon are being coy about the extent to which the front end is a MySQL derivative or a complete rewrite that is protocol-compatible - see http://www.theregister.co.uk/2014/11/26/inside_aurora_how_disruptive_is_amazons_mysql_clone/?page=2 - but it looks likely it's at least a major fork with lots of new code. It will have different bugs from the main MySQL releases, which users will be reliant on Amazon to fix. A distributed transactional database backend is a complex thing to write, and while Amazon have some of the best engineers in the world for this sort of system, it's still quite new.

It relies on a completely new Amazon-specific multi-tenanted storage backend, and the updated software isn't freely available as open source, so you can't just download it and run it on your own servers. It may diverge over time (e.g. years) in terms of functional features supported, meaning that code developed against Aurora may no longer work against mainstream MySQL releases, providing a risk of increased lock-in to Amazon.

Regardless, especially if your application needs them, the performance, low replica lag, scalability and recovery time reductions over standard MySQL look pretty compelling in the short term. The lock-in and costs are certainly much lower than with, for example, Oracle's Exadata - which is really the class of solution that Amazon are targetting.

Best Answer

Related Solutions

Linux – Can’t SSH into Amazon EC2

Mysql – AWS RDS MySQL vs Aurora

Related Topic