'we did not send a packet, disable method

I have tried to setup public key connection between AIX to AIX and that's working and I am facing problem while I setup same public key connection between AIX and DataPower appliance.

I could see in logs that's connection established but while using public I am not able to login and everytime expecting to enter password manually.

Can someone please help on this?

debug1: Authentications that can continue: publickey,password
debug3: start over, passed a different list publickey,password
debug3: preferred publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: ./***_rsa.pub
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred: ,password
ssh-keysibm-datapower


Solution 1:[1]

There are many, many reasons why client-side debugging (ssh -vvv ...) shows:

debug2: we did not send a packet, disable method

Many of these are listed in the answers to SSH public key won't send to server on Unix & Linux, but, unfortunately, the client does not give any indication as to which one applies.

When I was struggling with this, my main problem was getting server-side logging/debugging to show. Of great help was the following (paraphrased) suggestion taken from Ciro Santilli ?????????????'s answer to How to check sshd log? on ServerFault:

Start a new SSH Server instance on a new port in debug mode with:

/usr/sbin/sshd -d -p 2222

then connect to it from the client with:

ssh -p 2222 user@host

Solution 2:[2]

I solved the same problem
(when I checked in my system there is .ssh/authorized_keys : the filename was wrong)
this way:

cp -p .ssh/authorised_keys .ssh/authorized_keys

Solution 3:[3]

If you have sudo access to the destination server, check the SSH logs (/var/log/secure), it may give you some clue. For my case it was a bad permission on the home directory.

chmod g-w /home/user
chmod 700 /home/user/.ssh
chmod 600 /home/user/.ssh/authorized_keys

Reference: https://chemicloud.com/kb/article/ssh-authentication-refused-bad-ownership-or-modes-for-directory/

Solution 4:[4]

Refer to this answer SSH public key won't send to server.
In your log

Offering RSA public key: ./***_rsa.pub
...
we did not send a packet, disable method

It means that the client didn't send the key file. So make sure the key file exists.

  1. Check the key file is in your local path
  2. Make sure the public key content is copied into ~/.ssh/authorized_keys in remote server.

Solution 5:[5]

Check the ssh configuration on remote server to find if remote system is accepting type of key being passed.

Check the file /etc/ssh/sshd_config and look for property PubkeyAcceptedKeyTypes to confirm that it accepts key type being passed. For instance, here the key type seems to be ssh-rsa, so that should be added to the list of PubkeyAcceptedKeyTypes
(or for maximium compatibility PubkeyAcceptedKeyTypes *)

Once added, restart sshd daemon

EX:

sudo sed -i "/.*PubkeyAcceptedKeyTypes.*/d"     /etc/ssh/sshd_config
sudo sed -i "/.*RSAAuthentication.*/d"          /etc/ssh/sshd_config
sudo sed -i "/.*PubkeyAuthentication.*/d"       /etc/ssh/sshd_config
sudo sed -i "/.*PasswordAuthentication.*/d"     /etc/ssh/sshd_config
sudo sed -i "/.*PermitRootLogin.*/d"            /etc/ssh/sshd_config
echo "PubkeyAcceptedKeyTypes *"   | sudo tee -a /etc/ssh/sshd_config
echo "RSAAuthentication yes"      | sudo tee -a /etc/ssh/sshd_config
echo "PubkeyAuthentication yes"   | sudo tee -a /etc/ssh/sshd_config
echo "PasswordAuthentication no"  | sudo tee -a /etc/ssh/sshd_config
echo "PermitRootLogin no"         | sudo tee -a /etc/ssh/sshd_config
sudo systemctl restart sshd.service
sudo systemctl status  sshd.service | grep -i success

Solution 6:[6]

I've just had the same problem. Two raspberry Pis on my local network - one connected, one didn't (with the 'debug2: we did not send a packet, disable method' error)

after 4 hours I found the problem Being used to uk spelling I created the 'authorised_users' file not 'authorized_users'

Doh !!

Solution 7:[7]

So what happened for me is that I have 2 VMs to access from my local machine (2 keys id_rsa.pub and id_rsa2.pub). I realized that my ssh connection is using id_rsa.pub by default for any ssh [email protected] connection. I solved my issue by adding a config file and specify the identity to be used for every host like the following :

vi ~/.ssh/config

Add both hostnames and their identity file as follows:

Host server1.nixcraft.com
  IdentityFile ~/Users/.ssh/id_rsa1
Host server2.nixcraft.com
  IdentityFile ~/Users/.ssh/id_rsa2

Solution 8:[8]

This happened to me and, after several hours banging my head against the wall, I realized there was a typo in the public key file. Instead of beginning with

ssh-rsa

there was a + sign at the beginning:

+ssh-rsa

I know it's obvious in retrospect, but it doesn't hurt to double check your file.

Solution 9:[9]

This can happen if in your /etc/ssh/sshd_config you have the following entry

PubkeyAcceptedKeyTypes=+ssh-dss

as opposed to

PubkeyAcceptedKeyTypes +ssh-dss #this is the correct entry

After updating this, be sure to issue a

sudo systemctl restart sshd #Ubuntu

Solution 10:[10]

Think about selinux, if is enabled,do:

# sudo ausearch -c "sshd" --raw | audit2allow -M my-sshd  
# sudo semodule -i my-sshd.pp

Solution 11:[11]

It looks like there can be a lot of things causing this problem. In my case I forgot to specified the User name in my ~/.ssh/config file. Apparently, it depends on your current login name.

Host dev
HostName 1.2.3.4
IdentityFile ~/.ssh/id_rsa
User John

Solution 12:[12]

In my case the private key must have been added to the agent with:

ssh-add ~/.ssh/private_id_rsa

Related Questions