Посещая наш сайт, вы соглашаетесь с нашей политикой конфиденциальности в отношении файлов cookie, статистики отслеживания и т. д.

Главная » Вопросы и ответы » Компьютеры и программы

sftp-соединение с использованием следующей команды: sftp user@host, завершилось с сообщением: запрос подсистемы завершился с ошибкой на канале 0 Соединение закрыто.

На чтение 11 мин Опубликовано
Содержание
  1. Вопрос или проблема
  2. Ответ или решение
  3. Причины проблемы
  4. Решение
  5. Тестирование

Вопрос или проблема

Я пытаюсь установить соединение SFTP с помощью следующей команды: sftp user@host, но это не удается, и выводится сообщение: запрос подсистемы не удался на канале 0. Соединение SSH user@host с тем же хостом выполняется успешно.

Я прикладываю полный файл конфигурации sshd-config, который я использую:

    #       $OpenBSD: sshd_config,v 1.104 2021/07/02 05:11:21 dtucker Exp $

# Это файл конфигурации сервера sshd для всей системы. См.
# sshd_config(5) для получения дополнительной информации.

# Этот sshd был скомпилирован с PATH=/usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin

# Стратегия, используемая для параметров в конфигурации по умолчанию sshd_config, поставляемой с
# OpenSSH, заключается в том, чтобы указывать параметры с их значением по умолчанию, где
# это возможно, но оставлять их закомментированными. Раскомментированные параметры переопределяют
# значение по умолчанию.

# Чтобы изменить конфигурацию sshd на уровне системы, создайте файл с расширением *.conf в
# /etc/ssh/sshd_config.d/, который будет автоматически включен ниже
Include /etc/ssh/sshd_config.d/*.conf

# Если вы хотите изменить порт на системе SELinux, вам нужно сообщить
# SELinux об этом изменении.
# semanage port -a -t ssh_port_t -p tcp #PORTNUMBER
#
#Port 22
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::

HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_ecdsa_key
#HostKey /etc/ssh/ssh_host_ed25519_key
KexAlgorithms +diffie-hellman-group1-sha1
HostKeyAlgorithms +ssh-dss
PubkeyAcceptedAlgorithms +ssh-dss
Ciphers +aes128-cbc

HostKey /etc/ssh/ssh_host_dsa_key

# Шифры и ключи
#RekeyLimit default none

# Ведение журнала
#SyslogFacility AUTH
#LogLevel INFO

# Аутентификация:

#LoginGraceTime 2m
#PermitRootLogin prohibit-password
#StrictModes yes
#MaxAuthTries 6
MaxSessions 50

#PubkeyAuthentication yes

# По умолчанию проверяются оба .ssh/authorized_keys и .ssh/authorized_keys2,
# но это переопределяется, поэтому установки будут проверять только .ssh/authorized_keys
AuthorizedKeysFile      .ssh/authorized_keys

#AuthorizedPrincipalsFile none

#AuthorizedKeysCommand none
#AuthorizedKeysCommandUser nobody

# Для этого вам также понадобятся ключи хоста в /etc/ssh/ssh_known_hosts
#HostbasedAuthentication no
# Измените на yes, если вы не доверяете ~/.ssh/known_hosts для
# HostbasedAuthentication
#IgnoreUserKnownHosts no
# Не читать файлы пользователя ~/.rhosts и ~/.shosts
#IgnoreRhosts yes

# Чтобы отключить туннелирование паролей в открытом виде, измените на no здесь!
#PasswordAuthentication yes
#PermitEmptyPasswords no

# Измените на no, чтобы отключить пароли s/key
#KbdInteractiveAuthentication yes

# Опции Kerberos
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#KerberosGetAFSToken no
#KerberosUseKuserok yes

# Опции GSSAPI
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes
#GSSAPIStrictAcceptorCheck yes
#GSSAPIKeyExchange no
#GSSAPIEnablek5users no

# Установите это значение на 'yes', чтобы включить аутентификацию PAM, обработку учетных записей
# и обработку сессий. Если это включено, аутентификация PAM будет
# разрешена через KbdInteractiveAuthentication и
# PasswordAuthentication. В зависимости от вашей конфигурации PAM,
# аутентификация PAM через KbdInteractiveAuthentication может обойти
# установку "PermitRootLogin without-password".
# Если вы хотите, чтобы проверки учетных записей и сессий PAM выполнялись без
# аутентификации PAM, включите это, но установите PasswordAuthentication
# и KbdInteractiveAuthentication на 'no'.
# ПРЕДУПРЕЖДЕНИЕ: 'UsePAM no' не поддерживается в RHEL и может вызвать множество
# проблем.
#UsePAM no

#AllowAgentForwarding yes
#AllowTcpForwarding yes
#GatewayPorts no
#X11Forwarding no
#X11DisplayOffset 10
#X11UseLocalhost yes
#PermitTTY yes
#PrintMotd yes
#PrintLastLog yes
#TCPKeepAlive yes
#PermitUserEnvironment no
#Compression delayed
#ClientAliveInterval 0
#ClientAliveCountMax 3
#UseDNS no
#PidFile /var/run/sshd.pid
#PermitTunnel no
#ChrootDirectory none
#VersionAddendum none

# нет пути по умолчанию для баннера
#Banner none

# переопределить значение по умолчанию для подсистем

# Пример переопределения настроек на уровне пользователя
#Match User anoncvs
#       X11Forwarding no
#       AllowTcpForwarding no
#       PermitTTY no
#       ForceCommand cvs server
Subsystem sftp internal-sftp
MaxStartups 300
Match User amssftp
ChrootDirectory /ams
ForceCommand internal-sftp -u 0002

Не могли бы вы помочь мне разобраться с этой проблемой?

Я прикладываю вывод команды с опцией -vv:

 [root@localhost ~]#  sftp -vv [email protected]
    OpenSSH_8.7p1, OpenSSL 3.0.7 1 Nov 2022
    debug1: Чтение данных конфигурации /etc/ssh/ssh_config
    debug1: Чтение данных конфигурации /etc/ssh/ssh_config.d/50-redhat.conf
    debug2: проверка совпадения для 'final all' хост 10.85.220.158, изначально 10.85.220.158
    debug2: совпадение не найдено
    debug1: Чтение данных конфигурации /etc/crypto-policies/back-ends/openssh.config
    debug1: запрос конфигурации финального совпадения
    debug2: resolve_canonicalize: имя хоста 10.85.220.158 является адресом
    debug1: повторный парсинг конфигурации
    debug1: Чтение данных конфигурации /etc/ssh/ssh_config
    debug1: Чтение данных конфигурации /etc/ssh/ssh_config.d/50-redhat.conf
    debug2: проверка совпадения для 'final all' хост 10.85.220.158, изначально 10.85.220.158
    debug2: совпадение найдено
    debug1: Чтение данных конфигурации /etc/crypto-policies/back-ends/openssh.config
    debug1: Подключение к 10.85.220.158 [10.85.220.158] порт 22.
    debug1: Соединение установлено.
    debug1: файл идентификации /root/.ssh/id_rsa типа -1
    debug1: файл идентификации /root/.ssh/id_rsa-cert типа -1
    debug1: файл идентификации /root/.ssh/id_dsa типа -1
    debug1: файл идентификации /root/.ssh/id_dsa-cert типа -1
    debug1: файл идентификации /root/.ssh/id_ecdsa типа -1
    debug1: файл идентификации /root/.ssh/id_ecdsa-cert типа -1
    debug1: файл идентификации /root/.ssh/id_ecdsa_sk типа -1
    debug1: файл идентификации /root/.ssh/id_ecdsa_sk-cert типа -1
    debug1: файл идентификации /root/.ssh/id_ed25519 типа -1
    debug1: файл идентификации /root/.ssh/id_ed25519-cert типа -1
    debug1: файл идентификации /root/.ssh/id_ed25519_sk типа -1
    debug1: файл идентификации /root/.ssh/id_ed25519_sk-cert типа -1
    debug1: файл идентификации /root/.ssh/id_xmss типа -1
    debug1: файл идентификации /root/.ssh/id_xmss-cert типа -1
    debug1: Строка версии локального SSH-2.0-OpenSSH_8.7
    debug1: Удаленная версия протокола 2.0, удаленная версия ПО OpenSSH_3.5p1
    debug1: compat_banner: совпадение: OpenSSH_3.5p1 pat OpenSSH_3.* compat 0x01000002
    debug2: fd 3 установка O_NONBLOCK
    debug1: Аутентификация к 10.85.220.158:22 как 'admin'
    debug1: load_hostkeys: fopen /root/.ssh/known_hosts2: Файл или каталог не существует
    debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts: Файл или каталог не существует
    debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts2: Файл или каталог не существует
    debug1: SSH2_MSG_KEXINIT отправлено
    debug1: SSH2_MSG_KEXINIT получено
    debug2: локальное предложение KEXINIT
    debug2: KEX алгоритмы: curve25519-sha256,[email protected], ecdh-sha2-nistp256, ecdh-sha2-nistp384, ecdh-sha2-nistp521, diffie-hellman-group-exchange-sha256, diffie-hellman-group16-sha512, diffie-hellman-group18-sha512, diffie-hellman-group14-sha256, diffie-hellman-group1-sha1, ext-info-c
    debug2: алгоритмы ключей хоста: [email protected],[email protected],[email protected],rsa-sha2-512,rsa-sha2-256,ssh-rsa,[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],ssh-ed25519,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,[email protected],[email protected],ssh-dss
    debug2: шифры ctos: [email protected],aes128-ctr,aes192-ctr,aes256-ctr,[email protected],[email protected],aes128-cbc
    debug2: шифры stoc: [email protected],aes128-ctr,aes192-ctr,aes256-ctr,[email protected],[email protected],aes128-cbc
    debug2: MACs ctos: [email protected],[email protected],[email protected],[email protected],hmac-sha2-256,hmac-sha1,[email protected],hmac-sha2-512
    debug2: MACs stoc: [email protected],[email protected],[email protected],[email protected],hmac-sha2-256,hmac-sha1,[email protected],hmac-sha2-512
    debug2: сжатие ctos: none,[email protected],zlib
    debug2: сжатие stoc: none,[email protected],zlib
    debug2: языки ctos:
    debug2: языки stoc:
    debug2: first_kex_follows 0
    debug2: reserved 0
    debug2: предложение KEXINIT сервера-равному
    debug2: KEX алгоритмы: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
    debug2: алгоритмы ключей хоста: ssh-rsa,ssh-dss
    debug2: шифры ctos: aes128-cbc,3des-cbc,blowfish-cbc,arcfour,aes192-cbc,aes256-cbc,[email protected]
    debug2: шифры stoc: aes128-cbc,3des-cbc,blowfish-cbc,arcfour,aes192-cbc,aes256-cbc,[email protected]
    debug2: MACs ctos: hmac-sha1,hmac-sha1-96,hmac-md5,hmac-md5-96
    debug2: MACs stoc: hmac-sha1,hmac-sha1-96,hmac-md5,hmac-md5-96
    debug2: сжатие ctos: none
    debug2: сжатие stoc: none
    debug2: языки ctos:
    debug2: языки stoc:
    debug2: first_kex_follows 0
    debug2: reserved 0
    debug1: kex: алгоритм: diffie-hellman-group1-sha1
    debug1: kex: алгоритм ключа хоста: ssh-rsa
    debug1: kex: шифр сервера->клиент: aes128-cbc MAC: hmac-sha1 сжатие: none
    debug1: kex: шифр клиент->сервера: aes128-cbc MAC: hmac-sha1 сжатие: none
    debug1: kex: diffie-hellman-group1-sha1 need=20 dh_need=20
    debug1: kex: diffie-hellman-group1-sha1 need=20 dh_need=20
    debug1: ожидает SSH2_MSG_KEX_ECDH_REPLY
    debug1: SSH2_MSG_KEX_ECDH_REPLY получено
    debug1: Ключ хоста сервера: ssh-rsa SHA256:ZlIlk1cHA8WnjeJxK+DrLleDOiTlfb1cOMypierJ1Ww
    debug1: load_hostkeys: fopen /root/.ssh/known_hosts2: Файл или каталог не существует
    debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts: Файл или каталог не существует
    debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts2: Файл или каталог не существует
    debug1: Хост '10.85.220.158' известен и соответствует ключу RSA хоста.
    debug1: Ключ найден в /root/.ssh/known_hosts:5
    debug2: bits set: 500/1024
    debug2: set_newkeys: режим 1
    debug1: переинициализация через 4294967296 блоков
    debug1: SSH2_MSG_NEWKEYS отправлено
    debug1: ожидает SSH2_MSG_NEWKEYS
    debug1: SSH2_MSG_NEWKEYS получено
    debug2: set_newkeys: режим 0
    debug1: переинициализация через 4294967296 блоков
    debug1: Попытка ключа: /root/.ssh/id_rsa
    debug1: Попытка ключа: /root/.ssh/id_dsa
    debug1: Попытка ключа: /root/.ssh/id_ecdsa
    debug1: Попытка ключа: /root/.ssh/id_ecdsa_sk
    debug1: Попытка ключа: /root/.ssh/id_ed25519
    debug1: Попытка ключа: /root/.ssh/id_ed25519_sk
    debug1: Попытка ключа: /root/.ssh/id_xmss
    debug2: pubkey_prepare: готово
    debug2: service_accept: ssh-userauth
    debug1: SSH2_MSG_SERVICE_ACCEPT получено
    debug1: Аутентификации, которые могут продолжаться: password
    debug1: Следующий метод аутентификации: password
    [email protected]'s password:
    debug2: мы отправили пакет пароля, ждем ответа
    Аутентификация к 10.85.220.158 ([10.85.220.158]:22) с использованием "password".
    debug1: pkcs11_del_provider: вызвано, provider_id = (null)
    debug1: канал 0: новый [client-session]
    debug2: канал 0: отправить открыть
    debug1: Вход в интерактивную сессию.
    debug1: pledge: файловая система полная
    debug2: channel_input_open_confirmation: канал 0: начало обратного вызова
    debug2: fd 3 установка TCP_NODELAY
    debug2: client_session2_setup: id 0
    debug1: Отправка подсистемы: sftp
    debug2: канал 0: запрос подтверждения подсистемы 1
    debug2: channel_input_open_confirmation: канал 0: обратный вызов завершен
    debug2: канал 0: открыть подтвердить rwindow 0 rmax 32768
    debug2: channel_input_status_confirm: тип 100 id 0
    запрос подсистемы не удался на канале 0
    Соединение закрыто
    Соединение закрыто.

Ответ или решение

Проблема, с которой вы столкнулись — "subsystem request failed on channel 0" — обычно возникает в результате неправильной конфигурации SFTP-демона (sshd) на сервере. В вашем случае SFTP успешен через SSH, но не может быть инициализирован в режиме SFTP. Вы уже предоставили содержимое файла конфигурации sshd_config, и на его основе давайте рассмотрим возможные причины и решения.

Причины проблемы

  1. Неверно настроенный Subsystem: В вашем конфигурационном файле sshd_config вы указали Subsystem sftp internal-sftp, однако также у вас есть блок Match User amssftp, который использует ForceCommand internal-sftp. Если подключаетесь под другим пользователем (не amssftp), может возникнуть эта ошибка.

  2. Отсутствие необходимых прав доступа к Chroot: Если пользователь amssftp используется с Chroot, убедитесь, что структура директорий и права на них настроены правильно.

  3. Старые версии OpenSSH: Ваша версия OpenSSH (3.5p1) устарела, обновление OpenSSH может помочь избежать проблем с поддержкой новых алгоритмов.

  4. Неправильные настройки Chroot: Ваша конфигурация имеет ChrootDirectory /ams. Убедитесь, что:

    • /ams — это директория, принадлежащая пользователю root (chown root:root /ams).
    • Директория имеет правильные права (0x700 для корневой директории).

Решение

  1. Проверьте конфигурацию Subsystem:

    • Убедитесь, что у вас правильные настройки для использования SFTP. Вам нужно либо убрать специфические настройки для Match User amssftp, если они не нужны, либо удостовериться, что вы используете правильного пользователя при подключении.

  2. Проверьте права на директории:

    • Выполните следующие команды, чтобы указать корректные права: 
      sudo chown root:root /ams
sudo chmod 755 /ams

  3. Настройка sshd_config:

    • Если не требуется использование Chroot, вы можете закомментировать или удалить строки, касающиеся ChrootDirectory и ForceCommand.

  4. Перезапустите службу sshd после внесения изменений в конфигурацию:

    sudo systemctl restart sshd

  5. Обновите OpenSSH:

    • Если возможно, обновите OpenSSH на сервере до более поздней версии, например, 7.0 или выше, что может решить некоторые проблемы с совместимостью.

Тестирование

После реализации вышеуказанных шагов, попробуйте снова подключиться с помощью sftp:

sftp user@host

Если ошибка всё еще присутствует, запустите sftp с опцией -vv для дополнительной отладки:

sftp -vv user@host

Это даст вам больше информации о том, на каком этапе происходит сбой.

Если проблемы продолжатся, рассмотрите возможность проверки логов сервера (/var/log/auth.log или /var/log/secure в зависимости от вашей ОС) для получения дополнительных подсказок.

linux sftp
Оцените материал
Добавить комментарий

Капча загружается...

© 2024 IZ6.RU
*В материалах сайта упоминаются социальные сети Фейсбук / Инстаграм, принадлежащие Meta Platforms Inc., деятельность которой запрещена на территории РФ в части реализации данных социальных сетей на основании осуществления ею экстремистской деятельности