Reputation: 4754
We have two GKE private clusters, where access is only possible via ssh proxy.
In the local environment this works this way:
Open a ssh connection with port 8888 forwarding to the bastion host
gcloud compute ssh dev-cluster-bastion --project client-dev --zone xxxx -- -L 8888:127.0.0.1:8888
In another session
HTTPS_PROXY=localhost:8888 kubectl get pods
This returns the list of the running pods.
When we do this inside a bitbucket pipeline, then the ssh connects, but then closes and the kubectl
call fails.
The message from the ssh connection is:
Pseudo-terminal will not be allocated because stdin is not a terminal
So the portforwarding is closed too.
Adding -fN
to the ssh start does not help, the port forwarding is not working.
gcloud compute ssh dev-cluster-bastion --project client-dev --zone xxxx -- -fN -L 8888:127.0.0.1:8888
ssh then tells me client_loop: send disconnect: Connection reset by peer
Any ideas how to open the port 8888 tcp tunnel inside a bitbucket pipeline, so we can send the kubectl commands to the cluster?
Upvotes: 0
Views: 1362
Reputation: 291
The recommended way to use Google Cloud APIs in a non-interactive setting (like Bitbucket pipelines, GitHub actions, etc.) is to:
gcloud auth activate-service-account --key-file=...
to make gcloud
use the service accountgcloud compute ssh
in the pipeline and use SSH port forwarding as usual.Note that:
-fN
flags, which execute SSH in the background and make it run no command on the remote host (i.e. only do port forwarding).You can also refer to Service account creation and Get started with Bitbucket-pipeline for more information.
Upvotes: 1
Reputation: 291
To fix this error Pseudo-terminal will not be allocated because stdin is not a terminal. follow one of the below steps:
The error occurred because you're running SSH with a single -t option, when the standard input to the SSH process isn't a TTY. SSH prints that message specifically in this case A single -t is equivalent to "RequestTTY yes", while two of them is equivalent to "RequestTTY force".
If you want your remote command(s) to run with a TTY, then specify -t twice. If you are doing so then in your command instead of -t use -t -t or use -tt .
To fix this error client_loop: send disconnect: Connection reset by peer follow the below steps:
You shall look on these parameters on the client
side /etc/ssh/ssh_config
ServerAliveInterval
ServerAliveCountMax
To set the interval to the value 60 and try
ServerAliveInterval 60
Upvotes: 0