we did not send a packet, disable method

Question

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

score 14 · Answer 1 · answered Apr 18 '20 at 13:06

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

One possible cause is that the login shell for the account is set incorrectly in `/etc/passwd`. — miyalys, Feb 22 '22 at 16:26

score 12 · Answer 2 · answered Mar 25 '21 at 18:23

12

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/

answered Mar 25 '21 at 18:23

192dot

121
1
2

Also check the ownership of `.ssh` directory: `ls -lhd .ssh`, it should be the same user. This is stupid but I encountered it and struggled for 30 minutes. – kbridge4096 Oct 09 '21 at 12:22
Actually it should be `chmod go-w /home/user`. I guess that was a typo on your part. I could edit your answer but I don't like to do that so you or someone else might like to do so. – Pryftan Oct 23 '22 at 12:39

score 6 · Answer 3 · edited Jul 13 '20 at 07:00

6

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

edited Jul 13 '20 at 07:00

Yunnosch

26,130
9
42
54

answered Jul 13 '20 at 06:28

rupalisavekar

61
1
2

I've a promlem: iso public key copy into `.ssh/authorized_keys` private key – Grigory Kislin Jan 23 '21 at 13:00
1

I can't believe the problem was in this after all debugging and changing folder permissions :) – Aleks May 17 '21 at 11:38

Peter · Answer 4 · 2021-09-15T03:31:55.390

5

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.

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

edited Sep 15 '21 at 03:31

answered Feb 22 '18 at 10:43

Peter

357
3
10

score 5 · Answer 5 · edited Dec 23 '21 at 06:12

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

This is the only answer that worked for me. Messing with Open SUSE's Micro OS, noticed /etc/ssh/sshd_config didn't exist so I had to create it, and couldn't for the life of me get it to work. What worked for me was cat ~/.ssh/authorized_keys, saw my elliptic curve cryptography public key started with ssh-ed25519 AAAAC3...; sudo vi /etc/ssh/sshd_config; (added "PubkeyAcceptedKeyTypes ed25519"); sudo systemctl restart sshd; and success :), I also went back and found out adding PubkeyAcceptedKeyTypes *, works as well, so that should probably be the answer) — neoakris, Dec 23 '21 at 06:02
It now makes perfect sense "debug2: we did not send a packet, disable method" means the client didn't send the key, because it wasn't an accepted key type, without PubkeyAcceptedKeyTypes *, hum at this point I might as well edit the answer from 99% correct to 100% correct — neoakris, Dec 23 '21 at 06:13

Aymen Alsaadi · Answer 6 · 2019-12-18T21:32:12.547

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 user@xx.xx.xx.xx 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

score 1 · Answer 7 · answered Aug 11 '18 at 22:49

1

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 !!

answered Aug 11 '18 at 22:49

Iain1940

29
5

6

Did you mean `authorized_keys`? – Doctor Coder Mar 08 '19 at 09:37

score 1 · Answer 8 · answered Jan 28 '20 at 15:26

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.

score 1 · Answer 9 · answered Jun 08 '21 at 13:57

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

score 0 · Answer 10 · answered Apr 21 '20 at 21:37

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

Nonor · Answer 11 · 2020-09-24T15:11:19.290

0

Think about selinux, if is enabled,do:

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

edited Sep 24 '20 at 15:11

answered Sep 24 '20 at 15:02

Nonor

1
1

score 0 · Answer 12 · answered Aug 29 '22 at 18:52

I checked and tried every instruction given here and after several hours of troubleshooting, I noticed the SSH server (which is my router) does not have a support for ed25519. Dropbear was spamming the following log: Pubkey auth attempt with unknown algo...

Using an RSA type fixed my issue.

score 0 · Answer 13 · answered Oct 24 '22 at 10:23

Just for those who have the log "we did not send a packet, disable method" when trying to use a public key. Check your sshd_config file on the remote server and force "PubkeyAuthentication" to "yes", even if it should be "yes" by default. For me it solved my connection problem.

score -2 · Answer 14 · answered Mar 04 '22 at 06:44

-2

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

ssh-add ~/.ssh/private_id_rsa

answered Mar 04 '22 at 06:44

0x416e746f6e

9,872
5
40
68

we did not send a packet, disable method

14 Answers14

Linked