SSH to master node via Bastion node

Nikolaasdb · ‎10-04-2019

I've followed the AWS quick installer guide and used the OpenShift installer to create my infrastructure on AWS. I have a bastion installed manually and added it to the VPC that the terraform file from the OpenShift installer creates.

I would like to be able to SSH to a master node on my OpenShift cluster from my Bastion server, but I'm not sure what user and password to give.
The environment and the bastion machine are all created using the same SSH key.

flozano · ‎10-08-2019

You need to use the private SSH key that corresponds to the public SSH key you provided to openshift-install. There is no user with any password on the master (nor the worker nodes). The only option is key-based authentication.

Be warned that SSH access to any node "taints" it. It will be unschedulable until you untaint it. OpenShift does not want that you SSH into nodes. Most of the times you can use "oc debug node/name-of-the-node" to get a local prompt to perform tasks such as review systemd logs, check installed RPM packages, etc.

The idea is that OpenShift manages the nodes. if you want to open SSH sessions to change local configuration files and install software such as a backup agent, you are not doing it right. All configuration files would be managed by operators, using machineconfig resources and other CRDs. Software that you want to install on nodes need to be containers managed by daemon sets.

Edvin · ‎05-26-2020

Got a question about this post today so I thought I would clarify.

To my knowladge you don't get a taint on your node when you ssh in to the node, this might be something that happend in 4.0? I tried this today on my OCP 4.4 installation and I don't get any taints. So you don't have to do any blocking to make sure no admin ssh in to the nodes by misstake and ruins a node.

But just as @flozano writes you shoulden't ssh in to the node becouse there is no reason to, handle all the config on the nodes with machineconfig etc.

flozano · ‎05-26-2020

Yes it is a new thing from OpenShift 4.x. It taints nodes on SSH accesses because OpenShift expects that you use the Machine API to configure your nodes.

flozano · ‎05-27-2020

I confirmed that sometimes that annotation and taint are not applied to nodes after SSH access. I am trying to get a list of schenarios when it is and when it is not aplied.

Bottom line is:

- It is recommended that you avoid doing manual configs using SSH. Even if they seem to work initially, some operator may override your manual settings later, or fail because you chaged something you weren't supposed to.

- Do not rely on the annotation and taint to learn that someone "broke the rules". Keep tight control of who has SSH access to nodes.

- Using oc debug node you can do much of the same "damange" you could do using direct SSH access. That's another reason to not rely just on the annotation and taint.

HelmaD · ‎03-26-2023

https://access.redhat.com/solutions/6221581

Important note: By design, OpenShift 4 clusters are immutable and rely on Operators to apply cluster changes. In turn, this means that accessing the underlying nodes directly by SSH is not the recommended procedure. Additionally, the nodes will be tainted as accessed.