Starting with a service account JSON key, I attempt to add a throwaway "foo" ssh key to the gcloud instances create metadata and then connect to the instance using vanilla ssh and the throwaway key.
Script
here.
Expected behavior
At boot, the account daemon would create a user account corresponding to the supplied ssh key.
Observed behavior
In the Cloud Console, the instance shows correctly applied ssh metadata.
ssh -i throwaway_private_key foo#${IP} fails.
Logs on the instance show:
Apr 6 16:58:34 sshkey-test-x0rmqgh7 sshd[497]: Invalid user foo from 209.6.197.126 port 39792
How do I correctly trigger the account daemon?
If not through the metadata, then what?
Thanks!
For anyone struggling with a similar issue, there is a HUGE gotcha with os-login that can lead to the problem behavior.
In a nutshell, os-login="TRUE" can be (and is likely to be) set project-wide on GCE. If that's the case, then ssh-key metadata is ignored. I only discovered this by chance from reading other issues in the Google bug tracker.
As soon as I toggled os-login, my issue went away.
I am unable to connect through SSH to my GCE instance. I was connecting without any problem, the only think I changes was my user name through top right corner of the browser then selected Change Linux Username.
When I try to ssh into my google engine via browser, I keep having following message in a endless loop:
When I try to ssh via cloud shell I also get following error message, (serial console output):
Permission denied (publickey).
ERROR: (gcloud.compute.ssh) [/usr/bin/ssh] exited with return code [255].
[Q] Is there any way to fix this problem? Since I have no access to the engine now, I don't know what to do.
However you could always get back access through serial console then from there you could internally y troubleshoot user/ssh issue.
1) $ gcloud compute instances add-metadata [INSTANCE_NAME] --metadata=serial-port-enable=1
You can then connect to the instance through the serial port
NOTE:The root password have must been already set in order to use the serial port
2)
$ gcloud compute connect-to-serial-port [INSTANCE_NAME]
If you never set the root password you could set it by adding a startup-script to your instance that will set a password as root by running the below command :
NOTE: the instance must be rebooted in order to run the startup script.
3) $ gcloud compute instances add-metadata [instance name] --metadata startup-script='echo "root:YourPasswdHere" | chpasswd'
Reboot the instance run the command on the step "2)" authenticate your self as root with the password that you set on the startup script in the step "3)" .
I had the same problem, It took me several days to figure out what was happening in my case.
To find out, I created a new instance from scratch and started making all modifications I've done to those that eventually couldn't connect to, one by one, exiting the ssh connection and re entering so as to test it.
I've tried it a couple of times, in both cases, the connection was impossible after uninstalling python (I only needed 3.7 version so I was uninstalling all others and installing that one I needed).
My command for uninstalling it was
sudo apt purge python2.7-minimal
and
sudo apt purge python3.5-minimal
I don't know if it was specifically because of deleting python, or because of using purge (in which case this problem might reproduce if using purge with another program).
I don't even know why would this affect ssh connection.
Could it be that google cloud is somehow using destination python for the ssh web?
In any case, if you are experiencing this problem try to avoid uninstalling anything from the base VM.
I am following the steps here, to setup a CloudSQL DB in Google Cloud Platform. I'm stuck at the step with:
./cloud_sql_proxy -instances="[YOUR_INSTANCE_CONNECTION_NAME]"=tcp:3306
I get the message below:
2018/02/07 19:44:10 listen tcp 127.0.0.1:3306: bind: address already in use
I've tried: lsof -i tcp:3306 but nothing shows up. Alternatively, I am able to start a connection to tcp:3307, but that's not what's required in the tutorial, and may prevent the rest of the tutorial from working. When I do lsof -i tcp:3307 however, I am able to see the PID, and kill the SQL connection.
How is the port address 3306 already in use?? Even rebooted my computer.
My Steps I took to fix
I stop Mysql on my local machine
brew services stop mysql
But I had a problem of giving a directory for
Directory to use for placing Unix sockets representing database instances as seen by the console error
Then I did
sudo mkdir /cloudsql; sudo chmod 777 /cloudsql
My Final Script
./cloud_sql_proxy -instances=MyInstanceConnName=tcp:3306 -projects=myproject -dir=/cloudsql/
UPDATE: After trying to dig through many methods to kill the sql process, find out whats actually running on it, joining the gcloud slack group to ask around, etc etc, I ended up uninstalling mysql, and reinstalling it. Fixed it. :shrug:
About once every 10 years I need to wrestle with SAMBA as I migrate to new hosts, and then I repress the traumatic memory until I have to relearn it all the next time :S Hence this newbyish question.
I have a Ubuntu VM with a couple of shares - one ("Public") is unsecured, the other ("Public2") is secured, with the intention that it should be accessed only by an authenticated user account defined on the Ubuntu box. Both shares appear in Windows Explorer on both XP and Win8.1. However, I can't for the life of me work out how to log into the secure Public2 share.
Leaving Windows clients out of it, I've tried simply looping back to the box using smbclient, which produces the following output, indicating it just can't authenticate:
michael#ubuntu:~$ smbclient //ubuntu/Public2 --user=michael%mypasswd
Domain=[WORKGROUP] OS=[Unix] Server=[Samba 4.1.6-Ubuntu]
tree connect failed: NT_STATUS_ACCESS_DENIED
Meanwhile the unsecured share is accessible.
What (probably incredibly obvious) thing have I missed? Am I not specifying the username correctly?
/var/lib/samba/usershares/public (unsecure, works) contains:
#VERSION 2
path=/home/michael/Public
comment=
usershare_acl=S-1-1-0:F
guest_ok=y
sharename=Public
/var/lib/samba/usershares/public2 (which I can't access) contains:
#VERSION 2
path=/home/michael/Public2
comment=
usershare_acl=S-1-1-0:F
guest_ok=n
sharename=Public2
For users who are using for the command line option, use
$ sudo smbpasswd -a <user_name>
this will prompt you to assign the password.
WARNING: This refers to Samba 2. We are at Samba 4 now. Take care which version of Samba you are using. As stated in my comment, the GUI will break your configurations.
A work colleague has pointed me in the right direction:
The Linux user ID being used to access the Linux share needs to have a second "samba" password defined for it. The easiest way to do this is to install and run the GUI Samba Server Configuration app, which isn't installed by default.
The Samba documentation does explain this, but it's buried in the masses of documentation explaining all the various arcane aspects of samba.conf configuration etc.
The following article gets to the heart of the subject:
http://ubuntuhandbook.org/index.php/2014/05/ubuntu1404-file-sharing-samba/
You have to edit the '/etc/samba/smb.conf'
use sudo nano /etc/samba/smb.conf to edit the conf file.
Where Workgroup = [your Domain]
There is no 'second samba password'. There is linux password: /etc/passwd and then there is Samba password, which is either smbpasswd or passdb.tdb. Which one and where it is located depends on Samba version and setting in smb.conf. BOTH must be set. Both means Linux in /etc/passwd and in Samba (one of the above). This is in most cases the issue with this error message. Or try to restart Lanman service, or Windows.
But I want to comment on another, probably rarer case.
If you are using customized Samba and only in such case, there might be another (extended) reason for this error.
Samba might be compiled with additional permission checks, which will say "NO" (return false) after which Samba will announce error, the same as this Q is mentioning.
Check the log for errors. There might be a clue if it is such a case.
Again, this is specific for custom build Samba.
Specifically in my case, on QNAP NAS, Samba will call a binary /sbin/appriv -C -u 502 -S1
-C, --check Check user privilege.
-S, --samba [bit] The privilege of Samba
-u, --uid [uid] UID.
appriv is "appriv -> nasutil" which is QNAP own binary, not part of the linux or the GNU.
With so many options build in Samba, I can't find a reasoning for this additional check.
Especially when it could be satisfied with just a plain empty file returning "true".
Just a complication, possible source of issues, no safety advancement.
I've been updating old abandoned system from QNAP. Replaced Samba from another, newer NAS.
This is how I come about this issue and wasted a lot of time on it. Thanks QNAP.
Apparmor might also be the cause. You need to whitelist all share locations, otherwise you will always get the "permission denied" error.
Fix is adding to /etc/apparmor.d/local/usr.sbin.smbd:
"/path_to_share/" rk,
"/path_to_share/**" lrwk,
for each share. (The first line allows read-access to the base-directory, the second line allows read-write-access to everything within that base-directory recursively)
Source: https://wiki.archlinux.org/title/Samba#Permission_issues_on_AppArmor
Crosspost from: https://serverfault.com/a/1109267/592032
I kept getting kicked out of my compute engine instance after a few seconds of idle with the indicated error (255).
I used 'gcloud compute ssh' to log in.
I am using the default firewall setting, which I believe would be good enough for ssh.
But if I am missing something, please so indicate and suggest the fix for this error.
Basically I can't get any efficient work done at this point having to ssh in so many times.
gcloud denies an ssh connection if there was a change in the setup, e.g.
after you changed your default zone or region, or you created another instance.
Then, you must update the ssh keys in your metadata by
sudo gcloud compute config-ssh
If this complains about different entries in your config file where your ssh key entries are stored, ~/.ssh/config, delete this file and execute the above command again.
If you have installed gcloud without sudo, you can omit sudo.
255 is the interactive ssh exit code for ssh failure - otherwise interactive ssh exits with the exit code of the last command executed in the ssh session.
The next time you get exit code 255 from ssh try running with --ssh-flag="-vvv" (more v's => more debugging output) and see if it helps track down connection problems.
For those who stop by this page. This helped me to solve the problem.
Try to the following:
Go to your Google and remove the SSH key for the server
Go to your google cloud console -> compute engine -> Metadata -> "SSH
keys" tab and click on edit. Here you can delete the ssh keys.
Run the gcloud command again
Click on the "Instances" link on the left side of your google cloud account, which will list down all the instances on the right side. Under
connect column, you will see "SSH" drop-down, click on "View cloud
Command" and this will bring a new dialog. Copy that command and run on your PC's terminal. This will let you SSH into the google compute engine.
It seems a feature/issue from Google Cloud Platform itself, we are going to continue checking it.
If the default network was edited, or if not using the default network, you may need to explicitly enable ssh access by adding a firewall-rule:
$ gcloud compute firewall-rules create --network=YOUR_NETWORK \
default-allow-ssh --allow tcp:22
After that, retry the 'gcloud compute ssh' command.
This is a real problem with very little documentation to dealing with it.
Sometime after creating the instance using the gcloud sdk ssh snippet provided via GCP console stopped working and continually errors with 255 making connecting to ssh on the instance only available through browser via GCP console for the compute instance in question. Not to mention this has happened to me on many different instances some without touching the default account permissions after initial setup and deployment which is overly frustrating. Cause for no reason it just stops working...works, then doesn't...
The only thing that worked for me was creating a new user to connect with through gcloud sdk! Be it Windows/PowerShell or Linux locally, using the following snippet:
gcloud compute ssh newuser-name#instance-name
That all per GCP documentation here: https://cloud.google.com/compute/docs/troubleshooting/troubleshooting-ssh
Everything else passed per suggestions in documentation - port 22 open with access meaning it has to be a a problem with the default users authorization_keys WHICH they provide absolutely no documentation on how to fix that - at least nothing I could find on fixing (not creating or deleting)
I've tried updating the account, tried deleting the user and credentials from the instance, nothing appears to work. using:
gcloud compute --project "project-name" ssh --zone "us-east4-a" "instance-name"
Just doesn't work...
- even tried 'gcloud compute config-ssh --force-key-file-overwrite' NOTHING WORKS...
But creating a new user works every time, and once the user is created you can keep using that user via gcloud sdk
It's a work around, and I hate work around's for things like this but for my sanity this works at least until I can figure out how to reset the default account permissions, so if anyone has any ideas there or can point me in a direction for that I'd more than appreciate it!
IT was my mistake stating that the default firewall would allow all connections into an instance. The contrary turned out to be true. Please refer to an appropriate firewall rule must be set up to allow connection into an instance
Anh-
If you have Identity-Aware Proxy (IAP) enabled for your setup, try adding the --tunnel-through-iap option to the gcloud compute ssh command.
$ gcloud compute ssh --zone <zone> --project <project> --tunnel-through-iap <instance-name>
More information for people landing on this page, if you're using preemptible instances to save some compute costs, that could also be the reason for getting kicked out like this. Your instance may have just randomly stopped.
In my case, the I had created a bootable disk for the VM without adding the information of what source-image it needs to have. Because of this, even though the instance was coming up alright and ssh-allow rule was there, the VM was not booting up.
Finally added the source image to the disk and I was able to ssh into the VM.
Hope this helps for someone.
I had the same error . i restarted the VM instance and ssh workis fine
I had the problem where after clicking on the SSH button it would keep trying to establish a connection and fail. After long struggle I resolved it by adding Service Account User role to myself. If your account was created after the VM instance was created, it might result in this situation.
I know this was opened a long time ago, but for a more recent update on this topic. I had the same trouble connecting via ssh. It was giving the error code 225. Obviously there was a connectivity issue. There was already a firewall rule set under VPC network-> Firewall to allow ssh. However, to fix this problem I had to go to the specific network and create a rule under the network Firewall Rules. VPC network details -> FIREWALL RULES and create an inbound TCP rule for port 22.
if you are having a problem trying to access you g-cloud VM instance from your computer terminal remotely, and are getting the error code 255,the problem is that the ssh protocols in your computer are wrong or not updated.
In this case the best way to fix it is to go to your home directory (in your computer) check the hidden files and find the folder ".ssh" .Just delete this folder and re-open your bash terminal. Then run again your gcloud vm command.
Example:
you#your_computer:~$ gcloud beta compute ssh --zone "us-central1-a" "your_VM_name" --project "your_project_name"
You should this time instead of getting the error 255 code, the messages below:
WARNING: The private SSH key file for gcloud does not exist.
WARNING: The public SSH key file for gcloud does not exist.
WARNING: You do not have an SSH key for gcloud.
WARNING: SSH keygen will be executed to generate a key.
This tool needs to create the directory [/home/your_name/.ssh] before being able to
generate SSH keys.
Do you want to continue (Y/n)?
Type "Y" and gcloud will setup the new protocols by creating a brand new updated .ssh file.
After that you should be able to access your VM with your gcloud command without any problem.
That should solve the problem
Cheers
https://blackpearlmatrix.com
had the exact same symptoms - in my case the reason appeared to be the following. I was using root user + ssh key whereas root login is by default disabled in /etc/ssh/sshd_config (PermitRootLogin property).
I eventually had to delete my instance and make a new one with the same disk. See https://cloud.google.com/compute/docs/troubleshooting/troubleshooting-ssh#use_your_disk_on_a_new_instance for details.
For me, my other teammates were able to login into the machine, but not me. So I asked them to create a user of my name with sudo rights, logged into serial console and changed passwordAuthentication to yes followed by sudo service ssh restart (for few this could be sudo service sshd restart.)
Post this I was able to login with
ssh -o PreferredAuthentications=password username#publicIP -p 22
This trick worked fine for me.
Reinitializing the gcloud with "gcloud init" and generating new ssh keys resolved the problem for me.
I had same issue.
I had connected the serial control and had checked logs. and there was some error log like "there is no disk space". Then I had resized disk as written in this document.
Now I am able to connect to instance with ssh.
Try switching to a different Internet connection
So, I was getting the same error but in my case I was not able to log in to the instance at all.
(base) girish#girish:~$ gcloud beta compute ssh --zone "asia-east1-b" "fp-1" --project "fp-public"
ssh: connect to host 12.345.678.90 port 22: Resource temporarily unavailable
ERROR: (gcloud.beta.compute.ssh) [/usr/bin/ssh] exited with return code [255].
(base) girish#girish:~$ gcloud beta compute ssh --ssh-flag='-vvv' --zone "asia-east1-b" "fp-1" --project "fp-public"
OpenSSH_7.6p1 Ubuntu-4ubuntu0.3, OpenSSL 1.0.2n 7 Dec 2017
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: resolving "12.345.678.90" port 22
debug2: ssh_connect_direct: needpriv 0
debug1: Connecting to 12.345.678.90 [12.345.678.90] port 22.
[debug1: connect to address 12.345.678.90 port 22: Resource temporarily unavailable
ssh: connect to host 12.345.678.903 port 22: Resource temporarily unavailable
ERROR: (gcloud.beta.compute.ssh) [/usr/bin/ssh] exited with return code [255].
What worked for me:
I tried reinstalling lots of things and re-initializing various config and then landed on a thread which suggest to change the Internet network you are using and it worked!!
It's possible you have a rule that only allows whiltelisted IPs to ssh into a gcloud VM. So you may have forgotten to enable your work VPN or out of your work's office IP.
Try restarting your computer.
I got the same error and tried gcloud config ssh as mentioned previously to no avail. I then checked that the IDs and roles of serviceaccount and developer had 'editor' permissions, and that was fine. I started a new instance and logged out of all of my other google accounts and it still threw the error. Then, I restarted my computer and did not log back into my other google accounts. That fixed it.
When using IAP, GCP stores the key in instance metadata and then propagate
that to the ~/.ssh/authorized_keys file.
You might get the error OP talks about when you remove the key from the ~/.ssh/authorized_keys file and it's still in the instance metadata. Reason being:
GCP check that the user, key combo that you are using to ssh is already in the instance metadata.
It assumes that the exists in the ~/.ssh/authorized_keys file for that user and doesn't propagate the key.
As the key doesn't exist in ~/.ssh/authorized_keys file for whatever reason (you deleted it, someone else deleted it etc. etc.) - you get access denied.
If this is the case with you, then fix is simple: remove the instance metadata entry for that user, key combo (have attached an image for ref, just click X and remove your faulty key) and try ssh again
What worked for me was turning my firewall on. (On a Mac, ssh'ing into a gcp instance).
In another instance of the error, my connection worked fine when I was on ethernet, but not when I was on wifi. Switching back to ethernet allowed me to connect again.
In my case sorted out the issue after restarting the VM.
if you are able to access the VM previously and suddenly giving SSH issues, give it a try by restarting.
Permission wise check whether you have IAP-secured Tunnel User
gcloud compute ssh --zone "your_zone" "instance_name" --tunnel-through-iap --project "project_name"
If this not works check with the GCP built-in SSH client, and click open in browser window.
Hope this help !!!