0

We have problems with SSH, both with creating the keys yourself, and also the same problem exists with gcloud creating the keys.

To demonstrate that this is not a problem self-created we performed the following:

  1. We created a temporary server via gcloud: gcloud compute instances create temp-machine --scopes compute-rw
  2. We then SSH into the temp-machine instance: gcloud compute ssh temp-machine

  3. As we had no key defined, the command in step 2 creates a key pair for us with the following results:

    WARNING: The private SSH key file for Google Compute Engine does not exist.
WARNING: You do not have an SSH key for Google Compute Engine.
WARNING: [/usr/bin/ssh-keygen] will be executed to generate a key.
Generating public/private rsa key pair.
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/davebeach/.ssh/google_compute_engine.
Your public key has been saved in /home/davebeach/.ssh/google_compute_engine.pub.

  4. Once gcloud creates the key pair, it proceeds to use the keys to log on to the temp-machine instance. It successfully logs in and adds entry to google_known_hosts on local machine.

    updating project ssh metadata...\Updated     [https://www.googleapis.com/compute/v1/projects/pro-ppm].
Updating project ssh metadata...done.
Warning: Permanently added 'compute.3605686430923056095' (ECDSA) to the list of known hosts.

  5. Then we shut down the connection and attempt to rerun the SSH connection. When it attempts to use the keys that gcloud created in prior steps, it states that the keys are an invalid format:

    OpenSSH_7.3p1, OpenSSL 1.0.2j  26 Sep 2016
debug1: Reading configuration data /Users/davebeach/.ssh/config
debug1: Reading configuration data /usr/local/etc/ssh/ssh_config
debug2: resolving "130.211.121.82" port 22
debug2: ssh_connect_direct: needpriv 0
debug1: Connecting to 130.211.121.82 [130.211.121.82] port 22.
debug1: Connection established.
key_load_public: invalid format

  6. The logon continues and it instead finds the google_known_hosts file, and pulls a key out of this file, and uses this file to successfully authenticate with the server:

    debug1: identity file /Users/davebeach/.ssh/google_compute_engine type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/davebeach/.ssh/google_compute_engine-cert type -1
debug1: identity file /Users/davebeach/.ssh/id_ed25519 type 4
debug1: key_load_public: No such file or directory
debug1: identity file /Users/davebeach/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.3
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.7p1 Debian-5+deb8u3
debug1: match: OpenSSH_6.7p1 Debian-5+deb8u3 pat OpenSSH* compat 0x04000000
debug2: fd 3 setting O_NONBLOCK
debug1: Authenticating to 130.211.121.82:22 as 'davebeach'
debug1: using hostkeyalias: compute.3605686430923056095
debug3: hostkeys_foreach: reading file "/Users/davebeach/.ssh/google_compute_known_hosts"
debug3: record_hostkey: found key type ECDSA in file /Users/davebeach/.ssh/google_compute_known_hosts:6
debug3: load_hostkeys: loaded 1 keys from compute.3605686430923056095
debug3: order_hostkeyalgs: prefer hostkeyalgs: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-
......
debug1: Server host key: ecdsa-sha2-nistp256   SHA256:f9dkkPHglZNpR0XtAK33OWYNlyLc/jjHsbTpQvyhcys
debug1: using hostkeyalias: compute.3605686430923056095
debug3: hostkeys_foreach: reading file "/Users/davebeach/.ssh/google_compute_known_hosts"
debug3: record_hostkey: found key type ECDSA in file /Users/davebeach/.ssh/google_compute_known_hosts:6
debug3: load_hostkeys: loaded 1 keys from compute.3605686430923056095
debug1: Host 'compute.3605686430923056095' is known and matches the ECDSA host key.
debug1: Found key in /Users/davebeach/.ssh/google_compute_known_hosts:6

  7. The contents of google_known_hosts is created by gcloud only (during the first connection).

Why can we never get the instance to accept the keys that gcloud creates, and why does it use the google_known_hosts keys as acceptable keys? Is there a setting in SSHD_CONFIG that is causing this etc? And what is wrong with the format to the original key that is created on our behalf?

kasperd
  • 30,455
  • 17
  • 76
  • 124
David Beach
  • 1
  • 1
  • lets start reading something about ssh. You miss a lot of points in your diagnose and therefore it does not make sense what you ask. – Jakuje Nov 20 '16 at 08:21
  • I thought this site was to inquire about issues, the above steps are performed exactly how Google's documentation says to do it (and yes I agree it doesn't make sense, thus why I do not get it). The instructions are https://cloud.google.com/compute/docs/instances/adding-removing-ssh-keys – David Beach Nov 21 '16 at 03:29
  • I am just following Google troubleshooting guide for SSH. On a fresh install, using gcloud, it never actually uses the keys that are in the meta data for the instance, it only accepts the hosts keys in the client known_hosts file. I am not an expert, thus why I did this post, to see if something that makes no sense to me, also made no sense. This is in reference to a larger issue that we see if the linux deployment stacks, gcloud and SSH. It used to work, now it always has issues related to SSH. – David Beach Nov 21 '16 at 03:47
  • The purpose of the above steps was to SSH using the new user created on the temp instance, to then log into a instance that is not accepting any SSH requests, to see if that solves the problem. The results when this was attempted was that it fails due to invalid key format. – David Beach Nov 21 '16 at 03:52
  • No, this site is not about issues. This site is Q&A (question and answer). If you ask a good question, you will get a good answer (usually). There is too many questions which does not make a lot of sense, but I will try ... – Jakuje Nov 21 '16 at 07:43

2 Answers2

1

This output from your first invocation looks relevant to me:

Your identification has been saved in /home/davebeach/.ssh/google_compute_engine.

This output from your second invocation looks relevant to me:

debug1: identity file /Users/davebeach/.ssh/google_compute_engine type -1

The first invocation states a key file has been saved, the second invocation states it has tried to load a key file but it failed. The reason the second invocation cannot load the key file created by the first invocation appears to be that you are not using the same file name.

In the first invocation the path starts with /home in the second invocation the path starts with /Users. You should verify that any paths in your environment variables are correct - in particular HOME. You should also verify that any paths in your configuration files are correct, in particular I would pay attention to any paths in ~/.ssh/config.

kasperd
  • 30,455
  • 17
  • 76
  • 124
0

Why can we never get the instance to accept the keys that gcloud creates, and why does it use the google_known_hosts keys as acceptable keys?

You generate the instance server host keys. It does not have anything in common with authentication keys.

Is there a setting in SSHD_CONFIG that is causing this etc?

Causing what?

And what is wrong with the format to the original key that is created on our behalf?

How does the key look like?

Jakuje
  • 9,715
  • 2
  • 42
  • 45