Packer: Feature Request: ssh_interface option for GCP

[JasperWoo]

• Packer 1.4.1

As seen here, packer for aws has an option to ssh via DNS name. But I don't see an equivalent option for GCP.

Can I please request this feature to be implemented in GCP? For our security setup, we cannot ssh using IP address.

[azr]

Hello there @JasperWoo, thanks for opening. The GCP builder internally uses the same communicator code as the amazon-ebs builder. It seems to me that it's just that the field is not documented for GCP.

Can you please try to just set it and tell us if it worked for you ?

[rickard-von-essen]

There is a difference here. GCE instances either have a _external IP_ and those doesn't have any DNS name (automatically) associated with them. And if you use the internal ip then you can set ssh_host to [INSTANCE_NAME].[ZONE].c.[PROJECT_ID].internal.

[JasperWoo]

@rickard-von-essen Thanks for your reply! After trying your option, it seems like Packer ignored this field and still trying to connect to the internal ip address, which it obviously does not have access to from outside of GCP. Errors are as follows:

2019/06/20 10:11:04 packer: 2019/06/20 10:11:04 [DEBUG] TCP connection to SSH ip/port failed: dial tcp 10.128.7.245:22: i/o timeout
==> googlecompute: Timeout waiting for SSH.

[JasperWoo]

@azr Thanks for your reply! I tried to set ssh_interface for GCP builder, no effect is observed. Packer still tries to ssh via IP address:

2019/06/20 10:36:03 packer: 2019/06/20 10:36:03 [DEBUG] TCP connection to SSH ip/port failed: dial tcp 10.128.0.52:22: i/o timeout
2019/06/20 10:36:08 ui error: ==> googlecompute: Timeout waiting for SSH.
==> googlecompute: Timeout waiting for SSH.

[rickard-von-essen]

@azr ssh_interface is specific to amazon and openstack builders, it's a bug that it's available .

if you use the internal ip then you can set ssh_host to [INSTANCE_NAME].[ZONE].c.[PROJECT_ID].internal.

@JasperWoo means that it only works if you can access the internal IP.

@JasperWoo What is your actual problem. Describe it in detail and we can help you.

[JasperWoo]

@rickard-von-essen Thanks!

We are running Packer outside of GCP vpc to build GCP images (locally or using cloud-run for automation). What's different in our case is that our corporate security disabled external IP, and we are therefore constrained to only use DNS name to ssh into vms inside vpc.

Alternatively we can set up a bastion, but we are still working with our security team to discuss it, and it might not work.

ssh_interface, which is available in AWS, looks very promising and therefore I am thinking of its equivalent offering in GCP.

[rickard-von-essen]

What's different in our case is that our corporate security disabled external IP, and we are therefore constrained to only use DNS name to ssh into vms inside vpc.

That is a misunderstanding. IP networks don't work like that. You can't connect to a DNS name.

When a software is presented with a hostname it uses a resolver to lookup what IP that is, usually by contacting a DNS server asking for the IP address of that host name. Then it can use that IP to do a network connection. But IP datagrams knows nothing about hostnames they only carry a source and destination IP.

Go back to the networking/security people and ask what's exactly the limitations and how you are supposed to connect towards hosts in GCP.

[JasperWoo]

@rickard-von-essen Thanks for your message. I do understand DNS gets resolved to IP to actually send packet to the remote host. But in our case, we have to route through our security team's hosts, and using their NAT service to resolve to vms inside GCP. There is no way for us to connect to GCP vms with VM IPs directly.

[rickard-von-essen]

NAT should be transparent client's side, that shouldn't require that you do anything.

[JasperWoo]

@rickard-von-essen Thanks for your reply. NAT was not a valid point there. I apologize.

I will summarize our use case and ask again here:
We disabled external IP address per security request. With our internal security setup, we can ssh using dns name as ssh <user_name>@<dns_name>. When running packer outside of vpc with "omit_external_ip": true and "use_internal_ip": true, it is trying to ssh by internal ip address and therefore not able to ssh with error:

2019/06/20 10:36:08 ui error: ==> googlecompute: Timeout waiting for SSH.
==> googlecompute: Timeout waiting for SSH.

With my current understanding, Packer's option ssh_interface(only for AWS) can work in this use case because we can define in this option and have Packer ssh using just like how I am doing it manually above.

Is my understanding correct that Packer for GCP has no workaround for this use case? Thank you!

[rickard-von-essen]

@JasperWoo I summarise what I have stated above.

GCE instances with external IP don't have any DNS name.

We disabled external IP address per security request. With our internal security setup, we can ssh using dns name as ssh @

This is a misunderstanding of how this works. Please get this clarified and most likely we can resolve this for you.

( And you can ignore the "omit_external_ip": true and "use_internal_ip": true that is if you are on the VPC network. )

[JasperWoo]

@rickard-von-essen Sorry if there is any miscommunication and thanks for your continuous support. Really appreciate it!

To clarify, our GCE instances don't have external IP addresses and we are trying to run Packer from outside of vpc.
And when trying ssh manually outside of vpc, internal IP address won't work (obviously), and using DNS name works.
I admit I am not an expert in networking and this is all I know.. I really appreciate if you can help us based on my description above.

[rickard-von-essen]

I'm not sure I understand this correctly

And when trying ssh manually outside of vpc, internal IP address won't work (obviously), and using DNS name works.

---

Let's prove that I'm wrong. Can you do the following and gist the output of commands (except the first).

1. Launch a GCE instance with a similar setup to what you would run with Packer (or use one existing).
2. Ssh to it with IP, ssh -vvvv <user>@<IP>
3. Ssh to it with DNS name, ssh -vvvv <user>@<DNS name>
4. Show some DNS info dig <DNS name> ANY *)
5. Show some instance info gcloud --project <project> compute instances describe <vm name>

*) dig is part of the dnsutils package available for Linux and WSL, and installed by default on macOS.

[JasperWoo]

@rickard-von-essen
Really appreciate your attention on this. Here is the result of those commands:
https://gist.github.com/JasperWoo/a4ee0be3bad4ae7015ee1b228abc1103

For security reasons, I have masked our project as "example".

[rickard-von-essen]

To summarise the gist above:

The ssh-test instance has networkIP: 10.128.7.231
and you ssh to it and it fails.

Then you ssh to ssh-test.example.net and it works. ssh-test.example.net points to 10.238.10.134

This gives me a few new questions:

1) Where does the cloud dns entry come from, it's not automatically setup?
2) What do it point to?
3) Your not in the VPC but still you can ssh to 10.238.10.134, are you on a VPN or is there a router which are using (company network)?

[JasperWoo]

@rickard-von-essen Thanks for your follow up. To answer your questions:
1 & 2: The cloud dns comes from the A record we created in GCP Cloud DNS console, with ip address 10.128.7.231 and DNS name ssh-test.example.net
3: I am on company network VPN. As soon as I left company VPN, I cannot ssh using DNS name ssh-test.example.net. I get this error: ssh: connect to host ssh-test.example.net port 22: Operation timed out

[rickard-von-essen]

What's the output of:

gcloud dns record-sets list --zone example.net --name ssh-test.example.net.

[rickard-von-essen]

From the dig command you can see that

ssh-test.example.net. 5 IN A 10.238.10.134

not 10.128.7.231 as you state above.

[rickard-von-essen]

And if you ssh to the dns name and run

curl http://metadata.google.internal/computeMetadata/v1/instance/id

[JasperWoo]

@rickard-von-essen
10.128.7.231 is the internal IP address shown for the instance on GCP console. The reason dig command shows 10.238.10.134 is unknown to me and is related to the setup by our security team.

Running gcloud dns record-sets list --zone security-zone --name ssh-test.example.net gives me:

NAME                            TYPE  TTL  DATA
ssh-test.example.net.  A     300  10.128.7.231

Running curl http://metadata.google.internal/computeMetadata/v1/instance/id gives me:

<!DOCTYPE html>
<html lang=en>
  <meta charset=utf-8>
  <meta name=viewport content="initial-scale=1, minimum-scale=1, width=device-width">
  <title>Error 403 (Forbidden)!!1</title>
  <style>
    *{margin:0;padding:0}html,code{font:15px/22px arial,sans-serif}html{background:#fff;color:#222;padding:15px}body{margin:7% auto 0;max-width:390px;min-height:180px;padding:30px 0 15px}* > body{background:url(//www.google.com/images/errors/robot.png) 100% 5px no-repeat;padding-right:205px}p{margin:11px 0 22px;overflow:hidden}ins{color:#777;text-decoration:none}a img{border:0}@media screen and (max-width:772px){body{background:none;margin-top:0;max-width:none;padding-right:0}}#logo{background:url(//www.google.com/images/branding/googlelogo/1x/googlelogo_color_150x54dp.png) no-repeat;margin-left:-5px}@media only screen and (min-resolution:192dpi){#logo{background:url(//www.google.com/images/branding/googlelogo/2x/googlelogo_color_150x54dp.png) no-repeat 0% 0%/100% 100%;-moz-border-image:url(//www.google.com/images/branding/googlelogo/2x/googlelogo_color_150x54dp.png) 0}}@media only screen and (-webkit-min-device-pixel-ratio:2){#logo{background:url(//www.google.com/images/branding/googlelogo/2x/googlelogo_color_150x54dp.png) no-repeat;-webkit-background-size:100% 100%}}#logo{display:inline-block;height:54px;width:150px}
  </style>
  <a href=//www.google.com/><span id=logo aria-label=Google></span></a>
  <p><b>403.</b> <ins>That’s an error.</ins>
  <p>Your client does not have permission to get URL <code>/computeMetadata/v1/instance/id</code> from this server. Missing Metadata-Flavor:Google header. <ins>That’s all we know.</ins>

[rickard-von-essen]

Oh forgot to needed header:

curl "http://metadata.google.internal/computeMetadata/v1/instance/id" -H "Metadata-Flavor: Google"

Can you update the result.

[JasperWoo]

@rickard-von-essen Thanks for the update. This is what's returned:
8891099320207480912

[JasperWoo]

@rickard-von-essen
I understand that AWS provides an API to return the public dns name to use for the ec2 instance per the code here.

But in our case, we already know that dns name we want to use, and we know that ssh <username>@<dns_name> works.

I see that in the code, the connection is built using go/net/DialTimeout here

And I see that this method does take public DNS name / host name as input here

So can packer simply provide an option for the user to specify known DNS name to use during ssh connection, and have that to be injected in the DialTimeout method above.

[rickard-von-essen]

You can use ssh_host to tell packer where to connect.

But when packer launches a new instance it's not very likely that it has a DNS name, unless you have some automatic system that creates one for each instance for you.

[JasperWoo]

@rickard-von-essen
Thanks! For now, we can use -debug to pause after the instance creation, and create the DNS record manually. After making sure it's all set up correctly, we will automate this process.

However, when I use ssh_host to specify DNS name like test-ssh.example.com, Packer does not respect it and continues to ssh using internal IP address like this:

[DEBUG] TCP connection to SSH ip/port failed: dial tcp 10.128.7.245:22: i/o timeout
==> googlecompute: Timeout waiting for SSH.

Does that mean ssh_host is not working as expected?

[rickard-von-essen]

@JasperWoo that's a bug, I created #7823.

[JasperWoo]

@rickard-von-essen
Thanks for acknowledging this. Please let me know if I can help contribute to this. We would love this to be fixed ASAP.

[hashibot[bot]]

I'm going to lock this issue because it has been closed for _30 days_ ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.