Putty: Getting Server refused our key Error - ssh

I created key pair using puttygen.exe (client is windows 8). On server (Ubuntu 12.04.3 LTS), I have put my public key in ~/.ssh/authorized_keys. The public key is this:
ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAQEAopfM6RHOgnuc4Aftn3t4k5UIAT3StCAbn/vg/IMbphbXadshC+79sIlRq3P4zGzMjFTP4hKnzu6ehLV5lmj/qorq3SKT+bPO5Qrac3VbIlrGvuBFDDjP82I2Hwg3HzlsFTstqk++KToapaTYZ7jENEYyPl2wnzITJnt//+4U1o6juoXTKgdNE02hHnRZyHOV/bnkZyJJCEwJv5U0eXSThQnhmXtUxGT8U0HQNFiXfqIIVllhWiCnyrhhIaKz/CIJNAd2VmzyJzQtJtTQX8aWSNVrZju6Sv2/RncTNvsACdNgjjh/FH8PQXaep00jlJ3MOdsC8vz6VSPFbh6iKy1oLQ== rsa-key-20131231
So it's correct (one line, no comments, starts with ssh-rsa, etc.)
.ssh dir permission level is 700, authorized_keys file permission is 600. Both directory and file owned by the actual user that I try to log in.
When I try connecting I'm getting 'server refused our key' and server asks for password. That's all. Nothing is logged to /var/log/auth.log when attempting to log in with the key.
I've looked everywhere and all articles and tips mention setting chmod 600 and 700 for the file/directory and formatting the key correctly. I've done all this still getting 'refused our key' error and I'm out of ideas.

OK, there was a small typo in my key. Apparently when pasting to file the first letter was cut off and it started with sh-rsa instead of ssh-rsa.
nrathathaus - your answer was very helpful, thanks a lot, this answer is credited to you :) I did like you said and set this in sshd_conf:
LogLevel DEBUG3
By looking at the logs I realized that sshd reads the key correctly but rejects it because of the incorrect identifier.

Adding a few thoughts as other answers helped, but were not exact fit.
First of all, as mentioned in accepted answer, edit
/etc/ssh/sshd_config
and set log level:
LogLevel DEBUG3
Then restart sshd on the server to have it use the changed log level, e.g.:
sudo service ssh restart
Then try to authenticate, and when it fails, look for log file:
/var/log/secure
It will have errors you are looking for.

In my case I had to change the permissions of /home/user from 0755 to 0700 as well.

In my case, is a permission problem.
I changed the log level to DEBUG3, and in /var/log/secure I see this line:
Authentication refused: bad ownership or modes for directory
Googled and I found this post:
https://www.daveperrett.com/articles/2010/09/14/ssh-authentication-refused/
chmod g-w /home/$USER
chmod 700 /home/$USER/.ssh
chmod 600 /home/$USER/.ssh/authorized_keys
Basically, it tells me to:
get rid of group w permission of your user home dir
change permission to 700 of the .ssh dir
change permission to 600 of the authorized_keys file.
And that works.
Another thing is that even I enabled root login, I cannot get root to work. Better use another user.

Running Windows 8.1 I ran into the server refused our key problem.
Following the guide: https://winscp.net/eng/docs/guide_windows_openssh_server
It was easy to make a connection using the Windows login username and password. However, authenticating with the username in combination with a private key, the response was server refused our key.
Getting it to work with a public key came down to the permissions on the file:
C:\ProgramData\ssh\administrators_authorized_keys
This is a helpful page: https://github.com/PowerShell/Win32-OpenSSH/wiki/Troubleshooting-Steps
Stop the two OpenSSH services, then open a command prompt with admin permissions. Then run:
C:\OpenSSH-Win32>c:\OpenSSH-Win32\sshd.exe -ddd
Note: specify the full path to the exe otherwise sshd complains.
This creates a one-time use connection listener. The -ddd is verbose level 3.
After making a connection, scanning the logs revealed:
debug1: trying public key file __PROGRAMDATA__/ssh/administrators_authorized_keys
debug3: Failed to open file:C:/ProgramData/ssh/administrators_authorized_keys error:2
debug1: Could not open authorized keys '__PROGRAMDATA__/ssh/administrators_authorized_keys':
No such file or directory
Had to create the file: C:\ProgramData\ssh\administrators_authorized_keys
And copy the public key text into it, e.g: ssh-rsa AAAA................MmpfXUCj rsa-key-20190505
And then save the file. I saved the file as UTF-8 with the BOM. Didn't test ANSI.
Then running the one-time command line again, in the logs showed:
debug1: trying public key file __PROGRAMDATA__/ssh/administrators_authorized_keys
debug3: Bad permissions. Try removing permissions for user: S-1-5-11 on file C:/ProgramData/ssh/administrators_authorized_keys.
Authentication refused.
S-1-5-11 is the name given to the System.
To fix the Bad permissions, right click on the administrators_authorized_keys file, goto the Security Tab , click the Advanced button and remove inherited permissions.
Then delete all Group or user names: except for the Windows login username, e.g: YourMachineName\username
The permissions for that username should be Read Allow, Write Deny everything else is unchecked. The owner of the file should also be YourMachineName\username
This fixed the problem.
Other Useful links:
Download OpenSSH-Win32.zip from: https://github.com/PowerShell/Win32-OpenSSH/releases
C# example of how to use the WinSCPnet.dll to make a connection to the OpenSSH server: https://winscp.net/eng/docs/library#csharp
Here is the code snippet to make a connection using the WinSCPnet.dll:
static void WinSCPTest() {
SessionOptions ops = new SessionOptions {
Protocol = Protocol.Sftp,
PortNumber = 22,
HostName = "192.168.1.188",
UserName = "user123",
//Password = "Password1",
SshHostKeyFingerprint = #"ssh-rsa 2048 qu0f........................ddowUUXA="
};
ops.SshPrivateKeyPath = #"C:\temp\rsa-key-20190505.ppk";
using (Session session = new Session()) {
session.Open(ops);
MessageBox.Show("success");
}
}
Replace SshHostKeyFingerprint and SshPrivateKeyPath with your own values.
Edit: added screenshot of administrators_authorized_keys file permissions:
When OpenSSH SSH Server is running as a Service, then only System should have permission. However, if running sshd.exe from the command prompt, then the current user should be the only one listed (read allow, write deny).

The simple solution i found was to move the authorized_keys file away from the hidden .ssh directory and put it in the system ssh directory:
/etc/ssh/keys/authorized_keys
As soon as I did this it worked with no problems.

having same issue in windows server 2008 r2 and explored a lot to solve, finally did that by following:
open C:\Program Files (x86)\OpenSSH\etc\sshd_config with textpad or any other text editor
remove comment from following lines, after removing they should look like following:
RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
save it and try to login with private key now.
have fun.

I'm adding this answer to help anyone, like me, who spent hours scouring the internet without success.
YOUR HOME FOLDER MIGHT BE ENCRYPTED.
Or for that matter any folder in which your "authorized_keys" file is nested. Man, that would have saved me a lot of time. To check, go perform
ls -A
on the directory whose encryption status you would like to determine. If the folder contains a folder named ".encryptfs" the answer is, yes, that folder is encrypted. This will impede your ability to access the "authorized_keys" file containing the public ssh key needed for verification.
To fix this, place the "authorized_key" file in a directory tree that contains no encryption.

After adding key, login as ec2-user if you are using an Amazon Linux machine
If its ubuntu machine then use ubuntu

Thanks to nrathaus and /var/log/auth.log investigation on debug level comes the following.
Another reason is that your home directory may have permissions different than 755.

In my case it was caused by (/etc/ssh/sshd_config):
PermitRootLogin no
Changed to yes, restarted the service and got in normally.

I have solved this problem,puttygen is a third-party software, ssh key which generated by it didn't be used directly, so you must make some changes.
For example, it look like this
---- BEGIN SSH2 PUBLIC KEY ----
Comment: "rsa-key-20170502"
AAAAB3NzaC1yc2EAAAABJQAAAQEAr4Ffd3LD1pa7KVSBDU+lq0M7vNvLp6TewkP7
*******C4eq1cdJACBPyjqUCoz00r+LqkGA6sIFGooeVuUXTOxbYULuNQ==
---- END SSH2 PUBLIC KEY ----
I omit some of the alphabets in the middle, replaced by *, if not, StackOverflow told me that the code format is wrong, do not let me post。
this is my ssh key generated by puttygen, you must change to this
ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAQEAr4Ffd3LD1pa7KVSBDU+lq0M7vNvLp6TewkP7wfvKGWWR7wxA8GEXJsM01FQw5hYWbNF0CDI7nCMXDUEDOzO1xKtNoaidlLA0qGl67bHaF5t+0mE+dZBGqK7jG9L8/KU/b66/tuZnqFqBjLkT+lS8MDo1okJOScuLSilk9oT5ZiqxsD24sdEcUE62S8Qwu7roVEAWU3hHNpnMK+1szlPBCVpbjcQTdiv1MjsOHJXY2PWx6DAIBii+/N+IdGzoFdhq+Yo/RGWdr1Zw/LSwqKDq1SmrpToW9uWVdAxeC4eq1cdJACBPyjqUCoz00r+LqkGA6sIFGooeVuUXTOxbYULuNQ== yourname#hostname
In my case, I have deleted some comments, such as
---- BEGIN SSH2 PUBLIC KEY ----
Comment: "rsa-key-20170502"
---- END SSH2 PUBLIC KEY ----
and add ssh-rsa at the beginning,
add yourname#hostname at the last.
note: not delete== in the last and you must change "yourname" and "hostname" for you, In my case, is uaskh#mycomputer,yourname is that you want to log in your vps .when all these things have done,you could to upload public-key to uaskh's home~/.ssh/authorized_keys by cat public-key >> ~/.ssh/authorized_keys then sudo chmod 700 ~/.ssh sudo chmod 600 ~/.ssh/authorized_keys then you must to modify /etc/ssh/sshd_config, RSAAuthentication yes PubkeyAuthentication yes AuthorizedKeysFile .ssh/authorized_keys my operating system is CentOS 7,This is my first time to anwser question,I will try my efforts to do ,Thank you!

I encountered this problem today and my issue was that when copying the public key from file, new line characters are included as well. You can use ":set list" in vim to see all the hidden new lines and make sure to delete all the new lines except for the last one. Also, my key was missing "ssh-rsa " in the beginning. Make sure you have that as well.

The equivilent of an SSH command:
ssh -i <path_to_pem_file> ec2-user#calendar.com
In Windows, first use PuTTYGen to convert the pem file to a ppk file.
Open PuTTYGen
File/Load the private pem key (or an OpenSSH key)
In the Open FileDialog, use the drop down to select "All files" (it only shows ppk file formats not pem, also OpenSSH key files that can be converted like pem files don't have a file extension)
File/Save private key (*.ppk)
The same settings in Putty as the SSH command:
Open Putty
Session/Hostname: calendar.com
Connection/Data/Auto-login username: ec2-user
Connection/SSH/Auth/PrivateKeyFile Path: the file path to the PPK file

OpenSSH disable the ssh-rsa signature scheme by default in the next
release.
In the SSH protocol, the "ssh-rsa" signature scheme uses the SHA-1
hash algorithm in conjunction with the RSA public key algorithm. It is
now possible1 to perform chosen-prefix attacks against the SHA-1
algorithm for less than USD$50K.
Source
So, update the key.

For those receiving this error from Windows Server, I received this same error and it was a user account issue. With many organizations, group policy for Administrators may not allow setting up SSH Server and connections. With that type of setup, this must be done from Local Admin account. Might be worth looking into if you have confirmed there are not any typos in the public key.

In my case, I had to disable SELinux on Centos6.6 to get it working :)
Edit /etc/selinux/config and set the following and then reboot the host.
selinux=disabled
BTW...forgot to mention that I had to set the LogLevel=DEBUG3 to identify the issue.

I had the same error on solaris but found in /var/adm/splunk-auth.log the following:
sshd: [auth.debug] debug1: PAM conv function returns PAM_SUCCESS
sshd: [auth.notice] Excessive (3) login failures for weblogic: locking account.
sshd: [auth.debug] ldap pam_sm_authenticate(sshd-kbdint weblogic), flags = 1
sshd: [auth.info] Keyboard-interactive (PAM) userauth failed[9] while authenticating: Authentication failed
In /etc/shadow the account was locked:
weblogic:*LK*UP:16447::::::3
Removed the "*LK*" part:
weblogic:UP:16447::::::3
and I could use ssh with authorized_keys as usual.

I have this issue where sshd only reads from authorized_keys2.
Copying or renaming the file fixed the problem for me.
cd ~/.ssh
sudo cat authorized_keys >> authorized_keys2
P.S. I'm using Putty from Windows and used PuTTyKeygen for key pair generation.

I was facing similar issue when trying to logon through Mobaxterm. The private key was generated through puttygen. Regenerating the key helped in my case.

As my experience, I suggest you should generate keys from putty, should not generate from linux side. Because the key will be old PEM format. Anyway, just my suggestion. I did as steps below and worked fine with me and with my team.
Generate a key pair with PuTTYGen.exe on your local (type: RSA, length: 2048 bits).
Save private/public key as "id_rsa.ppk/id_rsa.pub" files on your local.
Create "authorized_keys" file on your local, then enter the public key in "id_rsa.pub" to "authorized_keys".
Remember content has to begin with "ssh-rsa" and one line only.
Use WinScp (or putty command) to copy "authorized_keys & id_rsa.pub" from your local to your linux-user-home "/home/$USER/.ssh/".
Run these commands:
chmod 700 .ssh
chmod 600 .ssh/authorized_keys
chown $USER:$USER .ssh -R
Test your connect setting by load the private key "id_rsa.ppk" in the PuTTY.exe profile, then click open (put your passphrase if have).

check your key, this should be a rsa (id_rsa.pub) key today and no longer a dss (id_dsa.pub) key, use puttygen 0.70 and choose RSA on type of key to generate, replace the public key on host ~/.ssh/authorized_keys

Oh my God I spent days trying to fix this. So here is what worked for me. I went back to the root fold like this:
cd /root/
mkdir .ssh
cd .ssh
chmod 700 .ssh
nano -w authorized_keys
service ssh restart
So I used root to logging via Putty and it worked. so try to do the same with the user you want to use in putty.

In the case of mine it was a wrong user:group attribution. I solved setting the right user and group:
sudo chown [user]:[group] -R /home/[user]

This helps to me:
# /etc/ssh/sshd_config
PubkeyAuthentication yes
PubkeyAcceptedKeyTypes=+ssh-rsa
# temporarily added:
LogLevel DEBUG3
# gentoo
# tail -n 50 /var/log/messages
and restart sshd
/etc/init.d/sshd restart

If you run Putty in a version before 0.75, then updating Putty should solve the problem.
Newer version of openSSH (as in Ubuntu 22.04) have deprecated the use of the SHA1 hashing algorithm during the login, but Putty used SHA1 until version 0.74.
If sshd log file on the server shows
$ sudo grep 'sshd' /var/log/auth.log
sshd[113232]: userauth_pubkey: key type ssh-rsa not in PubkeyAcceptedAlgorithms [preauth]
then this in fact causing the error, and should be gone after Putty has been updated.

I'm using a PUTTYgen file with psftp, and I encountered this problem on my Windows Server when we were required to create new keys for a client. The private_key_name.ppk file and the open_ssh.txt file must be in the same directory for the connection to work.

In my case home on nfs was 777, needed to be 750. That fixed the issue.

When using Cpanel you can check if the key is authorized in
SSH Access >> Public keys >> Manage >> Authorize or Deauthorize.

if you get this error in /var/log/secure
error: key_read: key_from_blob AA
AAB3NzaC1yc2EAAAABJQAAAQEAoo3PFwX04NFG+rKz93l7em1BsUBzjHPMsswD
it means your key is having space, if you generated key through puttgen when you view .ppk file, it will look like this:
AAAAB3NzaC1yc2EAAAABJQAAAQEAoo3PFwX04NFG+rKz93l7em1BsUBzjHPMsswD
al74MLaJyhQD0pE23NS1izahbo1sJGnSJu2VJ//zxidSsba6xa6OvmeiKTwCz0E5
GMefdGVdpdbTlv99qjBl1+Nw1tDnHIC0+v9XmeZERQfCds9Kp1UivfReoYImntBC
gLtNyqRYrSu8csJCt7E1oY8QK6WP1vfYgAQ2taGyS9+g7FHyyf5VY2vH3oWzzbqz
xjsSLAv3zEQSm1LzSw9Pvc8iwasFyUMBOPj31CKQYTXyX8KpJTr0Zb7oqMauBE5L
VwxZhlcJHbj0FsMbF/+GRjvgexymCi3bHmwGQ6FEADNd0RkhdQ==
and when you try to paste it you will get an error in reading key, so try to edit key and make it one line and try it
this should look like something
ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAQEAoo3PFwX04NFG+rKz93l7em1BsUBzjHPMsswDal74MLaJyhQD0pE23NS1izahbo1sJGnSJu2VJ//zxidSsba6xa6OvmeiKTwCz0E5GMefdGVdpdbTlv99qjBl1+Nw1tDnHIC0+v9XmeZERQfCds9Kp1UivfReoYImntBCgLtNyqRYrSu8csJCt7E1oY8QK6WP1vfYgAQ2taGyS9+g7FHyyf5VY2vH3oWzzbqzxjsSLAv3zEQSm1LzSw9Pvc8iwasFyUMBOPj31CKQYTXyX8KpJTr0Zb7oqMauBE5LVwxZhlcJHbj0FsMbF/+GRjvgexymCi3bHmwGQ6FEADNd0RkhdQ== username#domainname

Related

VScode remote connection error: The process tried to write to a nonexistent pipe

I use vscode with remote-ssh to connect my server, after configuring, I want to connect my host, but it failed, the dialog box display:"could not establish connection to XX, The process tried to write to a nonexistent pipe."
output:
[16:45:20.916] Log Level: 3
[16:45:20.936] remote-ssh#0.49.0
[16:45:20.936] win32 x64
[16:45:20.944] SSH Resolver called for "ssh-remote+aliyun", attempt 1
[16:45:20.945] SSH Resolver called for host: aliyun
[16:45:20.945] Setting up SSH remote "aliyun"
[16:45:21.012] Using commit id "c47d83b293181d9be64f27ff093689e8e7aed054" and quality "stable" for server
[16:45:21.014] Install and start server if needed
[16:45:21.019] Checking ssh with "ssh -V"
[16:45:21.144] > OpenSSH_for_Windows_7.7p1, LibreSSL 2.6.5
[16:45:21.214] Running script with connection command: ssh -T -D 5023 aliyun bash
[16:45:21.221] Terminal shell path: C:\WINDOWS\System32\cmd.exe
[16:45:21.504] >
>
>
> ]0;C:\WINDOWS\System32\cmd.exe
[16:45:21.505] Got some output, clearing connection timeout
[16:45:21.577] >
>
>
>
[16:45:21.592] > Bad owner or permissions on C:\\Users\\DY/.ssh/config
>
[16:45:21.689] > The process tried to write to a nonexistent pipe.
>
[16:45:22.091] "install" terminal command done
[16:45:22.092] Install terminal quit with output: The process tried to write to a nonexistent pipe.
[16:45:22.093] Received install output: The process tried to write to a nonexistent pipe.
[16:45:22.096] Resolver error: The process tried to write to a nonexistent pipe
[16:45:22.107] ------
Add the absolute file path to a custom SSH config file(C:\Users\{USERNAME}\.ssh\config), and my problem is solved.
If you format/re-install Server OS, but use same IP as before,
you may encounter fingerprint mismatched.
You may need to delete old fingerprint in this file:
C:\Users\xxx.ssh\known_host
and old IP in the file:
C:\Users\xxx.ssh\config
Then try to add host again.
What worked for me:
delete ssh config folder both in C:\Program Data\ssh and C:\<user>\.ssh
In VS Code, press F1, choose Remote-SSH: Connect to Host...
Do NOT enter anything in the prompt, but instead choose + Add New SSH Host..
Enter the full ssh command, including the key (in case of Windows,
you may want to enclose the path with double quote mark) ssh -i "C:\path\to\key" user#host. (you need to make sure the key has a limited permission. Remove all inherited permissions, and only give a full control to the owner.)
You will be asked to choose a folder in which a new config file will be created. Choose any of the two options.
There will a prompt notifying that the new config file
has been created. Click connect
At least three things may be happening:
Option 1
The location of your config file is not the absolute location, meaning you are probably using the location of the folder where the config file is.
If that is the case, access your User Settings in VSCode. Scroll to the Extensions>Remote - SSH. And add config at the end of the absolute file path of your custom SSH config file. In Windows, it can be
C:\Users\user\.ssh\config
See image below
Option 2
Authentication problems.
If that is the case, one of the things that may solve is generating new SSH keys.
In Windows, for that, I recommend using MobaXterm.
In MobaXterm, open a new terminal and write
ssh-keygen -b 4096 -t rsa
Then, in the config file, make sure that the IdentityFile points to the location of the key. MobaXterm's home directory, usually, is C:\Users\user\Documents\MobaXterm. If it makes it easy, one can copy/move the keys to C:\Users\user\.ssh and then just add, in the config file, IdentityFile ~/.ssh/KEY_rsa (where KEY_rsa is the name of the [public] key).
Note that if you use PuTTY to generate the keys, on the server OpenSSH authorized_keys file, one doesn't want the public key that one saves, but the one that appears on top (see image bellow):
Option 3
Your config file may be wrong.
The config file tends to look as follows. Double check if the fields have the information needed for the connection to be established.
Host Test # This is the name we want to give the host
User user # This is the username
Hostname blabla.com # This is the hostname
PreferredAuthentications publickey
IdentityFile ~/.ssh/KEY_rsa # This is the location of the key
IdentitiesOnly yes
Port 50 # This varies
What worked for me was to delete all of the contents of folder: C:\Users\MYNAME.ssh That meant to delete both the config file and known-hosts. The config was probably the most important one to delete.
The solution in my case was editing the json settings file for VSC as shown here: https://code.visualstudio.com/docs/remote/troubleshooting#_troubleshooting-hanging-or-failing-connections
In VSC go to File, Preferences, Setting and click on the upper right hand icon (Open Settings, JSON). Add these two lines to settings.json and retry connecting:
"remote.SSH.showLoginTerminal": true,
"remote.SSH.useLocalServer": false
In my case I had another setup:
Git bash in Windows was configured and I am using the ssh.exe provided by this tool
In the "Remote SSH" extension in VSCode, I specified the full path of this ssh.exe
I am using multiple servers (with ProxyJump)
The error message is the same as the OP but in the logs it was written that the ssh config file was not found, where all the folder names was concatenated (because it did not recognize the windows path separator)
Problem: the ssh.exe is using a different path convention thant VSCode. ssh.exe is using the "/c/Users/..." pattern and VSCode is using the "C:\Users..." pattern.
Solution:
Make sure the SSH config is at a standard place (C:\Users\LOGIN\.ssh\config)
Remove the absolute path of the config file in the "Remote SSH" settings in VSCode
VSCode will still be able to access the settings using the standard path, and the ssh.exe configuration will still look at the same standard path so the connexion is working.
Note:
I have the error only when connecting with multiple ssh servers (using ProxyJump). When connecting only to the first server, the solution of #pszrux and this one are both working for me.
This is probably something everyone has tried before looking here, but it worked for me. The server I was trying to ssh into was not responding, leading to the nonexistant pipe error. I rebooted the server and everything worked fine.
OS: windows 10
In my case there were permission issues. Repeatedly changing inheritance in windows did not solve the issue. Finally this worked
change the folder in which the config file is stored.
From C:/users/usr/.ssh/config to D:/config
and changed the config path in vscode remote ssh settings.
This worked for me.
This seems to be a problem with varied causes and corresponding remedies. In my case the problem had to do with the version of ssh I was using. In my Windows path there were two places were an instance of ssh.exe resided:
C:\Program Files (x86)\OpenSSH\bin
C:\WINDOWS\System32\OpenSSH\
After using both paths to set the "Remote.SSH: Path" parameter (which is in "Remote.SSH: Settings" [see here]), i.e. first C:\Program Files (x86)\OpenSSH\bin\ssh.exe and then C:\WINDOWS\System32\OpenSSH\ssh.exe, the problem still persisted.
Then I looked at this and tried the git-provided ssh.exe, which I already had on my system (otherwise, just install git, it's good stuff anyway :) )
Setting the SSH path parameter with that version did the trick for me, i.e. setting path to:
C:\Program Files\Git\usr\bin\ssh.exe
In my case, I did what dalilander said, but instead of deleting the entire '.ssh' folder, I just needed to delete the file 'known_hosts' and then it worked. So the servers I had saved were not deleted.
The path of that folder is C:\Users\yourUsername\.ssh
For Windows:
Adding the escape character before the private key file name & using quotes around the path solved my issue.
//config file
Host 12.12.12.12
HostName 12.12.12.12
IdentityFile "C:\Users\USERNAME/\PRIVATEKEY" <----Note /\
User username
Trying to add the full path in "IdentityFile" made the trick
" IdentityFile C:\Users\xxx.ssh\xxx"
The solution below may be the last resort but it perfectly solved the issue for me in a Windows 10 local machine. I simply delete the known_hosts file under the directory C:\Users\[your-username]\.ssh, relaunch VS Code and reconnect the remote server through Remote Explorer. Everything works normally afterward.
This seems to be a general error when the ssh connection fails for one of a multitude of reasons.
Adding what my issue was, and what helped, because I don't see it in the other answers in here: I had re-installed the box I was connecting to, and with it, reset the key it was using to authenticate. The ssh process tried to connect and failed with the usual "someone might be MITMing you this very moment, the identification changed" error, visible in the VSCode terminal. Solution was to go to my authorized_keys file and remove the offending key.
Obviously only know that if you know for sure why the identification changed, and that it's harmless. Don't actually get MITMed.
I had this problem once.
All you need to do is,
Go to /Users/XXX/.ssh
if you are on the windows, use command : "del /f known_hosts" to delete the known_hosts on the command prompt.
3.Then go to C:\Users\XXX.ssh\config on the vs code( config file )
4.Delete the host and the user if the host that you are trying to connect to is already there.
5.Then try to connect to the new host as usual.This will work.
The problem here could the mismatch of the finger prints once you reinstall the OS o n your host machine.
So to solve this problem by deleting the host that was saved.
once the config file on the vs code is edited it should look like..below picture is to show how the config file should look(after deleting the host saved)
If you're using WSL and might think that you should update ~/.ssh/config, that might not be the case.
Copy the content from ~/.ssh/config
Append it to C:\User\xxx\.ssh\config windows file
Make sure the public/private key is on C:\User\xxx\.ssh\ and is listed in config
Reconnect
Had an existing(working) configuration and had the same error when I added a new one. What worked for me is instead of just adding a new host configuration, I also commented out the first working config. Didn't know what happened but it worked.
In my case this was an offending key in my known_hosts in Windows (vscode on windows, remote developing via ssh on linux).
The error that comes back in vscode is not explaining in any way.
In my case, the path to key file was wrong.
For me, (windows) the permissions on the .pem file were the Critical issue. I had Administrator group only on the pem file and it was not working. I had to explicitly add the Admin user as well (even though admin is of course in administrator group).
In my case, I had no internet connection.
I was connecting to the server via VPN but the remote configuration was incorrect and I couldn't access the server. (DNS related issues) The connection indicator was showing no errors, so I didn't think of that at first.
Oops :)
I really didn't want to delete my C:Users\valo\.ssh\config, so I played a little with the various entries. It turned out that for me the option IdentitiesOnly yes was the problem. I also disabled security inheritance on all key files in the .ssh folder and left only myself, with Full Rights. Here is what my C:Users\valo\.ssh\config looks like now:
CanonicalizeHostname yes
Host aws.r3
HostName 3.31.45.216
ForwardAgent yes
User ubuntu
IdentityFile C:Users\valo\.ssh\u1-client-20210203-090555.pem
# IdentitiesOnly yes # VSCode Remote doesn't like this flag...?
Host github
HostName github.com
User git
IdentityFile ~/.ssh/id_val_ed25519
Host github.vm
HostName github.com
User git
IdentityFile ~/.ssh/id_valo_ed25519
Host *
ForwardAgent yes
AddKeysToAgent yes
LogLevel FATAL
ChallengeResponseAuthentication no
Now I can connect to aws.r3 with VSCode Remote.
A possible solution:
First run cat $HOME/.ssh/id_rsa.pub on your computer. That will get you a key. Save this key somewhere.
Then open this file by running vim $HOME/.ssh/authorized_keys on the computer that you're are ssh'ing to. Then copy the key in a new line of this file and close it by typing :wq.
You are all set.
In my case it was because the name I gave the host in config was myuser#myhostname. So if your config file looks like this:
Host myuser#myhostname
HostName 12.64.88.234
User myuser
Port 22
Try changing it to this:
Host myuser
HostName 12.64.88.234
User myuser
Port 22
Mine was solved by adding ".pem" extension while specifying the private key.
Here's the sample config text for reference.
Host ec2-3-234-8-176.compute-1.amazonaws.com
HostName ec2-3-234-8-176.compute-1.amazonaws.com
IdentityFile ~/.ssh/privatekey.pem
User username
There can be several reasons that have nothing to do with the accepted answer. For me:
Ubuntu 14.04.1 LTS didn't seem to work
Issues with EC2 auth, see pem file config and pem file permissions
And for yet another seeming cause/solution:
Adding the config path explicitly to settings only caused an EISDIR error.
Removing the listing from known_hosts made it need to confirm the fingerprint, but it didn't provide a way to do that. I could see it trying in the terminal output.
The solution a coworker recommended was to delete the vscode-server files from the server. That was the key step in my case. But...
Connecting to the server using another client, I attempted to rm -rf ~/.vscode-server. I could not delete many of the files because "device or resource busy".
That eventually required doing the following:
fuser ~/.vscode-server/[one of the child files ...]. But, you can probably skip this, because mainly I needed to know what to search for. Plus, fuser and lsof were finicky about returning results -- they often just sit waiting for something, I don't know what.
ps -e | grep node since node is the running process using vscode-server files.
For each PID in the list of node processes from step 2, run ps -o user= -p PID, substituting PID with each process PID in turn. This creates a formatted list of the process's associated user.
This is to determine which node processes you own, so you're not even trying to kill anybody else's.
Starting with the lowest node PID I own, run kill -9 PID. You won't need to run this for all PIDs, because killing a lower PID killed a child PID after a few seconds. So keep checking which node processes still exist after killing one: ps -e | grep node
Finally, once all mine are killed, I can rm -rf ~/.vscode-server
Then, I was able to connect via ssh in VS Code again. And, since I left the fingerprint removed from known_hosts, it even asked to confirm the connection to the server (up top, in the command prompt).
Also, for reference, I left the remote-ssh: settings config file entry, mentioned in other solutions, blank.
For reference or further explanation of certain steps above (I don't intend to elaborate more than I did):
rm: cannot remove ‘.vscode-server/bin/xxxxxx/.nfs000000000xxxxxxxxxxxx’: Device or resource busy
How find out which process is using a file in Linux?
https://unix.stackexchange.com/questions/284934/return-owner-of-process-given-pid/284938
In my case it worked when I added the port in my expression, eg ssh user#host-or-ip -p 22. With '22' the default port number, but you can check which port the ssh system is listening on with the sudo service ssh status command.
WSL Related
In my case, the issue was that my keys were set up on Ubuntu on WSL and VS Code was looking for them in Windows. I copied the keys over from the WSL side to Windows and voila! Worked like a charm!
Steps that I took.
Navigated to the /home//.ssh folder in WSL and then entered explorer.exe .
From there, I copied the id_rsa and id_rsa.pub files and pasted them in the windows side, under C:\Users<username>.ssh
Then I tried connecting again from VS Code and it worked perfectly.

transfer file to remote via cmd

I've done enough search on google and in this site, but I don't find any answer to my problem. I simply want to transfer file from local windows machine into remote ubuntu server.
This is the command I tried:
scp C:/Users/myself/Documents/personal/gd_bundle-g2-g1.crt bitnami#11.123.12.123:/etc/ssl/certs
I get this error:
Permission Denied (Publickey)
Obviously because I didnt key in the keyfile and I dont know where to key in. So please guide me how can I transfer file to remove server with public key specified.
Thanks
edit:
scp -i C:\Users\myself\Documents\personal\ppk\myfile.ppk bitnami#11.123.12.123:/C:/Users/myself/Documents/personal/gd_bundle-g2-g1.crt /etc/ssl/certs
Getting error : wrong format
You need to create an ssh key pair, a public and private key. There are many sites that explain how to do it, usually you run ssh-keygen, such as specified here.
The private key is "id_rsa" and the public key is "id_rsa.pub". On the remote machine you need to place the contents of id_rsa.pub at the end of the $HOME/.ssh/authorized_keys file. If you don't have an authorized_keys file then create one by copying id_rsa.pub there. You will need to use other means than scp to get it there.
Additionally your $HOME/.ssh directory on both machines needs to have good permissions, this is "chmod 700 .ssh" on a unix machine.

SSH keys setup but still asking for password (but not for 2nd, 3rd, etc. sessions)

The target server is a relatively clean install of Ubuntu 14.04. I generated a new ssh key using ssh-keygen and added it to my server using ssh-copy-id. I also checked that the public key was in the ~/.ssh/authorized_keys file on the server.
Even still, I am prompted for a password every time I try to ssh into the server.
I noticed something weird however. After I log into my first session using my password, the next concurrent sessions don't ask for a password. They seem to be using the ssh key properly. I've noticed this behaviour on two different clients (Mint OSX).
Are you sure your SSH key isn't protected by a password? Try the following:
How do I remove the passphrase for the SSH key without having to create a new key?
If that's not the case, it may just be that ssh is having trouble locating your private key. Try using the -i flag to explicitly point out its location.
ssh -i /path/to/private_key username#yourhost.com
Thank you Samuel Jun for the link to help.ubuntu.com - SSH Public Key Login Troubleshooting !
Just a little caveat:
If you copy your authorized keys file outside your encrypted home directory please make sure your root install is encrypted as well (imho Ubuntu still allows for unencrypted root install coupled with encryption of the home directory).
Otherwise this defeats the whole purpose of using encryption in the first place ;)
If this is happening to you on Windows (I'm on Windows 10)
Try running the program that you're trying to connect via ssh to the server as administrator.
For me I was using powershell with scoop to install a couple of things so that I could ssh straight from it. Anyway... I ran PowerShell as admin and tried connecting again and it didn't ask for my password.
For LinuxSE
Check the SE context with
% ls -dZ ~user/.ssh
Must contain unconfined_u:object_r:ssh_home_t:s0
If not, that was the problem , as root run
# for i in ~user/.ssh ~user/.ssh/*
do
semanage fcontext -a -t ssh_home_t $i
done
# restorecon -v -R ~user/.ssh
It looks like it's related to encryption on your home directory and therefore the authorized_keys file cannot be read.
https://unix.stackexchange.com/a/238570
Make sure your ssh public key was copied to the remote host in the right format. If you open the key file to edit it should read 1 line.
Basically, just do ssh-copy-id username#remote. It will take care of the rest.

Can not SSH to openshift

I have problem with accessing SSH to Openshift.
I still can push code to Openshift via Git. But when trying to SSH to Openshift, the server denied with error "no supported authentication methods available (server sent: public key, gssapi-keyex, gssapi-with-mic". I'm using Windows 7.
Do you know what's the problem and how to solve it?
This answer is for Windows users.
Who used puttygen.exe to generate your RSA keys.
And you added the PUBLIC key to your Openshift account, via the web console.
And you can PUTTY in OK, but not SSH from GIT-BASH (or cannot git clone via SSH).
One common reason is the key generated by puttygen.exe, is a PUTTY specific file.
You can convert this to OPENSSH format, from within the puttygen.exe program.
(Menu > Conversions > Export OpenSSH Key)
Save it to a new file, in the same directory as your original PUTTY generated PUBLIC/PRIVATE key pair.
Reference this OPENSSH key from your ~/.ssh/config file.
See step 4 here, if you dont have this config file.
https://confluence.atlassian.com/display/BITBUCKET/Set+up+SSH+for+Git
Test by opening GIT-BASH, and trying your specific "ssh user#yourhost.rhcloud.com" (without the quotes, and where user and your host are specific to your account). If that works, you should be good to go...
Short version:
remove the leading "ssh " from the ssh url provided by the OpenShift web console.
I was frustrated when this happened to me. I tried all things mentioned above. At last I gave up in windows 7 and opened my Ubuntu virtual machine. Then I noticed the leading "ssh " in the url.
I'm also using Windows 7 and I had the same problem.
I created ssh keys with rhc tool and then public key for putty (id_rsa.ppk). Their permissions (GIT Bash, "ls -l" command) were 700 (but I couldn't connect):
-rwx------+ 1 User123 None 1706 Mar 4 19:46 id_rsa
-rwx------+ 1 User123 None 1464 Mar 4 19:52 id_rsa.ppk
-rwx------+ 1 User123 None 394 Mar 4 19:46 id_rsa.pub
So I changed the permission (with chmod command) to 755:
-rwxr-xr-x+ 1 User123 None 1706 Mar 4 19:46 id_rsa
-rwxr-xr-x+ 1 User123 None 1464 Mar 4 19:52 id_rsa.ppk
-rwxr-xr-x+ 1 User123 None 394 Mar 4 19:46 id_rsa.pub
And then both git-bash and ssh from putty started working. I know that these are not the most secure permissions, but for me it's enough. It may also help to run git/putty as administrator, but I didn't try that.
You may want to reach look into what the OpenShift forums provided on no supported authentication methods available (server sent: public key, gssapi-keyex, gssapi-with-mic. The Red Hat Customer Portal also has a good article on this error, however you will need a Silver plan to see this article.
Typically, on linux this error is caused because the key you are using does not have the right permissions. In short your .ssh/id_rsa key's permissions are too lax (they should be 600).
Note that other people have seen similar issues related to this error with OpenShift so permissions may not be the root cause of your particular issue.
go to preference in eclipse and in ssh key menu, click KEY MANAGEMENT and ther is a rsa key tab click that and copy your public key and click the button save as private key... then go to your open shift application and paste your public key and work on it... i hope it working
Reference
TOOLS
We will need two tools to work with :
PuTTY
PuTTYgen
METHOD
Step 1: Generate a brand-new SSH-2 RSA key.
Step 2: Add the generated key in the host (for ex. in settings >> keys on Openshift) that requires the authentication.
Step 3: Export this key from PuTTYgen Conversions >> Export OpenSSH Key and save it on your file-system
Step 4: Add/Edit your ~/.ssh/config file
// ~/.ssh/config
Host HOST_NAME // for example - https://my-domain.rhcloud.com
Port PORT_NUMBER // ideally 22
IdentityFile PATH/TO/FILE/CREATED/IN/STEP/3 // the path to where the key was exported
Example Configuration of ~/.ssh/config
Host cool-websites.rhcloud.com
Port 22
IdentityFile C:/Users/cool_dude/Desktop/rhcloud
Good Luck.
You need to create keys in Puttygen - https://the.earth.li/~sgtatham/putty/latest/x86/puttygen.exe. Format - SSH-2 RSA.
This keys have correct format. It works.
This answer is for Linux users. If you have the same problem, disabling GSSAPI may help.
Edit your ~/.ssh/config (user) or /etc/ssh/ssh_config (system-wide) file to set GSSAPIAuthentication no.
Source: Speed up SSH logon by disabling GSSAPIAuthentication
Connecting the SSH servers can sometimes be delayed when the client
and server try to sort out if they should be using GSSAPI to
authenticate.

ssh: The authenticity of host 'hostname' can't be established

When i ssh to a machine, sometime i get this error warning and it prompts to say "yes" or "no". This cause some trouble when running from scripts that automatically ssh to other machines.
Warning Message:
The authenticity of host '<host>' can't be established.
ECDSA key fingerprint is SHA256:TER0dEslggzS/BROmiE/s70WqcYy6bk52fs+MLTIptM.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'pc' (ECDSA) to the list of known hosts.
Is there a way to automatically say "yes" or ignore this?
Depending on your ssh client, you can set the StrictHostKeyChecking option to no on the command line, and/or send the key to a null known_hosts file. You can also set these options in your config file, either for all hosts or for a given set of IP addresses or host names.
ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no
EDIT
As #IanDunn notes, there are security risks to doing this. If the resource you're connecting to has been spoofed by an attacker, they could potentially replay the destination server's challenge back to you, fooling you into thinking that you're connecting to the remote resource while in fact they are connecting to that resource with your credentials. You should carefully consider whether that's an appropriate risk to take on before altering your connection mechanism to skip HostKeyChecking.
Reference.
Old question that deserves a better answer.
You can prevent interactive prompt without disabling StrictHostKeyChecking (which is insecure).
Incorporate the following logic into your script:
if [ -z "$(ssh-keygen -F $IP)" ]; then
ssh-keyscan -H $IP >> ~/.ssh/known_hosts
fi
It checks if public key of the server is in known_hosts. If not, it requests public key from the server and adds it to known_hosts.
In this way you are exposed to Man-In-The-Middle attack only once, which may be mitigated by:
ensuring that the script connects first time over a secure channel
inspecting logs or known_hosts to check fingerprints manually (to be done only once)
To disable (or control disabling), add the following lines to the beginning of /etc/ssh/ssh_config...
Host 192.168.0.*
StrictHostKeyChecking=no
UserKnownHostsFile=/dev/null
Options:
The Host subnet can be * to allow unrestricted access to all IPs.
Edit /etc/ssh/ssh_config for global configuration or ~/.ssh/config for user-specific configuration.
See http://linuxcommando.blogspot.com/2008/10/how-to-disable-ssh-host-key-checking.html
Similar question on superuser.com - see https://superuser.com/a/628801/55163
Make sure ~/.ssh/known_hosts is writable. That fixed it for me.
The best way to go about this is to use 'BatchMode' in addition to 'StrictHostKeyChecking'. This way, your script will accept a new hostname and write it to the known_hosts file, but won't require yes/no intervention.
ssh -o BatchMode=yes -o StrictHostKeyChecking=no user#server.example.com "uptime"
This warning is issued due the security features, do not disable this feature.
It's just displayed once.
If it still appears after second connection, the problem is probably in writing to the known_hosts file.
In this case you'll also get the following message:
Failed to add the host to the list of known hosts
You may fix it by changing owner of changing the permissions of the file to be writable by your user.
sudo chown -v $USER ~/.ssh/known_hosts
Edit your config file normally located at '~/.ssh/config', and at the beggining of the file, add the below lines
Host *
User your_login_user
StrictHostKeyChecking no
IdentityFile ~/my_path/id_rsa.pub
User set to your_login_user says that this settings belongs to your_login_user
StrictHostKeyChecking set to no will avoid the prompt
IdentityFile is path to RSA key
This works for me and my scripts, good luck to you.
Ideally, you should create a self-managed certificate authority. Start with generating a key pair:
ssh-keygen -f cert_signer
Then sign each server's public host key:
ssh-keygen -s cert_signer -I cert_signer -h -n www.example.com -V +52w /etc/ssh/ssh_host_rsa_key.pub
This generates a signed public host key:
/etc/ssh/ssh_host_rsa_key-cert.pub
In /etc/ssh/sshd_config, point the HostCertificate to this file:
HostCertificate /etc/ssh/ssh_host_rsa_key-cert.pub
Restart the sshd service:
service sshd restart
Then on the SSH client, add the following to ~/.ssh/known_hosts:
#cert-authority *.example.com ssh-rsa AAAAB3Nz...cYwy+1Y2u/
The above contains:
#cert-authority
The domain *.example.com
The full contents of the public key cert_signer.pub
The cert_signer public key will trust any server whose public host key is signed by the cert_signer private key.
Although this requires a one-time configuration on the client side, you can trust multiple servers, including those that haven't been provisioned yet (as long as you sign each server, that is).
For more details, see this wiki page.
Do this -> chmod +w ~/.ssh/known_hosts. This adds write permission to the file at ~/.ssh/known_hosts. After that the remote host will be added to the known_hosts file when you connect to it the next time.
With reference to Cori's answer, I modified it and used below command, which is working. Without exit, remaining command was actually logging to remote machine, which I didn't want in script
ssh -o StrictHostKeyChecking=no user#ip_of_remote_machine "exit"
Add these to your /etc/ssh/ssh_config
Host *
UserKnownHostsFile=/dev/null
StrictHostKeyChecking=no
Generally this problem occurs when you are modifying the keys very oftenly. Based on the server it might take some time to update the new key that you have generated and pasted in the server. So after generating the key and pasting in the server, wait for 3 to 4 hours and then try. The problem should be solved. It happened with me.
The following steps are used to authenticate yourself to the host
Generate a ssh key. You will be asked to create a password for the key
ssh-keygen -f ~/.ssh/id_ecdsa -t ecdsa -b 521
(above uses the recommended encryption technique)
Copy the key over to the remote host
ssh-copy-id -i ~/.ssh/id_ecdsa user#host
N.B the user # host will be different to you. You will need to type in the password for this server, not the keys password.
You can now login to the server securely and not get an error message.
ssh user#host
All source information is located here:
ssh-keygen
For anyone who finds this and is simply looking to prevent the prompt on first connection, but still wants ssh to strictly check the key on subsequent connections (trust on first use), you can set StrictHostKeyChecking to accept-new in ~/.ssh/config, which will do what you're looking for. You can read more about it in man ssh_config. I strongly discourage disabling key checking altogether.
Run this in host server it's premonition issue
chmod -R 700 ~/.ssh
I had the same error and wanted to draw attention to the fact that - as it just happened to me - you might just have wrong privileges.You've set up your .ssh directory as either regular or root user and thus you need to be the correct user. When this error appeared, I was root but I configured .ssh as regular user. Exiting root fixed it.
This is trying to establish password-less authentication. So, if you try to run that command manually once, it will ask to provide the password there. After entering password, it saves that password permanently, and it will never ask again to type 'yes' or 'no'.
For me the reason is that I have wrong permission on ~/.ssh/known_hosts.
I have no write permission on known_hosts file. So it ask me again and again.
In my case, the host was unkown and instead of typing yes to the question are you sure you want to continue connecting(yes/no/[fingerprint])? I was just hitting enter .
I solve the issue which gives below written error:
Error:
The authenticity of host 'XXX.XXX.XXX' can't be established.
RSA key fingerprint is 09:6c:ef:cd:55:c4:4f:ss:5a:88:46:0a:a9:27:83:89.
Solution:
1. install any openSSH tool.
2. run command ssh
3. it will ask for do u add this host like.
accept YES.
4. This host will add in the known host list.
5. Now you are able to connect with this host.
This solution is working now......