Назад | Перейти на главную страницу

ssl подключение к aws без сервера aurora

На самом деле это следующий вопрос этот.
Я создал базу данных Aurora Serverless на AWS, создал VPC с 2 подсетями, как того требует Serverless aurora, и Cloud9, подключенный к подсети, к которой подключено устройство Aurora. Затем я создал закрытый ключ на платформе aws, который я загрузил на свой локальный компьютер.
Теперь я пытаюсь подключиться к своей бессерверной БД, но безуспешно. Я попытался создать туннельное соединение ssh, например, так ssh -i /path/to/file.pem] -N -L 3307:[DB endpoint].drds.amazonaws.com:3306 myAwsUser@[Cloud9 point] но не сработало, и более простой ssh -i /path/to/file.pem] myAwsUser@[Cloud9 point]
Я почти уверен, что я не назначил файл закрытого ключа, который я создал, используемому в cloud9.

Из того, что я понял, единственный способ подключиться к бессерверной базе данных на AWS, за пределами aws (то есть на локальном компьютере или другом удаленном сервере), - это использовать туннель ssh, верно? Если да, как мне включить ключевое соединение с БД?
Нужна ли мне учетная запись Cloud9 или нет?

ОБНОВИТЬ
Хорошо, кажется, кое-что теперь прояснилось. спасибо @MLu. Итак, я создал новый экземпляр EC2, используя бесплатный уровень t2.micro на Amazon Linux 2 AMI.
Я добавил разрешенный доступ к той же группе безопасности, которую использовал на бессерверных RDS. так что и мой Rds, и EC2 имеют общую группу безопасности.
Теперь я могу подключиться к экземпляру EC2 с помощью ssh -i file.pem ec2-user @ [EC2 dns] .compute.amazonaws.com Но у меня нет возможности подключиться к mysql. mysql -h [db endpoint].rds.amazonaws.com -u user дает мне mysql: command not found ошибка.

делая то, что упомянул @MLu ssh -v -i test.pem -N -L 3307:[db endpoint].rds.amazonaws.com:3306 ec2-user@[EC2 dns].compute.amazonaws.com дает мне это

OpenSSH_6.6.1, OpenSSL 1.0.1f 6 января 2014 г.

debug1: чтение данных конфигурации / etc / ssh / ssh_config
debug1: / etc / ssh / ssh_config, строка 19: Применение параметров для *
debug1: подключение к [EC2 PUBLIC DNS] [xx.xx.xx.xx] порту 22.
debug1: соединение установлено.
debug1: файл идентификации test.pem тип -1
debug1: файл идентификации test.pem-cert type -1
debug1: включение режима совместимости для протокола 2.0
debug1: строка локальной версии SSH-2.0-OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.10
debug1: версия удаленного протокола 2.0, версия удаленного программного обеспечения OpenSSH_7.4
debug1: match: OpenSSH_7.4 pat OpenSSH * compat 0x04000000
debug1: SSH2_MSG_KEXINIT отправлен
debug1: получен SSH2_MSG_KEXINIT
debug1: kex: server-> client aes128-ctr hmac-sha1-etm@openssh.com нет
debug1: kex: client-> server aes128-ctr hmac-sha1-etm@openssh.com нет
debug1: отправка SSH2_MSG_KEX_ECDH_INIT
debug1: ожидание SSH2_MSG_KEX_ECDH_REPLY
debug1: Ключ хоста сервера: ECDSA debug1: Хост 'EC2 host' известен и соответствует ключу хоста ECDSA.
debug1: найден ключ в ... /. ssh / known_hosts: 24
debug1: ssh_ecdsa_verify: подпись верна
debug1: SSH2_MSG_NEWKEYS отправлено
debug1: ожидание SSH2_MSG_NEWKEYS
debug1: получено SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_SERVICE_REQUEST отправлен
debug1: получен SSH2_MSG_SERVICE_ACCEPT
debug1: аутентификация, которая может продолжаться: publickey, gssapi-keyex, gssapi-with-mic
debug1: следующий метод аутентификации: gssapi-keyex
debug1: нет допустимого контекста обмена ключами
debug1: Следующий метод аутентификации: gssapi-with-mic
debug1: неуказанный сбой GSS. Дополнительный код может предоставить дополнительную информацию
Нет доступных учетных данных Kerberos

debug1: неуказанный сбой GSS. Дополнительный код может предоставить дополнительную информацию
Нет доступных учетных данных Kerberos

debug1: неуказанный сбой GSS. Дополнительный код может предоставить дополнительную информацию

debug1: неуказанный сбой GSS. Дополнительный код может предоставить дополнительную информацию
Нет доступных учетных данных Kerberos

debug1: Следующий метод аутентификации: publickey
debug1: Пробуем закрытый ключ: test.pem
debug1: key_parse_private2: отсутствует маркер начала
debug1: чтение закрытого ключа PEM выполнено: введите RSA
debug1: аутентификация прошла успешно (открытый ключ).
Аутентифицирован в [общедоступный DNS-сервер EC2] ([xx.xx.xx.xx]: 22).
debug1: Локальные соединения с LOCALHOST: 3307 перенаправляются на удаленный адрес [конечная точка БД]: 3306
debug1: локальная переадресация прослушивает :: 1 порт 3307.
debug1: канал 0: новый [прослушиватель порта]
debug1: локальная переадресация прослушивает 127.0.0.1 порт 3307.
debug1: канал 1: новый [прослушиватель порта]
debug1: запрос no-more-sessions@openssh.com
debug1: вход в интерактивный сеанс.
debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0
а то терминал просто зависает. Курсор работает, но я ничего не могу сделать, Excel Ctrl + C просто закрывает соединение.

Я также видел, что есть соединение api с RDS. Как это работает без сервера? Могу ли я выполнять все команды mysql оттуда? Думаю, это было бы полезно для моих java-приложений, вместо того, чтобы проходить через ssh и jdbc. Спасибо

amazon-web-services ssh-tunnel

В первую очередь: SSH - это не SSL

SSH используется для входа в целевые системы ' оболочка преимущественно для интерактивного использования. Т.е. ты SSH к экземпляру EC2 а затем запустите некоторые команды Linux.

SSL используется для шифрования различных протоколы приложений - HTTP, SMTP и в вашем случае протокол MySQL.

В вашем случае вам нужно будет использовать SSLне SSH.

Сначала включите SSL для Aurora, как описано в Использование SSL для шифрования подключения к инстансу БД

А затем на стороне клиента используйте mysql --ssl --ssl-cert=... --host=.... Возможно, вам понадобится использовать ряд параметров:

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

На самом деле, перечитав ваш вопрос еще раз, я вижу, что у вас другая проблема - вы хотите получить доступ к Serverless Aurora из-за пределов вашей сети AWS VPC, верный?

Бессерверная Aurora, похоже, не поддерживает общедоступный IP-адрес, поэтому да, вам придется туннелировать трафик с вашего ноутбука на VPC. Пара вариантов:

SSH-туннель пока вы пытаетесь настроить. Вместо туннелирования через Cloud9 может быть проще развернуть новый экземпляр EC2, даже самый маленький t3.nano подойдет, дайте ему публичный IP-адрес и используйте Amazon Linux 2 AMI. Как только он пройдет через него, выполните:
```
[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 туннель - это более прозрачный вариант, но немного сложнее в настройке. По сути, вы получите прямой сетевой доступ к ресурсам в VPC.

В обоих случаях убедитесь, что ваш Группа безопасности Аврора разрешает доступ из Экземпляр EC2! В противном случае вы не сможете подключиться.

Надеюсь, это поможет :)