SSH authentication fails if constraints/compute.requireOsLogin is enforced #852
Comments
|
Hi Thorsten, could you provide us a bit more information pls. a) which guide: github or suse getting started docu
|
|
@petersatsuse, Thorsten uses the SBP guide I created for GCP. @tstaerk, I would advise the following:
Some other required information:
There is the list of the required logs (each of the deployed machines will have all of them):
|
|
just realized I did not define a VPC... if there is only one, can't it use this? |
|
OK, I am using GCP and the following tfvars file: project = "thorstenstaerk-suse-terraforms" |
|
I have just completed a successful deployment using the most recent version, 8.1.0, using the following I see that we use almost the same configurations. Please ensure that you use the most recent version, 8.1.0, the master branch? |
|
git pull tells me "already up to date" |
|
Can you please try a fresh clone before digging into the issue? |
|
deleted and re-checked out |
|
OK, your and my terraform.tfvars is identical with the exception of passwords, names and your two lines hana_primary_site = "NUE" |
|
I repeated with my old terraform.tfvars and I get: module.hana_node.module.hana-load-balancer[0].google_compute_health_check.health-check: Creating... |
|
after deleting all the stuff above and re-starting terraform apply, I now get: │ Error: Error creating InstanceGroup: googleapi: Error 409: The resource 'projects/thorstenstaerk-suse-terraforms/zones/europe-west1-b/instanceGroups/demo-hana-primary-group' already exists, alreadyExists |
|
ssh cannot work, as Cloud Shell does not have network connection to a host inside a GCP project |
|
130.211.104.240 is demo-vmhana01 |
|
@tstaerk, please execute the When you ssh to the HANA node using the public IP address, you need to use the used SSH in the |
|
Hi, I do not call ssh. I get an error that ssh is not possible and I think this is because of the isolation between cloud shell and VMs. |
|
ok, makes sense - you use the public IP address. Here is what I get: admin_@cloudshell:~$ ssh -i .ssh/id_rsa [email protected] |
|
Three possible troubleshooting steps:
|
|
Two questions come to mind:
|
This is perfectly fine that this fails. Just make sure you delete the old host key from you known_hosts. |
This is the clusters's ssh key. Normally you don't have to temper with this.
You CAN connect via ssh/port-22 so this will not be a firewall issue. @tstaerk The ssh keys that are used by terraform to connect via ssh and run salt are these: Did you create these and are you using these also in your test? |
|
@tstaerk In addition to @yeoldegrove notes and questions, you may manually attach the SSH public keys to your nodes as a troubleshooting step. |
|
added the authorized_keys file manually to both nodes, now the install looks like it's doing sth! |
|
install finished, hdbsql answers my SQL queries. Please make sure the authorized_keys get created automatically! |
|
@tstaerk There is of course already code that handles this https://github.com/SUSE/ha-sap-terraform-deployments/blob/main/gcp/modules/hana_node/main.tf#L155 |
|
reproducing it now |
|
@yeoldegrove : looking at https://github.com/SUSE/ha-sap-terraform-deployments/blob/main/gcp/modules/hana_node/main.tf#L155, you only add the ssh key to the instance's metadata, so, ssh passwordless login would only work if the project is set to os_login=false, right? Ever tested it with os_login=true? |
|
@tstaerk I still do not get which exact problem you're having and trying to solve. Could you elaborate on that? ssh keys are added to the instance's metadata the usual way as you pointed out. Also, I am not sure what you mean by |
|
you would go to cloud console, search for "Metadata", select it, and there you set the key os_login and the value false. Then, the ssh key set in https://registry.terraform.io/providers/hashicorp/google/latest/docs/resources/compute_instance#metadata will be respected. |
|
@tstaerk are you talking about https://console.cloud.google.com/compute/metadata where I could set e.g. https://cloud.google.com/compute/docs/oslogin/set-up-oslogin ? Just that I do not miss anything out... Could you please sum-up what exactly is not working for you (your use case) and how you solve it exactly? Would just setting |
|
We found the error, we had an organisation policy (constraints/compute.requireOsLogin) active that enforced every project to have enable-oslogin=true. This led to the ssh error: The issue was that the public ssh key was not automatically added to the HANA node's authorized_keys. To change this, we set enable-oslogin=false in the project metadata, see Screenshot:
then, ssh'ing worked and the key could be found in authorized_keys: So, one solution would be to manually copy the public ssh key into the OS' authorized_keys file. Another option could be to check if constraints/compute.requireOsLogin is enforced and if yes, tell the user that they have to manually copy the ssh key to all nodes. |
tstaerk
changed the title
|
Hi @yeoldegrove thanks for all your contributions here. @ab-mohamed and I really invested a lot of work debugging a "it all boils down to doesn't work" issue. And arrived at a conclusion - if you have a org policy requiring OS Login, you get an error message like in the description. Solution: remove this org policy and enable OS Login. If you cannot do this, manually go to the hana nodes and add the public key to authorized_keys. Would it be possible to document this or implement a respective error message/policy check? |
|
@tstaerk Ok, so this is global setting which is not directly related to this project but gets in the way ... Could you check if it would be sufficient to set It would have to be added to every module that builds up compute instances... like here: If this does not work we should definitely write something into the |
|
If you have an organization policy that forbids it, you cannot set metadata = { enable-oslogin = false, sshKeys = "..." } |
|
OK, I propose that we add the error message to the documentation and explain how to check if the issue is about the organizational policy. And how to resolve it if you have the Org Policy Admin role. |
|
@tstaerk Do you want to make a PR (would be preferred by me as you're more into the topic) or shall I write something up (and let you review it) ? |
|
I work closely with @ab-mohamed I think we could come up with sth |
Following your guide, I get when I type terraform apply:
module.hana_node.null_resource.hana_node_provisioner[1]: Still creating... [5m0s elapsed]
╷
│ Error: file provisioner error
│
│ with module.hana_node.null_resource.hana_node_provisioner[1],
│ on modules/hana_node/salt_provisioner.tf line 23, in resource "null_resource" "hana_node_provisioner":
│ 23: provisioner "file" {
│
│ timeout - last error: SSH authentication failed ([email protected]:22): ssh: handshake failed: ssh: unable to authenticate, attempted methods [none publickey], no supported methods remain
The text was updated successfully, but these errors were encountered: