Изменить стандартные флаги команды SCP в Linux
Я пытаюсь переместить файл с виртуальной машины (Ubuntu 18.04) в моей локальной системе на удаленный сервер, используя очень простые scp команда. Эта проблема присутствует только на одном конкретном сервере, другие работают нормально, поэтому это не универсальная вещь.
scp <file name> <user>@<complete_hostname>:~/
Но эта команда не выходит за рамки аутентификации, которая прошла успешно.
То же самое происходит, когда я использую FileZilla.
ИТ-команда посоветовала мне использовать "WinSCP", который отлично работает.
журнал отладки scp
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Trying private key: /home/username/.ssh/id_dsa
debug1: Trying private key: /home/username/.ssh/id_ecdsa
debug1: Next authentication method: password
'user'@'full hostname's password:
debug1: Authentication succeeded (password).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending env LANG = C
debug1: Sending env LC_ALL = C
debug1: Sending command: scp -v -t ~/
После этого прогресса нет, FileZilla останавливается через 20 секунд аналогичным образом. в то время как WinSCP работает нормально.
Что может вызвать scp чтобы повесить, поскольку я использую это в некоторых из моих сценариев, эта проблема с одним конкретным сервером сделала мои сценарии непригодными для них, это относится и к методам SFTP.
ИТ-команда посоветовала мне не использовать флаги -d а также -t при вводе команды то же самое отображается в журнале отладки и не поддерживается удаленным сервером. Могут ли они быть удалены? Я не выдавал их явно с помощью команды.
Изменить 2:
SCP Log: (from local machine, Ubuntu 18.04)
==========
debug1: Next authentication method: publickey
debug1: Offering public key:
RSA SHA256:<key> /home/username/.ssh/id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 279
debug1: Authentication succeeded (publickey).
Authenticated to 'HOSTNAME' ([10.6.26.145]:22).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: pledge: network
debug1: Sending environment.
debug1: Sending env LANG = en_IN
debug1: Sending command: scp -v -r -d -t ~/received/
2 ответа
Это оказывается брандмауэр, блокирующий передачу. Причиной является разрешение на доступ к файлу моей оболочки по умолчанию . * Rc. .cshrc в этом случае.
Моя оболочка по умолчанию - csh, и разрешение File было
-rwxr-s---
Меняя их на
-rw-r-----
решил проблему.
Спасибо всем за помощь.
ИТ-команда посоветовала мне не использовать флаги
-dа также-tпри вводе команды то же самое отображается в журнале отладки и не поддерживается удаленным сервером. Могут ли они быть удалены? Я не выдавал их явно с помощью команды.
-t - Это полная чушь. Протокол SCP не может работать без -t флаг. См. Как работает передача файлов SCP (протокол защищенного копирования)?
-d - Используется, когда вы указываете более одного источника. Он указывает серверу, что "целью должен быть каталог".
В обоих случаях я сомневаюсь, что сервер не поддерживает ни один из них. Так как это Ubuntu, он работает с OpenSSH с уверенностью 99,9%. И OpenSSH поддерживает эти флаги с тех пор, как он существует. Увидеть scp.c с 1999 года.
Я уверен, что совет, который вы получили, - это просто чепуха. "Команда ИТ", вероятно, просто не нашла эти переключатели в scp man-страницу и получил легкий способ действительно помочь вам. Но эти флаги являются внутренними флагами, используемыми для связи между scp как "клиент" и scp как "сервер". Они не задокументированы по назначению.
Также FileZilla даже не поддерживает протокол SCP. Что только способствует вышесказанному - Ваша проблема не имеет никакого отношения к " scp флаги ".