0

I know there are lots of topics like this, but I've tried everything and none have solved my problem.

I'm trying to connect from my desktop to my pi with ssh but I get permission denied, please try again. I tried ssh pi@192.168.15.81, ssh pigio@192.168.15.81 (after creating it) and ssh barth-desktop@192.168.15.81. The problem is: I can connect using PuTTy but cannot using directly the ssh from ubuntu, so:

  • ip address and password are correct (a can even PING this address)
  • I can connect with ssh from my pi to the pi with localhost, from my desktop to my pi with PuTTy, and from my desktop to my desktop with localhost
  • I changed the keyboard layout from my desktop to be the same of the pi
  • I'm using raspberry 3B+ so the problem is not the connection of 5GHz
  • I'm using the same network
  • I also Tried to connect from a pi to another, and didn't work.
  • I have enabled it from raspi-config

ssh -v pi@192.168.15.81

OpenSSH_7.6p1 Ubuntu-4ubuntu0.3, OpenSSL 1.0.2n  7 Dec 2017
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 20: Applying options for *
debug1: Connecting to 192.168.15.81 [192.168.15.81] port 22.
debug1: Connection established.
debug1: identity file /home/barth/.ssh/id_rsa type 0
debug1: key_load_public: No such file or directory
debug1: identity file /home/barth/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/barth/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/barth/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/barth/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/barth/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/barth/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/barth/.ssh/id_ed25519-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_7.6p1 Ubuntu-4ubuntu0.3
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.6p1 Ubuntu-4
debug1: match: OpenSSH_7.6p1 Ubuntu-4 pat OpenSSH* compat 0x04000000
debug1: Authenticating to 192.168.15.81:22 as 'pi'
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:fxmXiaMbsyJegCGItGXXOq7xVh+ckOOcWLJi0JVKync
debug1: Host '192.168.15.81' is known and matches the ECDSA host key.
debug1: Found key in /home/barth/.ssh/known_hosts:1
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: 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,password
debug1: Next authentication method: publickey
debug1: Offering public key: RSA SHA256:6RnlUzax+BfvFwyuqjcyzd+SATwjc9aK7L/cLhjYuK4 /home/barth/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /home/barth/.ssh/id_dsa
debug1: Trying private key: /home/barth/.ssh/id_ecdsa
debug1: Trying private key: /home/barth/.ssh/id_ed25519
debug1: Next authentication method: password
pi@192.168.15.81's password: 
debug1: Authentications that can continue: publickey,password
Permission denied, please try again.
pi@192.168.15.81's password: 
  • This looks like a normal sequence and you appear to have a key mismatch /home/barth/.ssh/id_rsa. For whatever reason (which is unlikely to be the Pi) your password is not recognised. As you have provided insufficient detail we can't help. For what it is worth many of us don't use password and have installed publickeys on the Pi. – Milliways Aug 18 at 1:01
0

These lines:

debug1: identity file /home/barth/.ssh/id_rsa type 0
debug1: key_load_public: No such file or directory
debug1: identity file /home/barth/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/barth/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/barth/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/barth/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/barth/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/barth/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/barth/.ssh/id_ed25519-cert type -1

say ssh (i.e., your client) found one private key: id_rsa. All of the others were not found found (type -1).

Then these lines:

debug1: Trying private key: /home/barth/.ssh/id_dsa
debug1: Trying private key: /home/barth/.ssh/id_ecdsa
debug1: Trying private key: /home/barth/.ssh/id_ed25519
debug1: Next authentication method: password

say the client considered sending three different keys, but since it didn't have those keys, it fell through to trying a password.

Note that none of the 3 keys the client considered sending was the id_rsa file that was found.

So, you need to get these things in sync so that the client is offering a key that the server is willing to accept. You can use ssh-keygen to generate different kinds of keys.

| improve this answer | |
  • But this is only true if PasswordAuthentication no is set in /etc/ssh/ssh_config or /etc/sshd_config. – Ingo Aug 18 at 15:55
  • Thanks, it works, but i had to clean up my keys before I set a new one. I had three other problems: 1st is that I had to set PermitRootLogin yes in /etc/ssh/sshd_config, 2nd: I had to add AllowUsers pi and 3rd: delete the AllowUsers pi in my raspberry – Victor Pacheco Bartholomeu Aug 18 at 20:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.