Попытка скопировать файлы с serverB на serverA и получить следующую ошибку:
root@server:~# scp /root/test.txt root@111.111.111.111:/home/somefolder/
Permission denied (publickey,gssapi-keyex,gssapi-with-mic).
lost connection
На serverA я создал пару открытого и закрытого ключей без парольной фразы. На serverB я добавил открытый ключ в файл .ssh / authorized_keys. И папка, и файл принадлежат пользователю root.
Изначально я пробовал это с парольной фразой ... поскольку она не работала, я создал другой ключ без парольной фразы. Оба дают одинаковые результаты.
Это не проблема брандмауэра. serverA - это centos. serverB - это убунту.
Оказывается, мне нужно было указать идентификатор в команде scp примерно так:
scp -rp -i /root/.ssh/server /home/user-data/* root@111.111.111.111:/home/user-data
где '/root/.ssh/server' - это расположение используемого закрытого ключа. Разрешения и права собственности также должны быть правильными.
Я столкнулся с той же проблемой. Надеюсь, это сработает для вас.
scp -rp -i yourfile.pem ~/local_directory username@instance_url:directory
Разрешение также должно быть правильным, чтобы эта работа работала.
Запустите scp в подробном режиме (-vvv) и посмотрите, сможете ли вы определить проблему там. Возможно, права доступа к вашему файлу .ssh / authorized_key в месте назначения (или даже источнике) слишком открыты.
Проблема, с которой я столкнулся, заключалась в том, что учетная запись пользователя была заблокирована. В поле пароля / etc / shadow был восклицательный знак (восклицательный знак), что означало, что учетная запись заблокирована. Чтобы это исправить, мне пришлось
sudo vi /etc/shadow
И измените "!!" в '*'. В качестве альтернативы вы можете установить пароль для учетной записи
sudo passwd newacct
Смотрите также Что означает * в файле passwd
Что ты видишь в /var/log/secure файл? Наверное .ssh/* имеют плохие разрешения.
Так что вы можете попробовать бежать ssh -v команду, чтобы узнать, в чем проблема.