Friends good night.
I have a server on Google Compute Engine, which I do not have access to via ssh and the old administrator did not leave access to it.
Is there any possibility to access this server either through SDK, GCP Console, etc.?
Thank you very much in advance.
If you or your team have an IAM account on the project with sufficient roles/permissions (Owner, ComputeAdmin), you can try the following:
Check this troubleshooting documentation in order to identify and solve your issue
Try to access the VM through the SerialPort.
I had mistakenly locked myself via these files /etc/hosts.allow and /etc/hosts.deny. It took me a day to get back access to the server and I hope below will help someone locked out of a GCP vm. It simply creates a script that runs when your VM is booting up. You can then have all commands to fix your issue run without direct access to the server. Below is how you can for example reset root password.
I am assuming that you have access to GCP console via browser, do below:-
Shutdown the server
Click on edit and scroll down to Custom metadata. Add a new item with key as startup-script and the value as below. Replace yournewpassword with the password you want to set for the root user:
#!/bin/sh
echo "yournewpassword:root" | chpasswd
Reboot your server and use your new password set above to ssh to your vm
Remove the meta and save your VM. You can reboot again.
Related
We have upgraded Debian distribution in Google Cloud instance and it seems GCloud cannot manage the users and their SSH keys in the instance anymore.
I have installed following tools:
google-cloud-packages-archive-keyring/now 1.2-499050965 all
google-cloud-sdk/cloud-sdk-bullseye,now 412.0.0-0 all
google-compute-engine-oslogin/google-compute-engine-bullseye-stable,now 1:20220714.00-g1+deb11 amd64
google-compute-engine/google-compute-engine-bullseye-stable,now 1:20220211.00-g1 all
google-guest-agent/google-compute-engine-bullseye-stable,now 1:20221109.00-g1 amd64
I cannot connect through the UI. It gets stuck on "Transfering SSH keys to the instance". The "troubleshooting" says that everything is fine.
When trying to connect via gcloud compute ssh it dies with
permission denied (publickey)
I still have access to the instance with some other user, but no new users are created and no SSH keys transferred.
What else am I missing?
EDIT:
Have you added the SSH key to Project metadata or Instance metadata? If its instance metadata, is project level ssh key blocked?
I haven't added any metadata.
Does your user account has necessary permission in the project to SSH to the instance (e.g Owner, Editor or Compute Instance Admin IAM role)?
Yes this worked correctly until the debian upgrade to bookworm. I could see all the google-cloud related packages were remove and I had to install them.
Are you able to SSH to the instance using ssh client e.g Putty?If yes, you need to make sure Google account manager daemon is running on the instance.
I can nicely SSH with accounts which were active on the machine BEFORE the Debian upgrade. These account already have .ssh directory correctly set up and working. New google users cannot login.
Try gcloud beta compute ssh --zone ZONE INSTANCE_NAME --project PROJECT
This works only for users active before the Debian upgrade.
If yes, you need to make sure Google account manager daemon is running on the instance.
I installed the google-compute-engine-oslogin package which was missing, but it seems it has no effect and new users still cannot login.
EDIT2:
When connecting to serial console, it gets stuck on: csearch-dev google_guest_agent[2839775]: ERROR non_windows_accounts.go:158 Error updating SSH keys for gke-495d6b605cf336a7b160: mkdir /home/gke-495d6b605cf336a7b160/.ssh: no such file or directory. - the same issue, SSH keys are never transferred into the instance.
There are a few things you can do troubleshoot the Permission denied (publickey) error message :
To start, you must ensure that you have properly authenticated yourself with gcloud using an IAM user with the compute instance admin role. You can do that by running gcloud auth login [USER] then try gcloud compute ssh again.
You can also verify that the Linux Guest Environment scripts are properly installed and running. Please refer to this page for information about validating, updating, or manually installing the guest environment.
Another possibility is that the private key was lost or that we have a mismatched keypair. To force gcloud to generate a new SSH keypair, you must first move ~/.ssh/google_compute_engine and ~/.ssh/google_compute_engine.pub if present, for example:
mv ~/.ssh/google_compute_engine.pub ~/.ssh/google_compute_engine.pub.old
mv ~/.ssh/google_compute_engine ~/.ssh/google_compute_engine.old
Once that is done, you may then try gcloud compute ssh [INSTANCE-NAME] again, a new keypair should be created and a public key will be added to the SSH keys metadata.
Refer to Sunny-j and Answer to review the serial-port logs of the affected instance for possible clues on the issue. Also refer to Resolving getting locked out of a Compute Engine for more information.
Edit1:
Refer to this similar SO and Troubleshooting using the serial console which helps to resolve your error.
EDIT2:
Maybe you have git-all installed. Cloud-init and virtually every step of the booting process are disrupted as a result of this, as the older SysV init system takes its place. You are unable to SSH into your instance as a result of this.
Check out these potential solutions to the above problem:
1.Try using git instead of git-all.
2.If git-all is necessary, use apt install --no-install-recommends -y git-all to prevent the installation of recommendations.
Finally : If you were previously able to SSH into the instance with a particular SSH key for new users, either the SSH daemon was not running or was otherwise broken, or you somehow removed that SSH key. It would appear that you damaged this machine during the upgrade.
Why is this particular VM instance required? Does it contain significant data? If this is the case, you can turn it off, mount its disk with a new VM instance, and copy that data off.( I'd recommend build another machine running these services from latest snapshot or scratch and start using that instead).
You should probably move to a new machine if it runs a service: There is no way to tell what still works and what doesn't, even if you are able to access the instance.
My AWS account was suspended when my credit card expired and I updated the card in an hour. The access to my account was restored. But when I started my EC2 server, and tried to connect with SSH it gave an error saying Key not recognised.
I tried to follow the steps provided by AWS support to attach my volume to another server, reset the SSH permissions and re-attach volume to my original server. But on attaching volume to new server and mounting it, I found that the user directory (/home/ubuntu) was missing along with the /var/www directory from apache 2. So I have been unable to reset the SSH access.
Can anyone help with this?
I'm trying to execute a Script on a Google VM through Terraform.
First I tried it via Google Startup Scripts. But since the metadata is visible in the Google Console (startup scripts count as metadata) and that would mean that anybody with read access can see that script which is not acceptable.
So i tried to get the script from a Storage Account. But for that i need to attach a service account to the VM so the VM has the rights to access the Storage Account. Now people that have access to the VM also have access to my script as long as the service account is attached to the VM. In order to "detach" the service account i would have to stop the VM. Also if i don't want to permanently keep the attachment of the service account i would have to attach the service account via a script which requires another stop and start of the VM. This is probably not possible and also really ugly.
I don't understand how the remote-exec ressource works on GCP VMs. Because i have to specify a user and a userpassword to connect to the VM and then execute the script. But the windows password needs to be set manually via the google console, so i can't specify those things at this point in time.
So does anybody know how I can execute a Script where not anybody has access to my script via Terraform?
Greetings :) and Thanks in advance
I ended up just running a gcloud script in which i removed the Metadata from the VM after the Terraform apply was finished. In my Gitlab pipeline i just called the script in the "after_script"-section. Unfortunately the credentials are visible for approximately 3min.
I am stuck on step 4 with using SSH to enable https
https://docs.bitnami.com/aws/how-to/configure-elb-ssl-aws/
I open putty to make an SSH
I type /opt/bitnami/apps/ghost/conf/httpd-prefix.conf
the SSH client tells me -bash:/opt/bitnami/apps/ghost/conf/httpd-prefix.conf: permission denied
Can anyone provide a more detailed instruction into how to get my SSL certificate to work with Ghost by bitnami on AWS
Thank you
There's two things you need to do. First, you have to launch an editor to modify the httpd-prefix.conf file. Nano is easy to use and should be installed on your instance already. Issue a command like nano /opt/bitnami/apps/ghost/conf/httpd-prefix.conf, make your edits in the nano editor, then save the file.
The second thing is to make sure that the account you are using has permissions to perform those tasks. You'll need root-level permissions. You can use the sudo command to run things as root. If you get a permission denied error when launching nano, try sudo nano /opt/bitnami/apps/ghost/conf/httpd-prefix.conf and enter the necessary password to execute the nano command with root privileges.
Keep in mind that the best practice for AWS accounts is to only use the root account to create your first IAM user, so that your root account credentials stay safe, and that hackers can't gain full control of your account should a compromise happen.
Instead try this for setting up an SSL cert https://docs.bitnami.com/aws/how-to/generate-install-lets-encrypt-ssl/
A little backstory, I have an AWS instance made with Bitnami that I set up on my Windows Machine back home. I am currently out of the country and have no way to access that machine at the moment. One month later, I visit the website getting a 500 error and (only my Macbook on me). I've tried to SSH into it from my Macbook and no luck. I get the error:
Username is not in the sudoers file. This incident will be reported.
I've also tried another way to SSH into my aws but then I just get
Permission denied (publickey).
I do have the public/private keys I made with me so I am not sure if I had to set up some additional permissions to SSH from a different computer. On top of that, I got an email stating that someone attempted to access remote hosts on the internet without authorization. If I visit my Public IP address of my instance, it goes straight to a spam page.
At this point, I am not sure if I am just missing something in my steps or have missed a step. If someone can help me, I would really appreciate it.
Is there some way to get my instance back up and running? If not, is there some way I can back up the wordpress files on that instance that's down and use it to create another one on my Macbook currently? Please let me know.
If you have the private key that your AWS instance has been installed with, place the key in ~/.ssh .
Then, run the following command to set the permissions of the key to read and write only to your user (it's a mandatory step):
chmod 600 ~/.ssh/keyname
Then, run the following command to connect to your instance:
ssh -i ~/.ssh/keyname user#instance_ip
And it should connect successfully.
If you're not sure which user to connect to and you have access to AWS EC2 Console, then look for that server, right-click it and choose "Connect" and it will usually show the correct user to use when connecting to it by SSH.