I have a strange issue regarding my setup login into my hetzner cloud via SSH.
initial situation
I have made a fresh SSH Key, added that to a fresh Hetzner Cloud solution and made the initial login into the cloud. I was able to access the cloud via terminal with the command ssh root#MY_IP
the issue
When I retry to access my server with ssh root#MY_IP a few days after I've made the setup, I get the following error message: root#MY_IP: Permission denied (publickey).
I haven't made any changes in the meantime, didn't to anything with the ssh connection, didn't created new ssh key, nothing. I don't understand why it just denies my connection try since it was working fine before.
Probably your ssh-agent was configured in a different shell?
Try listing your stored keys with
ssh-add -l
If you don't see the one you created for this specific machine/cluster, try adding it again with:
ssh-add <absolute_path_to_your_private_key>
If your agent is not even running, start it in the background with:
eval "$(ssh-agent -s)"
Recently our web hoster (Domainfactory) changed the method to externally access our online mysql database. From simple ssh "port forwarding" to a "unix socks tunnel".
The ssh call looks like this (and it works!):
ssh -N -L 5001:/var/lib/mysql5/mysql5.sock ssh-user#ourdomain.tld
The problem: you have to enter the password every single time.
In the past I used BitVise SSH client to create a profile (which also stores the encrypted password). By simply double-clicking on the profile you'll be automatically logged in.
Unfortunately, neither the "BitVise SSH client" nor "Putty" (plink.exe) supports the "Unix socks tunnel" feature/extension, so I can't use these tools any more.
Does anyone have an idea how to realize an automated login (script, tool, whatever)?.
The employees who access the database must not know the SSH password in any case!
I got a solution. The trick is to generate a SSH Key pair (private and public) on client side (Windows machine) calling 'ssh-keygen'. Important: don't secure the ssh keys with a password (simply press [enter] if you're asked for a password, otherwise you'll be asked for the SSH-Key password every time you try to SSH). Two files will be generated inside 'c:\Users\your_user\.shh\': 'id_rsa' (private key) and 'id_rsa.pub ' (public key).
On server side create a '.shh' directory within your user's home directory. Inside the '.ssh' directory create a simple text file called 'authorized_keys'. Copy the contents of 'id_rsa.pub' into this file (unfortunately 'ssh-copy-id' isn't available yet for Windows. So you have to do the copy and paste stuff on your own.) Set permissions of 'authorized_keys' file to '600'.
Now you should be able to simply SSH into your server by calling 'ssh-user#ourdomain.tld' without entering a password. Create a batch file with your individual ssh-call and you're done.
Thanks to Scott Hanselman for his tutorial: https://www.hanselman.com/blog/how-to-use-windows-10s-builtin-openssh-to-automatically-ssh-into-a-remote-linux-machine
I have a Raspberry Pi set up as a download server at home. To access it from any Windows PC I download Putty and add its parent folder to the Path environment variable.
When accessing it via SSH using Putty GUI or CLI from any PC on my home network, it attempts to login with an SSH key, if it fails it prompts me for a password, and I can login.
I set up an ngrok account to be able to access the server from work (ngrok uses the same address for all users, but each free user gets a specific port, randomized on server reboot).
If i open up Putty's GUI and add the address (0.tcp.ngrok.io) and my port (13495) and click Open, I login normally, SSH key first, if that fails, password prompt, and I can login; as shown in the following picture: Putty GUI Login
However, if I login by command using "putty root#0.tcp.ngrok.io:13495" from the command line or making a Windows shortcut with that command as the target, it reacts as if password authentication is disabled and the only authentication method is via SSH key, which is not the case. (Failed Putty Logins)
I finally attempted to add the SSH key of my work desktop to the authorized_keys file, nothing changed. I can login by GUI using the key, but CLI login still fails.
I have tried resetting all of Putty's settings, redownloading, using Pageant instead of the Putty settings SSH>Auth, nothing works.
I have searched far and wide and delved into the creepy depths of the Internet and cannot find ANYONE with the same problem. If someone does find a post with the same question, well then that post must be running away from me.
Help me, please.
This is starting to get quite irritating.
Thanks in advance.
It's because PuTTY actually ignores everything after the colon (for a consistency with PuTTY psftp and pscp tools, where you specify a path after the colon).
So the putty root#0.tcp.ngrok.io:13495 works like putty root#0.tcp.ngrok.io. That means you actually connect to the default SSH 22 port, not to the 13495.
You have to use the -P switch to specify the non-default port:
putty root#0.tcp.ngrok.io -P 13495
After changing two passwords, root and the default user, suddenly we notice now that the "in browser" link on Google Compute Engine fails to connect via SSH.
Strangely, however, if we use the SSH command from the command line that Google provides (i.e. $ gcloud compute ssh VM-NAME --zone VM-ZONE) - SSH works.
It appears SSH is working - but the "in browser" SSH link no longer connects. What might have gone wrong and how do we fix this?
ADDENDUM:
Of note, a commenter below suggests it is not related to passwords but purely SSH keys - so it looks the answer to this question might rest around if there is a way to regenerate SSH keys on GCE instances. We are searching. If anyone knows code to regenerate SSH keys for GCE please post.
GCE VMs, by default, don't allow for SSH connections with clear-text password: it uses keys instead. You can specify approved keys during VM instantiation, or at a later time, but one that is always present is the key to the user account you used when creating the machine.
As long as you haven't modified /etc/ssh/sshd_config, this should continue to be the case. Either way, one more option you can use to connect via SSH to your instance is to run the following command:
$ gcloud compute ssh VM-NAME --zone VM-ZONE
while logged in with your authorized user account.
ADDENDUM - In lieu of regenerating previous keys, you can add additional, locally-generated SSH keys on both the project, as well as on the VM level. The first applies to all VMs and grants access to project owners and editors, while the second only applies to the VM in question. Both methods add the SSH entered to the Metadata server, from which the get uploaded to the VM prior to SSH connection to all / the VM.
You can do this from the Developers Console:
project-level SSH keys - go to your project -> Compute -> Compute Engine -> Metadata -> "SSH KEYS" (top of the screen) -> click on "Edit"
VM-level SSH keys - go to your project -> Compute -> Compute Engine -> VM instances -> click on the instance name -> "SSH keys" section (scroll down) -> click "Add SSH key"
We discovered the cause was a chown command we had executed on a directory for the primary user that Google creates on the Google Compute Engine instance.
By reversing that chown back to the Google created user, Google's in-browser SSH began working again.
We used chown on an entire user directory and also an ssh config file back to the Google created user using:
chown -R user_name_com /home/user_name_com
and also on this file
chown user_name_com /etc/ssh/ssh_config
where user_name_com was our gmail email address user.
I'm trying to connect to my Debian Google Compute Engine server through PuTTy (I've tried other alternatives too) but when I do I get the error "Disconnected: No supported authentication methods available (server sent: publickey)
The google server came without a username and password, only a url to automatically login to their own terminal.
I had PuTTY working and then one day got this error.
Solution: I had revised the folder path name containing my certificates (private keys), and this caused Pageant to lose track of the certificates and so was empty.
Once I re-installed the certificate into Pageant then Putty started working again.
Turn on Password Authentication
By default, you need to use keys to ssh into your google compute engine machine, but you can turn on password authentication if you do not need that level of security.
Tip: Use the Open in browser window SSH option from your cloud console to gain access to the machine. Then switch to the root user with sudo su - root to make the configuration changes below.
Edit the /etc/ssh/sshd_config file.
Change PasswordAuthentication and ChallengeResponseAuthentication to yes.
Restart ssh /etc/init.d/ssh restart.
Please follow this guide: https://gist.github.com/feczo/7282a6e00181fde4281b
with pictures.
In short:
Using Puttygen, click 'Generate' move the mouse around as instructed and wait
Enter your desired username
Enter your password
Save the private key
Copy the entire content of the 'Public key for pasting into OpenSSH authorized_keys file' window. Make sure to copy every single character from the beginning to the very end!
Go to the Create instances page in the Google Cloud Platform Console and in the advanced options link paste the contents of your public key.
Note the IP address of the instance once it is complete.
Open putty, from the left hand menu go to Connection / SSH / Auth and define the key file location which was saved.
From the left hand menu go to Connection / Data and define the same username
Enter the IP address of your instance
name the connection below saved Sessions as 'GCE' click on 'Save'
double click the 'GCE' entry you just created
accept the identy of the host
Now login with the password you specified earlier and run
sudo su - and you are all set.
You need to use an SSH key to login to your instance.
The GCE documentation explains the process here.
I had the same problem but got it working by changing enable-oslogin from TRUE to FALSE in google cloud.
from:
to:
I had the same issue and just figured it out !!
Assuming that you already went and created private/public key added your public key on the remote server ... type in username#remotehost.com and THEN go to Connection -> SSH -> Auth and click Browse to locate your private key. After you choose it will populate the input field. After that click OPEN ...
So the important thing here is the order... make sure you first enter parameters for the host and then locate your private key.
I got this error because I had forgotten to add my username behind the key in the GCE metadata section. For instance, you are meant to add an entry into the metadata section which looks like this:
sshKeys username:key
I forgot the username: part and thus when I tried to login with that username, I got the no supported auth methods error.
Or, to turn off the ssh key requirement entirely, check out my other answer.
Apparently running sudo chmod -R a+rw on your home folder causes this to happen as well.
This problem mainly caused by your connected username not have the access to the shell in GCE. So you use the following steps to solve this issue.
gcloud auth list
If you are using the correct login. please follow the below steps. otherwise use
gcloud auth revoke --all
gcloud auth login [your-iam-user]
and you get the token or it automatically detect the token.
gcloud compute --project "{projectid}" ssh --zone "{zone_name}" "{instance_name}" .
if you dont know this above line click to compute engine-> ssh dropdown arrow-> view google command-> copy that code and use it
Now it update your metadata and it is available in your computer's folder Users->username
~/.ssh/google_compute_engine.ppk
~/.ssh/google_compute_engine.pub
Then you create a new ppk file using puttygen and you give the username, which you want like my_work_space. Then
save the publickey and privatekey in a folder.
Next step: Copy the public key data from puttygen and create new ssh key in gcloud metadata
cloud console ->compute engine->metadata->ssh key->add new item->paste the key and save it
and now return your shell commandline tool then enter
sudo chown -R my_work_space /home/my_work_space
now you connect this private key using sftp to anywhere. and it opens the files without showing the permission errors
:) happy hours.
If the private key has been generated with ssh-keygen in Linux it needs to be converted with puttygen because Putty does not support openssh keys.
Start puttygen, and click on Conversions - Import key, then click Browse and select the private key generated with openssh, then click on Save private key.
Use your new key to connect.
I faced the same issue and solve after several trial and error.
In the /etc/ssh/ssh_config, set
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
PasswordAuthentication no
AuthenticationMethods publickey
then, open putty.
In the "Saved Sessions", enter the server IP, go through the path Connection->SSH->Auth->Browse on the left panel to search your private key and open it.
Last but not least, go back to Session of putty on the left panel and you can see the server IP address is still in the field, "Saved Sessions", then click "Save", which is the critical step.
It will let the user login without password any more.
Have fun,
Download "PuttyGEN" get publickey and privatekey
use gcloud SSH edit and paste your publickey located in /home/USER/.ssh/authorized_keys
sudo vim ~/.ssh/authorized_keys
Tap the i key to paste publicKEY.
To save, tap Esc, :, w, q, Enter.
Edit the /etc/ssh/sshd_config file.
sudo vim /etc/ssh/sshd_config
Change
PasswordAuthentication no
[...]
ChallengeResponseAuthentication to no.
[...]
UsePAM no
[...]
Restart ssh
/etc/init.d/ssh restart.
the rest config your putty as tutorial
NB:choose the pageant add keys and start session would be better
Electricity went down and got this error. Solution was to double click your .ppk (Putty Private Key) and enter your password.
PasswordAuthentication and ChallengeResponseAuthentication default set to NO in rhel7.
Change them to NO and restart sshd.
Similar problem - same error message. I got the same message when trying to clone something from bitbucket with ssh. The problem was in my ssh configuration configured in the mercurial.ini: I used the wrong bitbucket username. After I corrected the user name things worked.
For me these was my problem, solution from https://unix.stackexchange.com/questions/282908/server-refused-public-key-signature-despite-accepting-key-putty
"Looking at the log /var/log/secure showed that it was just downright refused. I'm somewhat new to centos since I'm mainly a debian kind of guy, so I was unaware of /var/log/secure
After checking this and doing a bit of searching, it turns out PermitRootLogin no needs to be PermitRootLogin without-password if you want to specifically use just keys for root login. That did the trick. Thanks everyone for contributing."
I had the same error message and discovered that my mistake was in the username I used with putty. Apparently GCE SSH Keys listing would change your username characters in some of the listing. In my case, the underscore was changed to period. i.e: my_username becomes my.username
I inadvertently copied the wrong username from the listing and got the same error message.
I know this is an old question, but I had the same problem and solved it thanks to this answer.
I use Putty regularly and have never had any problems. I use and have always used public key authentication. Today I could not connect again to my server, without changing any settings.
Then I saw the answer and remembered that I inadvertently ran chmod 777 . in my user's home directory. I connected from somewhere else and simply ran chmod 755 ~. Everything was back to normal instantly, I didn't even have to restart sshd.
I hope I saved some time from someone