I am trying to ssh to the remote client using a public key but I keep getting the permission denied (publickey) error and can't solve it. I have tried all the other solutions online, but it still won't work. I have replaced some information with * and ip_add. How do I resolve this issue?
PS C:\WINDOWS\system32> ssh -v -i C:/Users/*/.ssh/id_rsa administrator#ip_add
OpenSSH_for_Windows_7.6p1, LibreSSL 2.6.4
debug1: Connecting to ip_add [ip_add] port 22.
debug1: Connection established.
debug1: identity file C:/Users/*/.ssh/id_rsa type 0
debug1: key_load_public: No such file or directory
debug1: identity file C:/Users/*/.ssh/id_rsa-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_for_Windows_7.6
debug1: Remote protocol version 2.0, remote software version OpenSSH_for_Windows_8.1
debug1: match: OpenSSH_for_Windows_8.1 pat OpenSSH* compat 0x04000000
debug1: Authenticating to ip_add:22 as 'administrator'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: chacha20-poly1305#openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305#openssh.com MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:qjxnj9GZZ6kvey+qvHsEoJYnLTz4N82DtnmFMjRlrq8
debug1: Host '192.168.1.135' is known and matches the ECDSA host key.
debug1: Found key in C:\\Users\\*/.ssh/known_hosts:2
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey after 134217728 blocks
debug1: pubkey_prepare: ssh_get_authentication_socket: No such file or directory
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering public key: RSA SHA256:+ymSxB9gd+AJe9wYj0WgW70Qk+x4fWxEQhk1JCQyKWE C:/Users/*/.ssh/id_rsa
debug1: Authentications that can continue: publickey
debug1: No more authentication methods to try.
administrator#ip_add: Permission denied (publickey).
A file or directory with a name that starts with '.' in Unix/Linux is hidden, but in Windows it is not. .ssh is a regular file or directory name. It may be hidden, but then you have to set the hidden attribute, for instance with the command attrib +h .ssh
Also, there is no need to specify -i identityfilename as it defaults to C:\users\<user>\.ssh\known_hosts
The log you show also confirms the host "ip_add" is found in that file. I would say the keys don't match. Easiest way to solve is to remove the line with the host name or IP address "ip_add" (with notepad or any text editor) and just repeat ssh -v administrator#ip_add.
Provided the host with that name or address exists, this will prompt you
The authenticity of host 'ip_add (192.168.1.135)' can't be established.
ECDSA key fingerprint is SHA256:JxuqbzMam5Mgpa52B+xUsSd/3F6kb+yghZKnDX6ipQU.
Are you sure you want to continue connecting (yes/no/[fingerprint])?
and when you respond with yes the host will be added to the known_hosts file again, this time with a correct fingerprint. And the connection should be established.
this is a late answer but I had the same issue
Windows can't see hidden things
First thing (but has nothing to do with the problem) : avoid the Power Shell(it is too powerful), use a simply CMD or best use the Git Bash (https://gitforwindows.org/)
Second, your syntax is almost OK, but you placed the keys in hidden folder
C:\Users\yourname\.ssh\id_rsa and you should place it in a folder that is not hidden like this C:\Users\yourname\ssh\id_rsa and then you can access it like this :
C:\WINDOWS\system32> cd C:\Users\yourname\
C:\Users\yourname/> ssh <user>#<ssh_server> -p 22 -i ~/ssl/id_rsa
Where do you know?
debug1: No more authentication methods to try.
means definitively that you have not the same keys on your host and on remote , or there is a key here and no key there (or combinations of this) it has checked them all and says that "there are NO MORE keys to try".
You must place the same keys on both places in a way the system can read them. You pay attention to this 2 lines:
debug1: identity file C:/Users/*/.ssh/id_rsa type 0
debug1: key_load_public: No such file or directory
he was not able to read the key in the local hidden folder. So ... by moving it in a not hidden folder it will work.
I recently encountered a similar problem on Windows 10 and found the root cause (sort of) and the solution.
My tool chain involved was:
Visual Studio 2019 with git using ssh protocol and a key pair
Sourcetree also using git
A private bitbucket server.
My scenario was this: I installed Visual Studio 2019 with git using ssh protocol with my key pairs and was using it successfully, and then I installed Sourcetree (to get hunk commits instead of whole file commits) and Sourcetree worked but Visual Studio no longer could use git sync/commits.
The key to solving the problem was adding this environment variable: GIT_SSH_COMMAND=ssh -vvv
After restarting Visual Studio I could then get verbose information about the ssh failure using git.
The important debug output was this:
debug1: send_pubkey_test: no mutual signature algorithm
This is when I realized that something was incompatible between my key pair and bitbucket server ssh algorithm. I did not diagnose the exact problem (which I believe is due to obsolete RSA keys) but instead I simply created a new key pair using:
ssh-keygen -t ed25519
then uploaded to the bitbucket server and "bob's your uncle"
12 hours to find, 2 minutes to fix.
I got this same error and searched around for quite a while, changed the permission on my private key, created a new non-admin user to connect with, tried a few other things. Followed these links (among others):
https://geekrewind.com/how-to-set-up-ssh-key-login-with-windows-11/
https://learn.microsoft.com/en-us/windows-server/administration/openssh/openssh_keymanagement
For me, the issue was I had created my keypair using puttygen and OpenSSH on Windows didn't like the format of my PUBLIC key (I had already exported the private key to .pem format).
In my authorized_keys file, the original format was:
---- BEGIN SSH2 PUBLIC KEY ----
Comment: "xxxx"
xxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxx
---- END SSH2 PUBLIC KEY ----
changed it to:
ssh-rsa xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
all on one line, no line breaks, no comment, and everything worked fine.
I know this is an old thread, but hopefully this helps someone.
I generate a ssh key pair on my mac and add the public key to my ubuntu server(in fact, it is a virtual machine on my mac),but when I try to login the ubuntu server,it says:
###########################################################
# WARNING: UNPROTECTED PRIVATE KEY FILE! #
###########################################################
Permissions 0644 for '/Users/tudouya/.ssh/vm/vm_id_rsa.pub' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
bad permissions: ignore key: /Users/tudouya/.ssh/vm/vm_id_rsa.pub
Permission denied (publickey,password).
I have tried many ways to solve this, change the key file mode, change the folder mode,as some answer on stackoverflow,but it doesn't work.
the key file permission:
vm dir:
drwxr-xr-x 4 tudouya staff 136 4 29 10:37 vm
key file:
-rw------- 1 tudouya staff 1679 4 29 10:30 vm_id_rsa
-rw-r--r-- 1 tudouya staff 391 4 29 10:30 vm_id_rsa.pub
please give me some idea...
=========================================
I write the host infomation to ssh_config:
Host ubuntuvm
Hostname 10.211.55.17
PreferredAuthentications publickey
IdentityFile /Users/tudouya/.ssh/vm/vm_id_rsa.pub
I run command "ssh -v ubuntuvm",it displays:
ssh -v ubuntuvm
OpenSSH_6.2p2, OSSLShim 0.9.8r 8 Dec 2011
debug1: Reading configuration data /etc/ssh_config
debug1: /etc/ssh_config line 20: Applying options for *
debug1: /etc/ssh_config line 103: Applying options for *
debug1: /etc/ssh_config line 175: Applying options for ubuntuvm
debug1: Connecting to 10.211.55.17 [10.211.55.17] port 22.
debug1: Connection established.
debug1: identity file /Users/tudouya/.ssh/vm/vm_id_rsa.pub type 1
debug1: identity file /Users/tudouya/.ssh/vm/vm_id_rsa.pub-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.2
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6.1p1 Ubuntu-8
debug1: match: OpenSSH_6.6.1p1 Ubuntu-8 pat OpenSSH*
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5-etm#openssh.com none
debug1: kex: client->server aes128-ctr hmac-md5-etm#openssh.com none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Server host key: RSA 55:6d:4f:0f:23:51:ac:8e:70:01:ec:0e:62:9e:1c:10
debug1: Host '10.211.55.17' is known and matches the RSA host key.
debug1: Found key in /Users/tudouya/.ssh/known_hosts:54
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /Users/tudouya/.ssh/vm/vm_id_rsa.pub
debug1: Server accepts key: pkalg ssh-rsa blen 279
###########################################################
# WARNING: UNPROTECTED PRIVATE KEY FILE! #
###########################################################
Permissions 0644 for '/Users/tudouya/.ssh/vm/vm_id_rsa.pub' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
bad permissions: ignore key: /Users/tudouya/.ssh/vm/vm_id_rsa.pub
debug1: No more authentication methods to try.
Permission denied (publickey,password).
I suggest you to do:
chmod 400 ~/.ssh/id_rsa
It works fine for me.
debug1: identity file /Users/tudouya/.ssh/vm/vm_id_rsa.pub type 1
It appears that you're trying to use the wrong key file. The file with the ".pub" extension contains the public portion of the key. The corresponding file without the ".pub" extension contains the private part of the key. When you run an ssh client to connect to a remote server, you have to provide the private key file to the ssh client.
You probably have a line in the your .ssh/config file (or /etc/ssh_config) which looks like this:
IdentityFile .../.ssh/vm/vm_id_rsa.pub
You need to remove the ".pub" extension from the filename:
IdentityFile .../.ssh/vm/vm_id_rsa
Key should be readable by the logged in user.
Try this:
chmod 400 ~/.ssh/Key file
chmod 400 ~/.ssh/vm_id_rsa.pub
chmod 400 path/to/filename
This work for me. When I did this file I am able to connect to my EC2 instance
change your KEY permission to
chmod 400 your_key.pem
It should work !
After running below command it works for me
sudo chmod 600 /path/to/my/key.pem
In my case, it was a .pem file. Turns out holds good for that too. Changed permissions of the file and it worked.
chmod 400 ~/.ssh/dev-shared.pem
Thanks for all of those who helped above.
SSH keys are meant to be private so a 644 permission is too open.
Binary references to set Permissions
r(read) = 4
w(write) = 2
x(execute) = 1
So by adding these numbers and by passing the summed digit to chmod command,We set the permission of file/directory.
The first digit sets permission for the owner, second digit for group and the third one for all other users on the system who have no right to the file.
A permission of 644 means
(4+2) = read/write permission for the owner
(4) = read permission for the group
(4) = read permission for all other users
By changing the the permission of the file to 400 using
chmod 400 <filename>
solves the issue. As it makes the key read-only accessible to the owner.
Ref: https://www.linux.com/training-tutorials/understanding-linux-file-permissions/
Lot's of similar answers but no explanations...
The error is thrown because the private key file permissions are too open. It is a security risk.
Change the permissions on the private key file to be minimal (read only by owner)
Change owner chown <unix-name> <private-key-file>
Set minimal permissions (read only to file owner) chmod 400 <private-key-file>
If the keys are in the ~/.ssh directory , use
chmod 400 ~/.ssh/id_rsa
If the keys are in different directory, use
chmod 400 directory_path/id_rsa
This worked for me.
chmod 600 id_rsa
Run above command from path where key is stored in vm ex: cd /home/opc/.ssh
I have similar issue and solved it by changing the permission of the respective files and folder worked for me.
This is the solution which is worked for me:
$ chmod 0600 ~/.ssh/id_rsa.pub
$ chmod 0600 ~/.ssh/authorized_keys
$ chmod 0600 ~/.ssh/id_rsa
$ chmod 0700 ~/.ssh
You have to run the command bellow
chmod 400 /path/to/my/key.pem
As for me, the default mode of id_rsa is 600, which means readable and writable.
After I push this file to a git repo and pull it from another pc, sometimes the mode of the private key file becomes -rw-r--r--.
When I pull the repo with ssh after specify the private key file, it failed and prompted warnings the same with you. Following is my script.
ssh-agent bash -c "ssh-add $PATH_OF_RSA/id_rsa; \
git pull git#gitee.com:someone/somerepo.git "
I fix this problem just by changing the mode to 600.
chmod 600 $PATH_TO_RSA/id_rsa
giving permision 400 makes the key private and not accessible by someone unknown. It makes the key as a protected one.
chmod 400 /Users/tudouya/.ssh/vm/vm_id_rsa.pub
Just run below to your pem's
sudo chmod 600 /path/to/my/key.pem
If youre using a .ssh/config file try to
chmod 0400 .ssh/config
then:
chmod 0400 .ssh/<<KEYFILE_PATH>>
This should do the trick:
chmod 600 id_rsa
chmod 400 /etc/ssh/* works for me.
Those who suggested chmod 400 id_rsa.pub did not sound right at all. It was quite possible that op used pub key instead of private key to ssh.
So it might be as simple as ssh -i /Users/tudouya/.ssh/vm/vm_id_rsa (the private key) user#host to fix it.
--- update ---
Check this article https://www.digitalocean.com/community/tutorials/how-to-set-up-ssh-keys--2 for how to set up ssh key
I had this issue with a macbook m1, I later realized that i was missing sudo from the connection script
sudo ssh -i "key.pem" ubuntu#IP_Address
Ensure you are not missing the sudo in your connection script if you are using a macbook.
This problem had a quick and easy fix. You just had to change the permissions on the pem file using the following command.
chmod 400 /Users/yourUserName/pathOfYourFile/fileName.pem
This command will make the file read only and remove all other permissions on the file
There has been a lot of great explanation above, so I recommend reading and understanding.
Here is my simple step by step solution:
On your terminal, run:
open ~/.ssh/config
In your file, you will see something similar to this (in my personal case):
Host *
IgnoreUnknown UseKeychain
AddKeysToAgent yes
IdentityFile ~/.ssh/id_ed25519.pub
or like this (as per the example in this question).
Hostname 10.211.55.17
PreferredAuthentications publickey
IdentityFile /Users/tudouya/.ssh/vm/vm_id_rsa.pub
Remove the ".pub" extention from the last line, which should look like:
Hostname 10.211.55.17
PreferredAuthentications publickey
IdentityFile /Users/tudouya/.ssh/vm/vm_id_rsa
or in my case:
Host *
IgnoreUnknown UseKeychain
AddKeysToAgent yes
IdentityFile ~/.ssh/id_ed25519
Save the file and test your ssh connection.
i had similar issues and this was what i did and it worked.
sudo ssh -i webhost.pem ubuntu#ipaddress
I removed the .pub file, and it worked.
i'm use centos 5.9.
after installing gitlab by this link ssh not working.
before install gitlab ssh correctly working.
i'm using this server localy and other services such as elastix and apache,mysql installed on server.
appeare this error :
OpenSSH_6.9p1 Ubuntu-2ubuntu0.1, OpenSSL 1.0.2d 9 Jul 2015
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to 192.168.88.23 [192.168.88.23] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_rsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.9p1 Ubuntu-2ubuntu0.1
debug1: Remote protocol version 2.0, remote software version OpenSSH_4.3
debug1: match: OpenSSH_4.3 pat OpenSSH_4* compat 0x00000000
debug2: fd 3 setting O_NONBLOCK
debug1: Authenticating to 192.168.88.23:22 as 'root'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: curve25519-sha256#libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa-cert-v01#openssh.com,ssh-rsa-cert-v00#openssh.com,ssh-rsa,ecdsa-sha2-nistp256-cert-v01#openssh.com,ecdsa-sha2-nistp384-cert-v01#openssh.com,ecdsa-sha2-nistp521-cert-v01#openssh.com,ssh-ed25519-cert-v01#openssh.com,ssh-dss-cert-v01#openssh.com,ssh-dss-cert-v00#openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519,ssh-dss
debug2: kex_parse_kexinit: chacha20-poly1305#openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm#openssh.com,aes256-gcm#openssh.com,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc#lysator.liu.se
debug2: kex_parse_kexinit: chacha20-poly1305#openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm#openssh.com,aes256-gcm#openssh.com,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc#lysator.liu.se
debug2: kex_parse_kexinit: umac-64-etm#openssh.com,umac-128-etm#openssh.com,hmac-sha2-256-etm#openssh.com,hmac-sha2-512-etm#openssh.com,hmac-sha1-etm#openssh.com,umac-64#openssh.com,umac-128#openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1,hmac-md5-etm#openssh.com,hmac-ripemd160-etm#openssh.com,hmac-sha1-96-etm#openssh.com,hmac-md5-96-etm#openssh.com,hmac-md5,hmac-ripemd160,hmac-ripemd160#openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: umac-64-etm#openssh.com,umac-128-etm#openssh.com,hmac-sha2-256-etm#openssh.com,hmac-sha2-512-etm#openssh.com,hmac-sha1-etm#openssh.com,umac-64#openssh.com,umac-128#openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1,hmac-md5-etm#openssh.com,hmac-ripemd160-etm#openssh.com,hmac-sha1-96-etm#openssh.com,hmac-md5-96-etm#openssh.com,hmac-md5,hmac-ripemd160,hmac-ripemd160#openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib#openssh.com,zlib
debug2: kex_parse_kexinit: none,zlib#openssh.com,zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc#lysator.liu.se
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc#lysator.liu.se
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160#openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160#openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib#openssh.com
debug2: kex_parse_kexinit: none,zlib#openssh.com
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug1: kex: server->client aes128-ctr hmac-sha1 none
debug1: kex: client->server aes128-ctr hmac-sha1 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<7680<8192) sent
debug1: got SSH2_MSG_KEX_DH_GEX_GROUP
debug2: bits set: 3111/6144
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: got SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Server host key: ssh-rsa SHA256:7J6JOe94H9PedNKlx6yG/wMy6ZYC8iB74WdOVGDgY7A
debug1: Host '192.168.88.23' is known and matches the RSA host key.
debug1: Found key in /root/.ssh/known_hosts:1
debug2: bits set: 3102/6144
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /root/.ssh/id_rsa ((nil)),
debug2: key: /root/.ssh/id_dsa ((nil)),
debug2: key: /root/.ssh/id_ecdsa ((nil)),
debug2: key: /root/.ssh/id_ed25519 ((nil)),
debug1: Authentications that can continue: publickey,gssapi-with-mic
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure. Minor code may provide more information
No Kerberos credentials available
debug1: Unspecified GSS failure. Minor code may provide more information
No Kerberos credentials available
debug1: Unspecified GSS failure. Minor code may provide more information
debug1: Unspecified GSS failure. Minor code may provide more information
No Kerberos credentials available
debug2: we did not send a packet, disable method
debug1: Next authentication method: publickey
debug1: Trying private key: /root/.ssh/id_rsa
debug1: Trying private key: /root/.ssh/id_dsa
debug1: Trying private key: /root/.ssh/id_ecdsa
debug1: Trying private key: /root/.ssh/id_ed25519
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
Permission denied (publickey,gssapi-with-mic).
Setting 700 to .ssh and 600 to authorized_keys solved the issue.
chmod 700 /root/.ssh
chmod 600 /root/.ssh/authorized_keys
I had the same issue while using vagrant. So from my Mac I was trying to ssh to a vagrant box (CentOS 7)
Solved it by amending the /etc/ssh/sshd_config PasswordAuthentication yes then re-started the service using sudo systemctl restart sshd
Hope this helps.
Setting PasswordAuthentication to yes, is not the best way to go ,
is not as secure as using private and public keys for authentication !
First make sure that that you have the fallowing permissions set, on the server side.
First check your home dir (SERVER SIDE)
[vini#random ~]$ ls -ld ~
drwx------. 3 vini vini 127 Nov 23 15:29 /home/vini
if it is not like this, run
chmod 0700 /home/your_home
Now check .ssh folder
[vini#random ~]$ ls -ld /home/vini/.ssh/
drwx------. 2 vini vini 29 Nov 23 15:28 /home/vini/.ssh/
if it is not looking like this, run
chmod 0700 /home/your_home/.ssh
now make sure that authorized_keys looks like this
[vini#venon ~]$ ls -ld /home/vini/.ssh/authorized_keys
-rw-------. 1 vini vini 393 Nov 23 15:28 /home/vini/.ssh/authorized_keys
or just run
chmod 0600 /home/your_home/.ssh/authorized_keys
After that go to /etc/ssh/sshd_config
For best security set
PermitRootLogin no
PubkeyAuthentication yes
keep as yes for testing purposes
PasswordAuthentication yes
Make sure that
ChallengeResponseAuthentication no
Comment those lines for GSSAPI
# #GSSAPIAuthentication yes
# #GSSAPICleanupCredentials no
Make sure that is set to UsePAM yes
UsePAM yes
now restart sshd service
systemctl restart sshd
on the client side
cd /home/your_home/.ssh
generate new keys; setting a password is optional but is a good idea
ssh-keygen -t rsa -b 2048
copy pub key to your server
ssh-copy-id -i id_rsa.pub user_name#server_ip
start ssh agent
eval $(ssh-agent)
ssh-add /home/user/.ssh/your_private_key
now your are good to go !
ssh user_name#server_ip
if everything works just fine
make a backup of your private key and then deny PasswordAuthentication
PasswordAuthentication no
Restart you server
now anyone trying to ssh into your server, without your keys should get
vini#random: Permission denied (publickey).
keep script kids away from your business, and good luck
As everybody else has already said you need to edit /etc/ssh/sshd_config and change PasswordAuthentication no to PasswordAuthentication yes
I ran into this problem setting up a Vagrant box - so therefore it makes sense to script this and do it automatically in a shell provisioner:
sudo sed -i 's/PasswordAuthentication no/PasswordAuthentication yes/g' /etc/ssh/sshd_config;
sudo systemctl restart sshd;
The isssue is the username for most publickey errors on centos instances on AWS.
For Permission denied (publickey,gssapi-keyex,gssapi-with-mic):
its pretty simple. Just change your username from centos to ec2-user and the issue is solved.
Thank me later :)
please make sure following changes should be uncommented, which I did and got succeed in centos7
vi /etc/ssh/sshd_config
1.PubkeyAuthentication yes
2.PasswordAuthentication yes
3.GSSAPIKeyExchange no
4.GSSAPICleanupCredentials no
systemctl restart sshd
ssh-keygen
chmod 777 /root/.ssh/id_rsa.pub
ssh-copy-id -i /root/.ssh/id_rsa.pub user#ipaddress
thank you all and good luck
I had the same problem. In my case, macOS doesn't load my SSH keys, but I fix it with:
ssh-add <SSH private key>
ssh-add <SSH public key>
I couldn't connect to a Droplet on DigitalOcean, but the subsequent commands work for me.
You can go to the forum here.
According to the line debug1: Authentications that can continue: publickey,gssapi-with-mic , ssh password authentication is disabled and apparently you are not using public key authentication.
Login to your server using console and open /etc/ssh/sshd_config file with an editor with root user and look for line PasswordAuthentication then set it's value to yes and finally restart sshd service.
Tried a lot of things, it did not help.
It get access in a simple way:
eval $(ssh-agent) > /dev/null
killall ssh-agent
eval `ssh-agent`
ssh-add ~/.ssh/id_rsa
Note that at the end of the ssh-add -L output must be not a path to the key, but your email.
In Centos 7
Error : publickey,gssapi-keyex,gssapi-with-mic
Ans : Root access to vi /etc/ssh/sshd_config and change the PasswordAuthentication ( no ) to yes.
2 . Restart the sshd services
root> systemctl restart sshd.service
Logon into local id via putty without key.
As a few others have mentioned, make sure you are using the right private key when you ssh into your server. I had multiple ssh private keys set up in my directory, so it was defaulting to a different key. To ssh with the correct key call it out in your CLI call ssh centos#IP-ADDRESS -i YOUR-PATH-TO-KEY, in my case the path was ~/.ssh/id_rsa
Nobody has mention this in. above answers so i am mentioning it.
This error can also come if you're in the wrong folder or path of your pem file is not correct. I was having similar issue and found that my pem file was not there from where i am executing the ssh command
cd KeyPair
ssh -i Keypair.pem ec2-user#244.255.255.255
I know this is an old question, but thought I'd add my fix in the pot.
I was getting the same error trying to connect to Amazon Linux from Ubuntu. The solution was to simply change this:
ssh-add -c <key_location>.pem
to this:
ssh-add "<key_location>.pem"
... pretty simple change there got me in.
fixed by setting GSSAPIAuthentication to no in /etc/ssh/sshd_config
Maybe you should assign the public key to the authorized_keys, the simple way to do this is using ssh-copy-id -i your-pub-key-file user#dest.
And I think this will clearify the cause of posted problem, actualy this is bug of pssh itself (contains inside "askpass-client.py"). It is pssh's lib file. And there is documented issue for -A case:
https://code.google.com/archive/p/parallel-ssh/issues/80
There are two possible resolutions to use version of pssh containing this bug in case you forced to use passphrase for private key access:
Correct your "askpass-client.py" as described in link listed before in my post.
Using your favorite pass keeper.
Thnks for attention, hope it helps!
I try
rm ~/.ssh/id_rsa.pub
then it work!
First a password login has to be established to remote machine
Firstly make a password login
you have to enable a password login by enabling the property ie) PasswordAuthentication yes in sshd_config file.Then restart the sshd service and copy the pub key to remote server (aws ec2 in my case), key will be copied without any error
Without password login works if and only if password login is made first
copy the pub key contents to authorised keys, cat xxx.pub >> ~/.ssh/authorized_keys
This can happen if you are missing the correct id_rsa key set up in authorized_keys for an AWS instance.
Exact error I got (this article came up when I googled the error):
ec2-user#X.X.X.X: Permission denied (publickey,gssapi-keyex,gssapi-with-mic).
Note: If you have many keys, you have to either specify the key on the ssh command line or else add it to you ssh-agent keys (see ssh-add -l). Only the first 6 keys from ssh-agent may work - the default sshd MaxAuthTries config value is 6.
Hope, this will help someone. Problem I encountered is, I was completely using wrong key with the IP. Make sure you are using the right key for the right IP
For me it is a completely mistake, someone copy paste the key into the same row with another key, after separating them into two different lines then it works again, so check if your authorized_key file has similar mistakes !
I had same issue Permission denied (publickey, gssapi-keyex, gssapi-with-mic) earlier.
I had to go /etc/ssh/sshd_config to add the user user into AllowUsers section, then restarted sshd service.
Let me share with you how I did it and I am sure you will find good answer here.
Make sure the following
Step 1. You have Public DNS (IPv4) from aws E.g ec2-IPV4.us-east-2.compute.amazonaws.com
Step 2. You remember where your your_secret_key_is.pem E.g its better to keep it far from root of the known folders like Downloads, Desktop or Documents
Step 3 Open terminal and add the command sudo ssh -v -i path-to-key.pem ec2-user#host
ec2-user is important because it for some linux server it is the username
sudo it needs permission to execute
host It is Amazon Public DNS (IPv4) (copy step 1)
Find more info here
Permission denied (publickey)
seems like an issue generated by the ssh client rather than the ssh server in my case.
Here's what caused my problem and how I solved.
The problem source is I used sudo to generate the keys like this:
sudo ssh-keygen -t ed25519 -f ~/.ssh/serverA_ed25519_key
This automatically set the owner of these key files to root only, so my current user doesn't have permission to read the keys.
Now solution #1 is change the file ownership to your current user. This's what I did.
sudo chown CURRENT_USER ~/.ssh/serverA_ed25519_key
Solution #2 would be just run ssh client with sudo when you try to connect to the ssh server.
Finally, a trick to find the source of problem with ssh client.
ssh -v -o IdentitiesOnly=yes -i ~/.ssh/serverA_ed25519_key me#serverA
This let me focus on the problem by:
show verbose info by -v flag.
the -o option and -i ~/.ssh/serverA_ed25519_key force ssh client to try with this key ONLY, not all the keys you have.
I also have this error info : Permission denied (publickey,gssapi-keyex,gssapi-with-mic).
Using cmd: ssh -i "~/.ssh/old.pem" user#ip cause the error.
Problem is old.pem has been deprecated， after changing to newest pem file，
the error disappears.
In my case, I was using wrong username. Fixed that and the issue got resolved.
The issue is simple, the owner for the key should be one in case if windows ( Just remove other users and keep only one or deny other users permissions) for linux/Mac just do a chmod 400 as this will only give read permission only to the user and no permission to groups or public.
I run into this strange error whiles connecting from my Mac(host) to a CentOS(7.9) guest. I had to explicitly passed the key file to the ssh client ssh root#ip -i private_key_file before connection was successful.
Earlier on, I had enabled the following after the usual key generation with ssh-keygen and copying with ssh-copy-id
PermitRootLogin yes #Logging in with root, it was set by default
PasswordAuthentication no
I decided against using the default name provided by ssh-keygen though the generated file was saved at the same location as the default.
I left the other default values untouched.
Don't forget to restart sshd on the remote machine.
I got Sucess !!
I've copied my ssh_keys from my other machine and tryed to log to my AWS EC2, but it failed:
sign_and_send_pubkey: signing failed for RSA "/home/xxxx/.ssh/my_rsa" from agent: agent refused operation
ec2-user#bla-blah-blah.zzzzz.amazonaws.com: Permission denied (publickey,gssapi-keyex,gssapi-with-mic).
The solution was:
cd $HOME/.ssh
ls -l
-r-x------ 1 xxxx xxxx 1766 May 4 09:13 id_rsa
-r-x------ 1 xxxx xxxx 405 May 4 09:13 id_rsa.pub
-rw-r--r-- 1 xxxx xxxx 444 May 6 17:18 known_hosts
Optional command:
rm known_hosts
chmod 400 id*
ssh -i ./id_rsa.pub ec2-user#bla-blah-blah.zzzzz.amazonaws.com
Last login: Fri May 6 19:09:48 2022 from 123.456.77.9
__| __|_ )
_| ( / Amazon Linux 2 AMI
___|\___|___|
Just run this to add your key to localhost of current user.
ssh-copy-id localhost
So, I'm going through this tutorial (Running Hadoop on windows using cygwin...) to setup hadoop on my WINDOWS (please don't ask why I would use Linux). So I got to this point that I need to SSH to my localhost and test the SSH using Cygwin, but it closes the connection and says:
Connection closed by 127.0.0.1
I've googled a lot but couldn't find any proper answer for my problem.
P.S.: I'm running cygwin on Windows 7 professional x64
any idea?
BTW, Here is a sample run:
$ ssh -v localhost
OpenSSH_6.0p1, OpenSSL 1.0.1c 10 May 2012
debug1: Reading configuration data /etc/ssh_config
debug1: Connecting to localhost [127.0.0.1] port 22.
debug1: Connection established.
debug1: identity file /home/Soroush/.ssh/id_rsa type 1
debug1: identity file /home/Soroush/.ssh/id_rsa-cert type -1
debug1: identity file /home/Soroush/.ssh/id_dsa type -1
debug1: identity file /home/Soroush/.ssh/id_dsa-cert type -1
debug1: identity file /home/Soroush/.ssh/id_ecdsa type -1
debug1: identity file /home/Soroush/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.0
debug1: match: OpenSSH_6.0 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.0
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA 19:2d:f6:84:4d:e5:0d:d4:5e:e6:e5:a4:6a:3c:ea:8b
debug1: Host 'localhost' is known and matches the ECDSA host key.
debug1: Found key in /home/Soroush/.ssh/known_hosts:1
debug1: ssh_ecdsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/Soroush/.ssh/id_rsa
Connection closed by 127.0.0.1
When you installed Cygwin and ran ssh-host-config, you might have created user cyg_server. So when you are connecting to ssh, you need to use the user cyg_server#localhost.
When you run ssh with that user, it will ask you for the password that you provided when you ran ssh-host-config.
$ ssh cyg_server#localhost
cyg_server#localhost's password:
Last login: Mon Dec 31 01:14:44 2012 from ::1
cyg_server#polorumpus ~
$
I hope it will be useful.
It looks like the key isn't being accepted. Check that /home/Soroush/.ssh/id_rsa.pub has been added to /home/Soroush/.ssh/authorized_keys
I would also check that
RSAAuthentication yes is set in /etc/ssh/sshd_config
I had to do these to fix the problem:
chown <USERNAME> /var/log/sshd.log
chown -R <USERNAME> /var/empty
chown <USERNAME> /etc/ssh*
chmod 755 /var/empty
chmod 644 /var/log/sshd.log
Note that the is my desired user name, not cyg_server.
I Found this post relating to my issue, but it turned out that my cyg_server account did not have administrator privilege.
I had the same problem, and it was generated by Putty authentication agent (Pageant): it was running with a private key. For some reason, it tried to use it to connect to localhost. If I closed Pageant (or removed the key), I could ssh to localhost.
But as I wanted to have Pageant running (to be a client of other ssh servers), I managed to modify the local sshd service, so that it 'ignored' in some way Pageant, to accept connections:
Modify /etc/ssh/sshd_config:
PubkeyAuthentication no
Now, it works
I had to use the 64-bit version of Cygwin to get this to work.