Вопрос или проблема
Я могу подключиться к удалённому серверу по SSH, используя аутентификацию с открытым ключом и ввод пароля.
Тем не менее, я получаю сообщение о запрете доступа, когда пытаюсь скопировать файл с помощью SCP, используя тот же пароль. Вот мой вывод:
$ scp -v [файл] [пользователь]@[удалённыйсервер.com]:/home/[моя директория]
Выполнение: программа /usr/bin/ssh хост [удалённыйсервер.com], пользователь [пользователь], команда scp -v -t /home/[моя директория]
OpenSSH_5.3p1 Debian-3ubuntu7, OpenSSL 0.9.8k 25 Марта 2009
debug1: Чтение данных конфигурации /home/[моя директория].ssh/config
debug1: Применение параметров для [удалённыйсервер.com]
debug1: Чтение данных конфигурации /etc/ssh/ssh_config
debug1: Применение параметров для *
debug1: Подключение к [удалённыйсервер.com] [[удалённыйсервер.com]] порт 22.
debug1: Соединение установлено.
debug1: файл идентификации /home/[пользователь]/.ssh/aws_corp тип -1
debug1: Удалённая версия протокола 2.0, удалённая версия ПО OpenSSH_5.3p1 Debian-3ubuntu7
debug1: совпадение: OpenSSH_5.3p1 Debian-3ubuntu7 пат OpenSSH*
debug1: Включение режима совместимости для протокола 2.0
debug1: Локальная версия строки SSH-2.0-OpenSSH_5.3p1 Debian-3ubuntu7
debug1: SSH2_MSG_KEXINIT отправлено
debug1: SSH2_MSG_KEXINIT получено
debug1: kex: сервер->клиент aes128-ctr hmac-md5 none
debug1: kex: клиент->сервер aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) отправлено
debug1: ожидание SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT отправлено
debug1: ожидание SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Хост '[удалённыйсервер.com]' известен и совпадает с RSA ключом хоста.
debug1: Найден ключ в /home/[моя директория]/.ssh/known_hosts:12
debug1: ssh_rsa_verify: подпись верна
debug1: SSH2_MSG_NEWKEYS отправлено
debug1: ожидание SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS получено
debug1: SSH2_MSG_SERVICE_REQUEST отправлено
debug1: SSH2_MSG_SERVICE_ACCEPT получено
debug1: Аутентификации, которые могут продолжиться: publickey
debug1: Следующий метод аутентификации: publickey
debug1: Попытка использовать закрытый ключ: /home/[моя директория]/.ssh/aws_corp
debug1: PEM_read_PrivateKey не удалось
debug1: чтение PEM закрытого ключа завершено: тип <неизвестно>
Введите пароль для ключа '/home/[моя директория]/.ssh/aws_corp':
debug1: чтение PEM закрытого ключа завершено: тип RSA
Соединение закрыто [удалённый сервер]
соединение потеряно
Я искал ответы, но не могу найти точно такую же проблему или просто не могу разобраться. В любом случае я буду признателен за любую помощь. Спасибо!
Ваш scp не говорит “доступ запрещён” нигде. Он просто говорит “Соединение закрыто”, что может означать, что на сервере отсутствует команда scp, или она не может быть запущена по какой-то причине.
-
Попробуйте
ssh [пользователь]@[удалённыйсервер.com] scp. Если он говорит “использование: scp …”, то scp в порядке. Если говорит “команда не найдена”, то… -
Если у вас есть административный доступ на удалённом сервере, проверьте журналы там; возможно, даже запустите
sshd -rdddp 222в режиме отладки.
У меня была эта проблема. В моем случае, когда я пытался запустить scp на сервере (в jail chroot), я получал ошибку неизвестного пользователя. Чтобы исправить это:
Обратите внимание на <jail> в коде ниже, это полный путь к файловой системе chrooted jail, которую вы создали для входа в ssh сессии.
sudo cp -vf /usr/bin/strace <jail>/bin
ldd <jail>/bin/strace
sudo cp -vf ...
Скопируйте каждую из отсутствующих библиотек с основной системы в директорию <jail>/lib64
В сеансе chroot jail выполните:
strace scp
Скопируйте библиотеку/библиотеки, которые не удалось найти согласно выводу, в директорию /lib64, используя опцию -vf. В моем случае, мне было необходимо скопировать libnss_compat.so.2
После этого scp в chrooted jail заработал!
У меня была такая же проблема, и я заставил его работать, используя опцию scp -O (буква ‘o’)
scp -O пользователь@удалённый:/<путь/файл> .
Опция -O: “Использовать оригинальный протокол SCP для передачи файлов вместо
протокола SFTP.” На некоторых sshd серверах использование sftp может быть запрещено.
С включённым подробным выводом (scp -v) вы увидите, какой протокол используется для копирования:
debug1: Sending subsystem: sftp (по умолчанию)
или
debug1: Sending command: scp -v -f /<путь>/<файл> (с -O)
Надеюсь, это поможет.
Ответ или решение
Отвечая на вопрос о том, почему вы можете подключаться к удаленному серверу через SSH, но сталкиваетесь с трудностями при использовании SCP, стоит рассмотреть несколько важных аспектов, которые могут оказать влияние на эту ситуацию.
Причины, по которым SCP может не работать:
-
Отсутствие команды SCP на сервере:
Убедитесь, что на удаленном сервере установлена команда SCP. Это можно проверить, подключившись к серверу через SSH и выполнив следующую команду:which scpЕсли команда не найдена, возможно, вам потребуется установить ее или использовать другой метод передачи файлов (например, SFTP).
-
Проблемы с библиотеками в окружении chroot:
Если вы работаете в окружении chroot, это может вызвать проблемы, так как не все необходимые библиотеки и исполняемые файлы могут быть доступны в этом окружении.
Для диагностики можно использоватьstrace:sudo cp -vf /usr/bin/strace <jail>/bin ldd <jail>/bin/straceЭто позволит отслеживать, какие библиотеки и файлы требуются и какие отсутствуют.
-
Использование протокола SFTP вместо SCP:
Ваша версия SCP может по умолчанию использовать протокол SFTP. Некоторые SSH-серверы не поддерживают SFTP (или не настроены на это). Попробуйте использовать опцию-O, чтобы заставить SCP использовать оригинальный протокол копирования файлов, вместо SFTP:scp -O [user]@[remoteserver.com]:/[path/to/file] .Это вызовет SCP использовать старый протокол передавая информации, что может помочь решить проблему.
-
Проблемы с аутентификацией:
В выводе, который вы предоставили, вы видите сообщениеConnection closed by [remote server]. Это может указывать на проблемы с аутентификацией, особенно если вы используете ключи RSA, прошедшие через естество проверки. Убедитесь, что ваш SSH-ключ правильно настроен и добавлен в файлauthorized_keysна сервере:cat /home/[user]/.ssh/aws_corp.pub | ssh [user]@[remoteserver.com] 'cat >> .ssh/authorized_keys' -
Проверка прав доступа:
Убедитесь, что у вас есть соответствующие права доступа на целевой каталог на удаленном сервере. Вашим пользователям могут не хватать разрешений для записи в указанный каталог. Проверьте это, выполнив:ls -ld /home/[my dir]
Рекомендации по диагностике:
-
Проверьте логи на сервере SSH:
Если у вас есть доступ к логам на удаленном сервере, это может помочь в диагностике проблемы. Логи могут находиться в файле/var/log/auth.logили/var/log/secure. -
Навигируйте настройки сервера:
Если вы администратор, вы можете временно запустить SSH-сервер в режиме отладки:sudo /usr/sbin/sshd -d -
Работа с конфигурациями:
Убедитесь в правильности настроек SSH на сервере, находящихся в файле/etc/ssh/sshd_config, включая параметрыSubsystemи разрешения для протокола SCP.
Следуя указанным рекомендациям, вы сможете определить и, возможно, устранить причину, по которой SCP не работает, несмотря на успешные подключения по SSH.