How do I use gcloud compute ssh with ssh's -t flag (pseudo-terminal allocation)?
You can use --ssh-flag to pass the flags to the ssh command.
gcloud compute ssh INSTANCE --zone=ZONE --ssh-flag="-t"
Related
Connection to created Droplet via SSH by Github Actions runner.
My steps:
ssh-keygen -t rsa -f ~/.ssh/KEY_NAME -P ""
doctl compute ssh-key create KEY --public-key "CONTENT OF KEY_NAME.pub"
doctl compute droplet create --image ubuntu-20-04-x64 --size s-1vcpu-1gb --region fra1 DROPLET_NAME --ssh-keys FINGERPRINT --wait
ssh -vvv -i ~/.ssh/KEY_NAME root#DROPLET_IP
✔️ Tested on Windows local machine using doctl.exe runned from cmd - works!
✔️ Tested on Docker (installed on Windows) based on Linux image using doctl script - works!
⚠️ Tested on Github Actions runner based on ubuntu-latest using digitalocean/action-doctl script - doesn't work!
Received message is: connect to host ADDRESS_IP port 22: Connection refused.
So the steps are correct, so why does this not work for Github Actions?
If you are using the GitHub Action digitalocean/action-doctl, check issue 14 first:
In order to SSH into a Droplet, doctl needs access to the private half of the SSH key pair whose public half is on the Droplet.
Currently the doctl Action is based on a Docker container.
If you were using the Docker container directly, you could invoke it with:
docker run --rm --interactive --tty \
--env=DIGITALOCEAN_ACCESS_TOKEN=<YOUR-DO-API-TOKEN> \
-v $HOME/.ssh/id_rsa:/root/.ssh/id_rsa \
digitalocean/doctl compute ssh <DROPLET-ID>
in order to mount the SSH key from outside the container.
You might be better off just using doctl to grep the Droplet's IP address and using this Action that is more focused on SSH related use cases and provides a lot of additional functionality: marketplace/actions/ssh-remote-commands.
I've been trying to create a cluster in Dataproc using as initialization script the jupyter repository.
But when I try to ssh to the master so to be able to access the Jupyter interface running this command:
gcloud compute ssh --zone=zone_name \
--ssh-flag="-D 10000" \
--ssh-flag="-N" \
--ssh-flag="-n" "cluster1-m" &
I get the error:
Permission denied (publickey). ERROR: (gcloud.compute.ssh)
[/usr/bin/ssh] exited with return code [255].
I could confirm that all ssh keys are created normally. I tried this other option then:
gcloud compute ssh --zone=zone_name \
--ssh-flag="-D 10000" \
--ssh-flag="-N" \
--ssh-flag="-n" "will#cluster1-m" &
Which seems to work as I can ssh into the instance but now I get the error:
bind: Cannot assign requested address
channel_setup_fwd_listener_tcpip: cannot listen to port: 10000 Could
not request local forwarding.
For creating the cluster I used:
gcloud dataproc clusters create $CLUSTER_NAME \
--metadata "JUPYTER_PORT=8124,JUPYTER_CONDA_PACKAGES=numpy:pandas:scikit-learn:jinja2:mock:pytest:pytest-cov" \
--initialization-actions \
gs://dataproc-initialization-actions/jupyter/jupyter.sh \
--bucket $BUCKET_NAME
and I'm running this in a docker image Debian 8.9 (jessie).
If you need any extra information please let me know.
If you verified you can do a normal SSH into the cluster, then if you're just getting the bind: Cannot assign requested address error it probably means you have another SSH session with local port forwarding already on your current machine using port 10000 already. If you see the bind error, you should always first try a different local port, like -D 12345. You can use top or your task manager to check if you have a hanging ssh -D command somewhere still running and occupying port 10000.
For some reason ssh doesn't work to set up a tunnel to my Google Compute Engine instance. I have to use gcloud compute ssh. I'd really like to set up a persistent/resilient tunnel, like one gets with autossh. Is there any way I can do so using gcloud compute ssh?
gcloud compute ssh simply copies your ssh key to the project sshKeys metadata (see Cloud Console > Compute Engine > Metadata > SSH Keys) and runs standalone SSH with the ~/.ssh/google_compute_engine key. To see the exact command line invoked, run gcloud compute ssh --dry-run .... Anything that's possible with typical SSH is possible with gcloud compute ssh.
Another option to investigate is gcloud compute config-ssh, which syncs your ~/.ssh/google_compute_engine SSH key to the project and sets up your ~/.ssh/config file so that you can run ssh without gcloud.
I am trying to ssh into a VM from another VM in Google Cloud using the gcloud compute ssh command. It fails with the below message:
/usr/local/bin/../share/google/google-cloud-sdk/./lib/googlecloudsdk/compute/lib/base_classes.py:9: DeprecationWarning: the sets module is deprecated
import sets
Connection timed out
ERROR: (gcloud.compute.ssh) [/usr/bin/ssh] exited with return code [255]. See https://cloud.google.com/compute/docs/troubleshooting#ssherrors for troubleshooting hints.
I made sure the ssh keys are in place but still it doesn't work. What am I missing here?
There is an assumption that you have connected to the externally-visible instance using SSH beforehand with gcloud.
From your local machine, start ssh-agent with the following command to manage your keys for you:
me#local:~$ eval `ssh-agent`
Call ssh-add to load the gcloud compute public keys from your local computer into the agent, and use them for all SSH commands for authentication:
me#local:~$ ssh-add ~/.ssh/google_compute_engine
Log into an instance with an external IP address while supplying the -A argument to enable authentication agent forwarding.
gcloud compute ssh --ssh-flag="-A" INSTANCE
source: https://cloud.google.com/compute/docs/instances/connecting-to-instance#sshbetweeninstances.
I am not sure about the 'flags' because it's not working for me bu maybe I have a different OS or Gcloud version and it will work for you.
Here are the steps I ran on my Mac to connect to the Google Dataproc master VM and then hop onto a worker VM from the master MV. I ssh'd to the master VM to get the IP.
$ gcloud compute ssh cluster-for-cameron-m
Warning: Permanently added '104.197.45.35' (ECDSA) to the list of known hosts.
I then exited. I enabled forwarding for that host.
$ nano ~/.ssh/config
Host 104.197.45.35
ForwardAgent yes
I added the gcloud key.
$ ssh-add ~/.ssh/google_compute_engine
I then verified that it was added by listing the key fingerprints with ssh-add -l. I reconnected to the master VM and ran ssh-add -l again to verify that the keys were indeed forwarded. After that, connecting to the worker node worked just fine.
ssh cluster-for-cameron-w-0
About using SSH Agent Forwarding...
Because instances are frequently created and destroyed on the cloud, the (recreated) host fingerprint keeps changing. If the new fingerprint doesn't match with ~/.ssh/known_hosts, SSH automatically disables Agent Forwarding. The solution is:
$ ssh -A -o UserKnownHostsFile=/dev/null ...
I've setup 2 Google Compute Engine instances and I can easily SSH in both of them by using the key created by gcloud compute ssh command. But when I try the following...
myself#try-master ~] ssh-keygen -q -t rsa -N "" -f ~/.ssh/id_rsa
myself#try-master ~] cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys
myself#try-master ~] chmod 0600 ~/.ssh/authorized_keys
myself#try-master ~] ssh-copy-id -i ~/.ssh/id_rsa.pub myself#try-slave-1
... it does not work, and ssh-copy-id shows the message below:
Permission denied (publickey,gssapi-keyex,gssapi-with-mic)
If I copy the google_compute_engine private and public key on try-master, and can use it to log on both instances, but I find unsatisfactory to move a private key over the network. I guess this is somewhat related to this topic:
How can this be solved?
[1] https://cloud.google.com/compute/docs/instances#sshbetweeninstances
Using CentOS7 images, and a CentOs7 as local host:
gcloud compute instances create try-master --image centos-7
gcloud compute instances create try-slave-1 --image centos-7
This can be solved by using authentication forwarding during initial SSH keys setup:
Set up authentication forwarding for once on local machine (note the "-A" flag). First you need to run:
eval `ssh-agent -s`
And then
ssh-add ~/.ssh/google_compute_engine
gcloud compute ssh --ssh-flag="-A" try-master
Perform the steps above (from keygen to ssh-copy-id)
myself#try-master ~] ssh-keygen -q -t rsa -N "" -f ~/.ssh/id_rsa
myself#try-master ~] cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys
myself#try-master ~] chmod 0600 ~/.ssh/authorized_keys
myself#try-master ~] ssh-copy-id -i ~/.ssh/id_rsa.pub myself#try-slave-1
myself#try-master ~] exit
Login again into try-master without SSH authentication forwarding:
gcloud compute ssh try-master
myself#try-master ~] ssh myself#try-slave-1
myself#try-slave-1 ~]
Initial approach didn't work because GCE instances only allow public key authentication by default. So, ssh-copy-id is unable to authenticate against try-slave to copy the new public key, because there is no public key configured in try-master available in try-slave yet.
Using authentication forwarding, the private key from your local machine is forwarded from your local machine to try-master, and from there to try-slave. GCE account manager in try-slave will fetch the public key from your project metadata and thus ssh-copy-id will be able to copy work.