12

Trying to copy files over from serverB to serverA and get the following error:

root@server:~# scp /root/test.txt root@111.111.111.111:/home/somefolder/
Permission denied (publickey,gssapi-keyex,gssapi-with-mic).
lost connection

On serverA I created a public/private key pair with no passphrase. On serverB I added the public key to the .ssh/authorized_keys file. Both the folder and file is owned by root.

I originally tried this with a passphrase... since it was not working I created another key without a passphrase. Both are giving the same results.

This is not a firewall issue. serverA is centos. serverB is ubuntu.

user756659
  • 273
  • 1
  • 2
  • 10

5 Answers5

10

I was facing the same problem. Hope this will work for you.

scp -rp -i yourfile.pem ~/local_directory username@instance_url:directory

Permission should also be correct to make this work.

iCPSoni
  • 101
  • 1
  • 3
6

Run scp with verbose mode (-vvv) and see if you can identify the problem there. It could be the permissions on your .ssh/authorized_key file on the destination (or even the source) are too open.

  • Verbose mode helped me realize that I'd copied the command from Windows and left the file separator as a backslash – crowne Jun 20 '22 at 08:07
5

Turns out I needed to specify the identity in the scp command something like so :

scp -rp -i /root/.ssh/server /home/user-data/* root@111.111.111.111:/home/user-data

where '/root/.ssh/server' is the location of the private key to be used. Permissions and ownership should be correct for it as well.

RalfFriedl
  • 3,108
  • 4
  • 13
  • 17
user756659
  • 273
  • 1
  • 2
  • 10
1

The problem I ran into with this was the user account was locked. A bang (exclamation point character) was in the /etc/shadow password field which meant the account was locked. To fix it, I had to

sudo vi /etc/shadow

And change the '!!' to '*'. Alternatively, you could set a password for the account

sudo passwd newacct

See also What does * mean in passwd file

PatS
  • 113
  • 5
0

What do you see in /var/log/secure file? Probably .ssh/* have bad permissions.

So you can try to run ssh -v command to see what's the problem.

kenorb
  • 6,499
  • 2
  • 46
  • 54
fyarci
  • 114