Bitbucket SSH authentication - ssh

I have a problem connecting with my SSH service,
ssh-agent is running:
ps -e | grep ssh
12163 ? 00:00:00 ssh-agent
and caches my only identity:
ssh-add -l
4096 25:56:f4:9c:09:65:fe:39:b3:17:73:bd:3c:76:3f:8d /home/matthias/.ssh/id_rsa (RSA)
everything exists as it should:
ls ~/.ssh/
id_rsa id_rsa.pub known_hosts
and id_rsa.pub is uploaded to Bitbucket.org SSH-Keys section..
However SSH authentication fails (using the verbose mode, one can see, that it somehow tries to load the non-existing id_dsa file)
ssh -v -T hg#bitbucket.org
[...]
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/matthias/.ssh/id_rsa
debug1: Authentications that can continue: publickey
debug1: Offering RSA public key: /home/matthias/.ssh/id_rsa
debug1: Remote: Forced command: conq username:matthias_hueser
debug1: Remote: Port forwarding disabled.
debug1: Remote: X11 forwarding disabled.
debug1: Remote: Agent forwarding disabled.
debug1: Remote: Pty allocation disabled.
debug1: Server accepts key: pkalg ssh-rsa blen 535
debug1: key_parse_private_pem: PEM_read_PrivateKey failed
debug1: read PEM private key done: type
Enter passphrase for key '/home/matthias/.ssh/id_rsa':
debug1: read PEM private key done: type RSA
debug1: Remote: Forced command: conq username:matthias_hueser
debug1: Remote: Port forwarding disabled.
debug1: Remote: X11 forwarding disabled.
debug1: Remote: Agent forwarding disabled.
debug1: Remote: Pty allocation disabled.
debug1: Authentications that can continue: publickey
debug1: Trying private key: /home/matthias/.ssh/id_dsa
no such identity: /home/matthias/.ssh/id_dsa: No such file or directory
debug1: Trying private key: /home/matthias/.ssh/id_ecdsa
no such identity: /home/matthias/.ssh/id_ecdsa: No such file or directory
debug1: No more authentication methods to try.
Permission denied (publickey).
Has somebody else run into the same problem and has
a suggestion?
[Thanks for the Edit]

The output you're seeing looks consistent with the server rejecting your id_rsa key. ssh will check for id_rsa, id_dsa, and id_ecdsa even if you don't specify them on the command-line or have them loaded in your ssh-agent.
If I were troubleshooting this, I'd remove ssh-agent from the picture and specify your private key on the command-line.
Run this in a new shell you'll close afterward, so you don't trash your existing environment:
$ bash
$ unset SSH_AGENT_PID SSH_AUTH_SOCK
$ ssh -v -T -i ~/.ssh/id_rsa hg#bitbucket.org
[...]
$ exit
(ssh-keygen should prompt you for your key's password)
If that works, I'd double-check that the key your ssh-agent is providing is actually the correct one. You can
$ ssh-keygen -y -f ~/.ssh/id_rsa
And check that against what's in your ssh-agent:
$ ssh-add -L
If the identity in your agent is different, you should dump your keys with ssh-add -D and re-load them. If it's not different, I'm not sure what's up. Hope that helps a bit.

Related

Should the ssh fingerprint change when the sshd port changes

After changing the sshd port in OpenSSH 8.2, I found that the ssh fingerprint changed. This surprised me since I had assumed it was just dependent on the public key.
What does the fingerprint depend on? Is the port part of it?
On closer examination it looks like the key changed from ssh-rsa to ecdsa-sha2-nistp256. It looks like the server has multiple key files. What determines which key is used and what might have caused a change?
I haven't found the official documentation, but ran into a similar confusion so just experimented a bit.
The hostnames in fingerprints (in .ssh/known_hosts) are hashed, but you can check them with ssh-keygen -H -F 'remote' (you'd see Host remote found...)
It seems that if you're using the default port (22), when you run ssh remote the first time, the fingerprint will only contain the hostname.
You can check this with ssh-keygen -H -F 'remote' (you'd see Host remote found...)
Now, if you change the sshd port on remote (say, to 1234), seems that ssh is still happy with it, because it tries matching against the hostname without the port.
You can see that with the -v flag:
$ ssh -v remote -p 1234
debug1: Authenticating to remote:1234 as 'user'
...
debug1: checking without port identifier
debug1: Host 'remote' is known and matches the ECDSA host key.
debug1: Found key in /home/user/.ssh/known_hosts:11
However -- if the first time you ssh onto remote is with a custom port (ssh remote -p 1234), then it seems to remember the hostname with port:
ssh-keygen -H -F 'remote' -- doesn't result in anything
ssh-keygen -H -F '[remote]:1234' -- results in a match
The ssh output changes slightly too, it's checking both host and port now:
$ ssh -v remote -p 1234
...
debug1: Host '[remote]:1234' is known and matches the ECDSA host key.
debug1: Found key in /home/user/.ssh/known_hosts:12
...
Now if you change the remote sshd port to something else, say back to 22, and run ssh remote, ssh won't be able to verify the host, because it only knows about [remote]:1234, not remote.
(I guess in theory it could still check all 65535 ports against .ssh/known_hosts and give a friendlier error message).
Regarding the key choice: same -v flag might be helpful here:
...
debug1: Will attempt key: /home/user/.ssh/id_rsa RSA <redacted> agent
debug1: Will attempt key: /home/user/.ssh/id_dsa
debug1: Will attempt key: /home/user/.ssh/id_ecdsa
debug1: Will attempt key: /home/user/.ssh/id_ecdsa_sk
debug1: Will attempt key: /home/user/.ssh/id_ed25519
debug1: Will attempt key: /home/user/.ssh/id_ed25519_sk
debug1: Will attempt key: /home/user/.ssh/id_xmss
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<redacted>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering public key: /home/user/.ssh/id_rsa RSA <redacted> agent
debug1: Server accepts key: /home/user/.ssh/id_rsa RSA <redacted> agent
...

why does "ssh root#server" need a id_dsa key?

Why find .ssh/iddsa file. there is no such a file. just id_rsa.
So the issue is that I can login to my server just fine using:
ssh root#SERVER_IP_ADRESS
But when I try to login with a user I created from root:
ssh USERNAME#SERVER_IP_ADRESS5
I get:
Permission denied (publickey).
The steps I went through before this.
SSH generated a key
Created an Ubuntu 16.04 droplet with given SSH key.
SSH into server with root
$ adduser username
usermod -aG sudo username
`$ ssh -vvv root#serverip
OpenSSH7.6p1, LibreSSL 2.6.2
debug1: Reading configuration data /etc/ssh/sshconfig
debug1: /etc/ssh/sshconfig line 48: Applying options for *
debug2: sshconnectdirect: needpriv 0
debug1: Connecting to cleanproject port 22.
debug1: Connection established.
debug1: identity file /Users/happy/.ssh/idrsa type 0
....
...
debug1: Authentications that can continue: publickey
debug1: Trying private key: /Users/happy/.ssh/id_dsa
debug3: no such identity: /Users/happy/.ssh/id_dsa: No such file or directory
debug1: Trying private key: /Users/happy/.ssh/id_ecdsa
debug3: no such identity: /Users/happy/.ssh/id_ecdsa: No such file or directory
debug1: Trying private key: /Users/happy/.ssh/id_ed25519
debug3: no such identity: /Users/happy/.ssh/id_ed25519: No such file or directory
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
root#server: Permission denied (publickey).`
Below steps should help to create and authenticate the new user on the instance.
Ssh into your instance using public key.
Create a new user: $ sudo adduser test123
Change the shell session: $ sudo su test123
Create .ssh folder: $mkdir .ssh
Change the permission: $ chmod 700 .ssh
Confirm $pwd is /home/test123
In .ssh folder, execute these
$ touch authorized_keys
$ chmod 600 authorized_keys
paste your public key here from your local system, id_rsa.pub is the default name if not edited while saving. make sure no extra spaces are copied.
It should work!.
$ssh test123#ip-address

Permission denied on Amazon LightSail

Login works with LightsailDefaultPrivateKey-eu-west-1.pem but not with my own key-pair.
I tried to generate the keys with 'ssh-keygen -t rsa -b 4096 -C "my#email.com" -f ~/.ssh/lsail-mikemittererat-eu-west-1.pem'
I also tried to generate a key on AWS/S2, dowloaded it, generated a public key out of the private key and uploaded it to LightSail - the same result. It doesn't work.
Error-Message:
ssh -i ~/.ssh/ssh_my-website ubuntu#
Permission denied (publickey).
This is what I get if I use the -v option:
ssh -v -i ~/.ssh/lsail-mikemittererat-eu-west-1.pem ubuntu#<public ip>
OpenSSH_6.9p1, LibreSSL 2.1.8
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 21: Applying options for *
debug1: /etc/ssh/ssh_config line 56: Applying options for *
debug1: Connecting to <public ip> [<public ip>] port 22.
debug1: Connection established.
debug1: identity file /Users/mikemitterer/.ssh/lsail-mikemittererat-eu-west-1.pem type 1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/mikemitterer/.ssh/lsail-mikemittererat-eu-west-1.pem-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.9
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.2p2 Ubuntu-4ubuntu2.4
debug1: match: OpenSSH_7.2p2 Ubuntu-4ubuntu2.4 pat OpenSSH* compat 0x04000000
debug1: Authenticating to <public ip>:22 as 'ubuntu'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client chacha20-poly1305#openssh.com <implicit> none
debug1: kex: client->server chacha20-poly1305#openssh.com <implicit> none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:6u6vqWOSbOSNiPYAOqa5q/epSntR7GG5dvFzKuUAJOQ
debug1: Host '<public ip>' is known and matches the ECDSA host key.
debug1: Found key in /Users/mikemitterer/.ssh/known_hosts:38
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /Users/mikemitterer/.ssh/lsail-mikemittererat-eu-west-1.pem
debug1: Authentications that can continue: publickey
debug1: No more authentication methods to try.
Permission denied (publickey).
permission of .pem is set to 600, .ssh ist set to 700
I was able to get this to work as follows:
Generated the SSH keypair as you described above (ssh-keygen -t rsa -b 4096 -C "my#email.com" -f ~/certs/test.pem)
changed permissions on the private key file (chmod 600 test.pem)
ssh'd into the instance using the lightsail integrated console and added the public key to the ~/.ssh/authorized_keys file
I was able to access the instance using ssh -i ~/certs/lightsail.pem ubuntu#
Let me know if this works, or if I'm missing something.
I had same issue for hours, and finally solved it. Here is what I did:
Download the pem file into a folder.
Then run this:
$chmod 600 KEYFILE.pem
And this:
$ssh -i "KEYFILE.pem" bitnami#your_static_ip
As I remember, I've tried the same thing as you, but it didn't work.
I followed all of the steps listed in Add new user accounts with SSH access using an AWS key and a 3rd-party generated key and still got the <USER>#<HOSTNAME>: Permission denied (publickey) error. It turned out that I needed to fix the directory permissions for my custom home directory location and had nothing to do with how I generated the key or uploaded it to the instance.
The required directory permissions detailed in the Troubleshoot "Permission denied (publickey)" knowledge-base article state that the following permissions should be used:
The parent directory of the user's home directory (e.g. /home): 755
The user's home directory (e.g. /home/ec2-user): 700
The user's .ssh/ directory (e.g. /home/ec2-user/.ssh): 0700
The user's authorized_keys file (e.g. /home/ec2-user/.ssh/authorized_keys): 600
Once my directory permissions were correct, my configured key started working.
If the other solutions provided did not work, you might need to check to make sure the username you want to ssh is the owner of .bash_logout, .bashrc, .profile, .ssh and the authorized_keys and known_hosts inside .ssh.
You can login with your main bitnami username to check the above using ls -lash and change them using chown if needed. For example,
sudo chown yoursshusername .bash_logout

ssh : Permission denied (publickey,gssapi-with-mic)

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

Can't get SSH ProxyCommand with sudo on proxy machine to work

I was trying to configure my SSH configs for easier workflows, but I've run against a wall here.
I have a jump host which requires sudo ssh to get to all the other machines.
I've figured out that if I run ssh -tt jumphost sudo ssh desthost that I get asked for my sudo password and I get access to desthost
Now, when I add ProxyCommand ssh -tt jumphost sudo ssh %h to my ssh_config and run ssh desthost then I just get a blank connection.
Debug printout:
OpenSSH_6.2p2, OSSLShim 0.9.8r 8 Dec 2011
debug1: Reading configuration data /Users/deiga/.ssh/config
debug1: /Users/deiga/.ssh/config line 34: Applying options for desthost
debug1: /Users/deiga/.ssh/config line 167: Applying options for *
debug1: Reading configuration data /etc/ssh_config
debug1: /etc/ssh_config line 20: Applying options for *
debug1: auto-mux: Trying existing master
debug1: Control socket "/tmp/ssh-deiga#desthost:22" does not exist
debug2: ssh_connect: needpriv 0
debug1: Executing proxy command: exec ssh -tt jumphost sudo ssh desthost
debug1: identity file /Users/deiga/.ssh/id_rsa type -1
debug1: identity file /Users/deiga/.ssh/id_rsa-cert type -1
debug1: identity file /Users/deiga/.ssh/id_dsa type -1
debug1: identity file /Users/deiga/.ssh/id_dsa-cert type -1
debug1: permanently_drop_suid: 501
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.2
debug1: ssh_exchange_identification: [sudo] password for deiga:
debug1: ssh_exchange_identification: Sorry, try again.
debug1: ssh_exchange_identification: [sudo] password for deiga:
debug1: ssh_exchange_identification: sudo: 1 incorrect password attempt
This is not how the proxy command work. Basic example how you should do jumphosts is this way:
ProxyCommand ssh -W %h:%p jumphost
which doesn't support running sudo on remote machine. But you can do the same with netcat command:
ProxyCommand ssh jumphost nc %h %p
And to make it working with your sudo requirement, just add the sudo command:
ProxyCommand ssh jumphost sudo nc %h %p
If it will not help, please try to diagnose the problem with verbose logs from ssh (-vvv).