ssh - que - vpc aws
Usando el plugin knife ec2 para crear VM en subred privada VPC (1)
Aunque he escrito una buena cantidad de chef, soy bastante nuevo tanto para AWS / VPC como para administrar el tráfico de red (especialmente un host de bastión).
Usando el plugin knife ec2, me gustaría tener la capacidad de crear y arrancar dinámicamente una máquina virtual desde mi estación de trabajo de desarrollador. La VM debería poder existir en una subred pública o privada de mi VPC. Me gustaría hacer todo esto sin utilizar una IP elástica. También me gustaría que mi host de bastión fuera manos libres (es decir, me gustaría evitar tener que crear túneles de escucha explícitos por VM en mi host de bastión)
He utilizado con éxito el plugin knife ec2 para crear una máquina virtual en el modelo EC2 heredado (por ejemplo, fuera de mi VPC). Ahora estoy tratando de crear una instancia en mi VPC. En la línea de comando del cuchillo, estoy especificando una puerta de enlace, grupos de seguridad, subred, etc. La máquina virtual se crea, pero el cuchillo no puede acceder a ella más tarde.
Aquí está mi línea de comando cuchillo:
knife ec2 server create /
--flavor t1.micro /
--identity-file <ssh_private_key> /
--image ami-3fec7956 /
--security-group-ids sg-9721e1f8 /
--subnet subnet-e4764d88 /
--ssh-user ubuntu /
--server-connect-attribute private_ip_address /
--ssh-port 22 /
--ssh-gateway <gateway_public_dns_hostname (route 53)> /
--tags isVPC=true,os=ubuntu-12.04,subnet_type=public-build-1c /
--node-name <VM_NAME>
Sospecho que mi problema tiene que ver con la configuración de mi host bastion. Después de un día de buscar en Google, no pude encontrar una configuración que funcionara. Soy capaz de enviar un ssh al host de bastión, y desde allí puedo ssh a la máquina virtual recién creada. No puedo conseguir un cuchillo para duplicar con éxito esto utilizando el argumento de la puerta de enlace.
He jugado con / etc / ssh / ssh_config. Así es como existe hoy:
ForwardAgent yes
#ForwardX11 no
#ForwardX11Trusted yes
#RhostsRSAAuthentication no
#RSAAuthentication yes
#PasswordAuthentication no
#HostbasedAuthentication yes
#GSSAPIAuthentication no
#GSSAPIDelegateCredentials no
#GSSAPIKeyExchange no
#GSSAPITrustDNS no
#BatchMode no
CheckHostIP no
#AddressFamily any
#ConnectTimeout 0
StrictHostKeyChecking no
IdentityFile ~/.ssh/identity
#IdentityFile ~/.ssh/id_rsa
#IdentityFile ~/.ssh/id_dsa
#Port 22
#Protocol 2,1
#Cipher 3des
#Ciphers aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc
#MACs hmac-md5,hmac-sha1,[email protected],hmac-ripemd160
#EscapeChar ~
Tunnel yes
#TunnelDevice any:any
#PermitLocalCommand no
#VisualHostKey no
#ProxyCommand ssh -q -W %h:%p gateway.example.com
SendEnv LANG LC_*
HashKnownHosts yes
GSSAPIAuthentication yes
GSSAPIDelegateCredentials no
GatewayPorts yes
También he establecido /home/ubuntu/.ssh/identity en la clave privada coincidente de mi nueva instancia.
ACTUALIZAR:
Observo lo siguiente en el /var/log/auth.log del host bastión:
May 9 12:15:47 ip-10-0-224-93 sshd[8455]: Invalid user from <WORKSTATION_IP>
May 9 12:15:47 ip-10-0-224-93 sshd[8455]: input_userauth_request: invalid user [preauth]
Finalmente resolví esto. Me faltaba el nombre de usuario al especificar mi puerta de enlace. Originalmente pensé que el argumento --ssh-user se usaría tanto para la puerta de enlace como para la máquina virtual que estoy intentando arrancar. Esto fue incorrecto, el nombre de usuario debe especificarse para ambos.
knife ec2 server create /
--flavor t1.micro /
--identity-file <ssh_private_key> /
--image ami-3fec7956 /
--security-group-ids sg-9721e1f8 /
--subnet subnet-e4764d88 /
--ssh-user ubuntu /
--server-connect-attribute private_ip_address /
--ssh-port 22 /
--ssh-gateway ubuntu@<gateway_public_dns_hostname (route 53)> /
--tags isVPC=true,os=ubuntu-12.04,subnet_type=public-build-1c /
--node-name <VM_NAME>
Solo la línea que contiene la actualización (note la ubuntu @ al frente):
--ssh-gateway ubuntu@<gateway_public_dns_hostname (route 53)>
He pasado y bloqueado mi host de bastión de nuevo, incluida la eliminación de /home/ubuntu/.ssh/identity, ya que el almacenamiento de la clave privada en el host de bastión realmente me estaba molestando.
Para su información: al configurar un host de bastión, la configuración "fuera de la caja" de sshd funcionará cuando se use la imagen AMI de Amazon Linux. Además, algunos de los argumentos anteriores son opcionales, como --ssh-port.