Improvement suggestion for ADDING A BASTION HOST TO OUR CLUSTER documentation

[vkotheka]

1. What kops version are you running? The command kops version, will display
this information.
Version 1.18.0

2. What Kubernetes version are you running? kubectl version will print the
version if a cluster is running or provide the Kubernetes version specified as
a kops flag.
Client Version: version.Info{Major:"1", Minor:"16+", GitVersion:"v1.16.6-beta.0", GitCommit:"e7f962ba86f4ce7033828210ca3556393c377bcc", GitTreeState:"clean", BuildDate:"2020-01-15T08:26:26Z", GoVersion:"go1.13.5", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"18", GitVersion:"v1.18.6", GitCommit:"dff82dc0de47299ab66c83c626e08b245ab19037", GitTreeState:"clean", BuildDate:"2020-07-15T16:51:04Z", GoVersion:"go1.13.9", Compiler:"gc", Platform:"linux/amd64"}

3. What cloud provider are you using?
AWS

4. What commands did you run? What is the simplest way to reproduce this issue?
This is a documentation issue on https://github.com/kubernetes/kops/blob/master/docs/examples/kops-tests-private-net-bastion-host.md#adding-a-bastion-host-to-our-cluster

5. What happened after the commands executed?
No commands executed as this is a doc issue

6. What did you expect to happen?
The doc provides example to ssh assuming the user = admin
Which is not always the case because if it's an ubuntu image underlying then it will be ubuntu user. That makes sense and is obvious.

However, if we don't explicitly mention that please use the appropriate user for ssh then a reader may think:

• admin user is created by KOPS behind the scene on bastion and cluster nodes.

It's not a big issue but just adding that line of caution will help if somebody runs into this trap.

The problem is when I ssh using admin@LB-bastion, it doesn't say invalid user - it gives an error
admin@LB-bastion: Permission denied (publickey).
which unfortunately is misleading

[h3poteto]

Hi, I will take this issue.

/assign

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[h3poteto]

/close

[k8s-ci-robot]

@h3poteto: Closing this issue.

In response to this:

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.