Я создал следующую пару ключей и экземпляр EC2 с помощью Terraform. Я не буду включать конфигурацию SG, но она позволяет использовать SSH из Интернета.
Когда я пытаюсь подключиться к этому экземпляру по SSH, я получаю сообщения об ошибках «Сервер отказался от нашего ключа» и «Нет доступных поддерживаемых методов аутентификации (сервер отправил: открытый ключ).
Однако Я являюсь могу войти в систему, когда я создаю отдельный экземпляр EC2 в консоли и назначаю ему ту же пару ключей, что и в сценарии TF.
Кто-нибудь видел такое поведение? Что вызывает это?
# Create Dev VPC
resource "aws_vpc" "dev_vpc" {
cidr_block = "10.0.0.0/16"
instance_tenancy = "default"
enable_dns_hostnames = "true"
tags = {
Name = "dev"
}
}
# Create an Internet Gateway Resource
resource "aws_internet_gateway" "igw" {
vpc_id = aws_vpc.dev_vpc.id
tags = {
Name = "dev-engineering-igw"
}
}
# Create a Route Table
resource "aws_route_table" " _dev_public_routes" {
vpc_id = aws_vpc. _dev.id
tags = {
name = " _dev_public_routes"
}
}
# Create a Route
resource "aws_route" " _dev_internet_access" {
route_table_id = aws_route_table. _dev_public_routes.id
destination_cidr_block = "0.0.0.0/0"
gateway_id = aws_internet_gateway.igw.id
}
# Associate the Route Table to our Public Subnet
resource "aws_route_table_association" " _dev_public_subnet_assoc" {
subnet_id = aws_subnet. _dev_public.id
route_table_id = aws_route_table. _dev_public_routes.id
}
# Create public subnet for hosting customer-facing Django app
resource "aws_subnet" " _dev_public" {
vpc_id = aws_vpc. _dev.id
cidr_block = "10.0.0.0/17"
availability_zone = "us-west-2a"
tags = {
Env = "dev"
}
}
resource "aws_security_group" "allow_https" {
name = "allow_https"
description = "Allow http and https inbound traffic"
vpc_id = aws_vpc. _dev.id
ingress {
description = "HTTP and HTTPS into VPC"
from_port = 80
to_port = 80
protocol = "tcp"
cidr_blocks = ["0.0.0.0/0"]
}
ingress {
description = "HTTP and HTTPS into VPC"
from_port = 443
to_port = 443
protocol = "tcp"
cidr_blocks = ["0.0.0.0/0"]
}
ingress {
description = "SSH"
from_port = 22
to_port = 22
protocol = "tcp"
cidr_blocks = ["0.0.0.0/0"]
}
egress {
description = "HTTP and HTTPS out of VPC for Session Manager"
from_port = 443
to_port = 443
protocol = "tcp"
cidr_blocks = ["0.0.0.0/0"]
}
tags = {
Name = "allow_https"
}
}
resource "aws_instance" "web" {
ami = data.aws_ami.ubuntu20.id
instance_type = "t3.micro"
subnet_id = aws_subnet. _dev_public.id
associate_public_ip_address = "true"
vpc_security_group_ids = ["${aws_security_group.allow_https.id}"]
key_name = "key_name"
metadata_options { #Enabling IMDSv2
http_endpoint = "disabled"
http_tokens = "required"
}
tags = {
Env = "dev"
}
}
Добавлено, хотя у меня нет проблем с сетевым подключением к экземпляру, о чем свидетельствует ошибка «сервер отказался от нашего ключа».
Вы проверили авс документы возможные способы решения такой проблемы?
Вы используете ubuntu20
. Это происходит с другими ОС, такими как AL2?
К сожалению, да. Я использую правильные имена пользователей для каждой версии.
Вы уверены, что это ваш настоящий код? У вас там много странных пробелов, таких как vpc_id = aws_vpc. _dev.id
, что означает, что ваш код TF даже не является действительным кодом TF.
Точно так же вы определили vpc с именем dev_vpc
, но ваш код использует какой-то другой VPC?
Это продезинфицированный код. Я использовал поиск-замену. Я могу очистить его, если вам нужно запустить на нем приложение.
Мне удалось его запустить. Просто попытаюсь воспроизвести вашу проблему и посмотреть, относится ли она только к вам или нет.
Спасибо. Должен был знать лучше. ?
У меня тоже проблема с ssh. Кажется, это из-за вашего metadata_options
. Если вы удалите это и повторно развернете (создайте новый экземпляр), это сработает для меня. Пока не уверен, почему metadata_options
вызывает это.
У вас была возможность проверить, помогает ли удаление metadata_options
в вашем случае?
Я не запускал вышеуказанное, но, глядя на metadata_options
, у вас есть: http_endpoint = "disabled"
который отключает службу метаданных, но http_tokens = "required"
указывает, что для службы метаданных требуются токены сеанса. Может ли это быть коллизия в логике, вызывающая странные проблемы? ("Метаданные отключены, но для них требуются токены")
Марчин, спасибо! Сегодня утром я смог протестировать, и это решило мою проблему. @Fermin - ты прав - здесь может быть логическая коллизия. Я тоже проверю это позже сегодня днем. Вы хотите опубликовать ответ, который я могу принять?
Документация AWS подтверждает подозрения @Fermin: требовать использования IMDSv2. Вы можете указать, что при запросе метаданных экземпляра необходимо использовать IMDSv2. Используйте команду интерфейса командной строки «modify-instance-metadata-options» и установите для параметра http-tokens значение «обязательно». Когда вы указываете значение для http-токенов, вы также должны включить http-endpoint.
Как указано в комментариях, удаление metadata_options
из ресурса экземпляра решает проблему.
Исправление состоит в том, чтобы обновить metadata_options
следующим образом:
metadata_options { #Enabling IMDSv2
http_endpoint = "enabled"
http_tokens = "required"
}
Просмотр документации Terraform для metadata_options
показывает, что:
http_endpoint = "disabled"
означает, что служба метаданных недоступна.http_tokens = "required"
означает, что службе метаданных требуются токены сеанса (например, IMDSv2).Это недопустимая конфигурация, как указано в Документы AWS:
You can opt in to require that IMDSv2 is used when requesting instance metadata. Use the modify-instance-metadata-options CLI command and set the http-tokens parameter to required. When you specify a value for http-tokens, you must also set http-endpoint to enabled.
Вы должны предоставить свои
aws_security_group.allow_https
иaws_subnet.wisefi_dev_public
данные.