scp error: "Permission denied (publickey). lost connection"

Question

I tried to scp an svn dump to savannah, but I got the following error at the end.

Permission denied (publickey).
lost connection

The scp command and verbose output are below. Any ideas?

[wcyang@be2-wireless-pittnet-60-37 ~]$ scp -v diffcolor-dump.bz2 [email protected]:/srv/download/diffcolor/
Executing: program /usr/bin/ssh host dl.sv.gnu.org, user wcyang, command scp -v -t /srv/download/diffcolor/
OpenSSH_5.2p1, OpenSSL 0.9.7l 28 Sep 2006
debug1: Reading configuration data /etc/ssh_config
debug1: Connecting to dl.sv.gnu.org [140.186.70.73] port 22.
debug1: Connection established.
debug1: identity file /Users/wcyang/.ssh/identity type -1
debug1: identity file /Users/wcyang/.ssh/id_rsa type 1
debug1: identity file /Users/wcyang/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.1p1 Debian-5
debug1: match: OpenSSH_5.1p1 Debian-5 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.2
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: 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: Host 'dl.sv.gnu.org' is known and matches the RSA host key.
debug1: Found key in /Users/wcyang/.ssh/known_hosts:1
debug1: ssh_rsa_verify: signature correct
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: Trying private key: /Users/wcyang/.ssh/identity
debug1: Offering public key: /Users/wcyang/.ssh/id_rsa
debug1: Authentications that can continue: publickey
debug1: Trying private key: /Users/wcyang/.ssh/id_dsa
debug1: No more authentication methods to try.
Permission denied (publickey).
lost connection

Solution 1

Did you expect to be prompted for a password? If so, then something in your ssh or the remote server's sshd configuration's changed to disallow password authentication.

Otherwise, your debug output seems to be saying that your private keys don't match any of the public keys in the remote account's .ssh directory. Have you compared the ~/.ssh/id_?sa.pub files on savannah to the output from ssh-keygen -y on your local box?

Another possibility is that the permissions on your .ssh files are too permissive. I believe I've seen that happen without any output, debug or otherwise, to hint at it.

Solution 2

This is a authentication error, there is not a matching key to pair to.

When having problems with ssh or using ssh over scp as your doing the -v switch is very informative to diagnose the problem, the more v's you put in there the more verbose the output:

scp -vvv -P 30000 /somedir/somedir/file user@domain:/somedir/somedir/

Here is a sample output of it:

OpenSSH_6.7p1 Debian-5+deb8u7, OpenSSL 1.0.1t  3 May 2016
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.1.171 [192.168.1.171] port 30000.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/identity type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/identity-cert type -1
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: Remote protocol version 2.0, remote software version OpenSSH_7.4p1 Debian-10+deb9u4
debug1: match: OpenSSH_7.4p1 Debian-10+deb9u4 pat OpenSSH* compat 0x04000000
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.7p1 Debian-5+deb8u7
debug2: fd 3 setting O_NONBLOCK
debug3: put_host_port: [192.168.1.171]:30000
debug3: load_hostkeys: loading entries for host "[192.168.1.171]:30000" from file "/root/.ssh/known_hosts"
debug3: load_hostkeys: found key type ECDSA in file /root/.ssh/known_hosts:7
debug3: load_hostkeys: loaded 1 keys
debug3: order_hostkeyalgs: prefer hostkeyalgs: [email protected],[email protected],[email protected],ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received

You could check if the permissions on the ssh files are rightly set, you can see the right permissions below in my ls command

There maybe is someone who deleted your key from the server.

Or as in the comments someone said, maybe you don't have a matching private key?

---

To create a ssh key if anyone needs that at this stage, this is how you do that:

ssh-keygen -o -b 4096 -t rsa -C [email protected]

that creates a private key and a public key in ~/.ssh/ directory, be careful never to share your private key, that's the id_rsa....notice that ~/.ssh/ has a dot in front of it because it's a hidden directory like here:

$ls -sail .ssh/
total 20
  658 4 drwx------  2 user user 4096 Nov 10 06:05 .
   12 4 drwxr-xr-x 47 user user 4096 Nov 10 06:11 ..
34211 4 -rw-r--r--  1 user user 1487 Nov  1 02:37 authorized_keys
34375 4 -rw-------  1 user user 3434 Nov 10 06:05 id_rsa
34376 4 -rw-r--r--  1 user user  749 Nov 10 06:05 id_rsa.pub
  664 0 -rw-r--r--  1 user user   0 Nov 10 06:04 known_hosts

then to copy the key over to the server:

cat ~/.ssh/id_rsa.pub | ssh -p 30000 something@SERVER 'cat >> .ssh/authorized_keys'

You need to get your public ssh key to the server and if you don't have access to it in physical and can edit sshd_config to allow passwords

 # Change to no to disable tunnelled clear text passwords
 PasswordAuthentication no

while you copy it, you could email it to the system administrator and he can put it on the server.

Comments

[Engineer2021]

might get a better response on superuser.com

[pyccki]

Have you uploaded a public key to authenticate with? Is it the one matching the private key in ~/.ssh ?

[Jim Lewis]

Also, disregard any advice to post all the files under your .ssh directory so we can check them for typos.

[Henke]

I got this problem when the file in the target folder of the target machine was owned by root instead of by the ordinary user (in your case wcyang). I could ssh into the machine without problems, so I knew it's not a classical WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! problem, nor any other problem with the ssh keys. - - - - - - - - - - - - So how did I solve it? - Answer: I changed the owner of the file on the target machine.

[Fazer87]

Can you explain those switches please?