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

Главная » Вопросы и ответы » Системное администрирование и сети

Могу подключиться через SSH, но не через SFTP? Код завершения 127

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

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

К сожалению, я не могу подключиться к моему VPS через sftp:

Это мой sshd_config:

# Файл конфигурации, сгенерированный пакетом
# См. man-страницу sshd_config(5) для подробностей

# Какие порты, IP и протоколы мы слушаем
Port 22
# Используйте эти параметры, чтобы ограничить интерфейсы/протоколы, к которым sshd будет привязываться
#ListenAddress ::
#ListenAddress 0.0.0.0
Protocol 2
# HostKeys для версии протокола 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
# Разделение привилегий включено для безопасности
UsePrivilegeSeparation yes

# Время жизни и размер временного ключа сервера версии 1
KeyRegenerationInterval 3600
ServerKeyBits 768

# Логирование
SyslogFacility AUTH
LogLevel INFO

# Аутентификация:
LoginGraceTime 120
PermitRootLogin no
StrictModes yes

RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile  %h/.ssh/authorized_keys

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

# Чтобы разрешить пустые пароли, измените на yes (НЕ РЕКОМЕНДУЕТСЯ)
PermitEmptyPasswords no

# Измените на yes, чтобы включить challenge-response пароли (осторожно с
# некоторыми модулями PAM и потоками)
ChallengeResponseAuthentication no

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

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

# Опции GSSAPI
GSSAPIAuthentication no
#GSSAPICleanupCredentials yes

X11Forwarding no
X11DisplayOffset 10
PrintMotd yes
PrintLastLog yes
TCPKeepAlive yes
#UseLogin no
UseDNS yes

#MaxStartups 10:30:60
Banner no

# Разрешить настройку переменных окружения
AcceptEnv LANG LC_*

#Subsystem sftp /usr/lib/openssh/sftp-server
Subsystem sftp /usr/lib/openssh/sftp-server
UsePAM yes

AllowUsers [email protected] [email protected] [email protected]

Match User user
    PasswordAuthentication yes

Подробный вывод при попытке подключения:

me:~ user$ sftp -v [email protected]
OpenSSH_6.9p1, LibreSSL 2.1.8
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 21: Applying options for *
debug1: Connecting to example.org [xx.xxx.xx.xx] port 22.
debug1: Connection established.
debug1: identity file /Users/user/.ssh/id_rsa type 1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/user/.ssh/id_rsa-cert type -1
debug1: identity file /Users/user/.ssh/id_dsa type 1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/user/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/user/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/user/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/user/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/user/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.9
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6.1
debug1: match: OpenSSH_6.6.1 pat OpenSSH_6.6.1* compat 0x04000000
debug1: Authenticating to example.org:22 as 'user'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client [email protected] <implicit> none
debug1: kex: client->server [email protected] <implicit> none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ssh-rsa SHA256:/RUeBQCA1w0nHUWT2OgLDhy7/bNQy4nWH2IVZatMLw4
debug1: Host 'example.org' is known and matches the RSA host key.
debug1: Found key in /Users/user/.ssh/known_hosts:4
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /Users/user/.ssh/id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 279
debug1: Authentication succeeded (publickey).
Authenticated to example.org ([xx.xxx.xx.xx]:22).
debug1: channel 0: new [client-session]
debug1: Requesting [email protected]
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending env LANG = de_DE.UTF-8
debug1: Sending subsystem: sftp
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: client_input_channel_req: channel 0 rtype [email protected] reply 0
debug1: channel 0: free: client-session, nchannels 1
debug1: fd 0 clearing O_NONBLOCK
Transferred: sent 3332, received 2796 bytes, in 0.2 seconds
Bytes per second: sent 18890.9, received 15852.0
debug1: Exit status 127
Connection closed

Есть идеи, как решить эту проблему?

Скорее всего, это означает, что /usr/lib/openssh/sftp-server не существует.

Убедитесь, что директива Subsystem указывает на существующий путь:

Subsystem sftp /usr/lib/openssh/sftp-server

Или на самом деле, в настоящее время вы обычно используете internal-sftp вместо:

Subsystem sftp internal-sftp

См. Разница между OpenSSH internal-sftp и sftp-server.

Для меня это была ошибка конфигурации клиента. Код 127 означает, что команда не найдена. Я случайно изменил конфигурацию WinSCP на использование “/bin/sftp-server” вместо “default”. Проверьте конфигурацию вашего клиента.

У меня полный путь к sftp-server был в файле конфигурации, но не работал. Я добавил “Subsystem sftp internal-sftp”, и все заработало. Спасибо!

Subsystem sftp /usr/lib/openssh/sftp-server <– не работает

Subsystem sftp internal-sftp <– работает

Это сработало для меня в SLES 15. Сопоставил ошибку: debug1: Exit status 127

# grep -i sftp /etc/ssh/sshd_config
Subsystem sftp internal-sftp

В то время как для старой версии ОС, т.е. SLES 12, использовал ниже

# grep -i sftp /etc/ssh/sshd_config
Subsystem  sftp /usr/lib/ssh/sftp-server

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

Ошибка с кодом выхода 127 в процессе использования SFTP через SSH часто связана с проблемой в конфигурации самого сервера SSH или ошибкой в указании пути к серверной подсистеме SFTP. Давайте рассмотрим теоретические аспекты, примеры из практики и шаги по исправлению данной проблемы.

Теория

SFTP (Secure File Transfer Protocol) — это протокол, работающий поверх SSH, который позволяет безопасно передавать файлы между хостами. Конфигурация SFTP обычно настроена в файле sshd_config. Чтобы SFTP корректно функционировал, необходимо, чтобы путь к подсистеме SFTP был правильно указан в директиве Subsystem. Ошибка с кодом 127, как правило, указывает на то, что команда или файл, к которому осуществляется попытка доступа, не найден.

Пример

В предоставленном вами выводе конфигурационного файла присутствует следующая строка:

Subsystem sftp /usr/lib/openssh/sftp-server

Когда указанный путь неправильный или соответствующий файл отсутствует, возникает ошибка с кодом 127. Современные версии OpenSSH позволяют использовать встроенный модуль internal-sftp, который устраняет необходимость указывать путь к внешнему бинарному файлу.

Применение

  1. Проверка пути к SFTP-серверу:

    • Убедитесь, что путь /usr/lib/openssh/sftp-server действительно существует на вашем сервере. Для этого выполните команду ls в соответствующей директории.

  2. Изменение на внутренний модуль:

    • Если путь попросту отсутствует или вы хотите упростить конфигурацию, замените текущую строку на использование внутреннего модуля:

      Subsystem sftp internal-sftp

  3. Перезагрузка службы SSH:

    • После внесения изменений, необходимо перезагрузить службу SSH для применения новой конфигурации. Это можно сделать с помощью команды:

      sudo systemctl restart sshd
    • Или, в случае использования другого дистрибутива, воспользуйтесь аналогичной командой для перезапуска службы.

  4. Проверка клиентской конфигурации:

    • Убедитесь, что клиентская программа (например, WinSCP) не настроена на использование некорректного серверного пути.

Применение данных шагов должно устранить проблему, связанную с ошибкой SFTP. Эти действия направлены на обеспечение корректности конфигурации и совместимости используемого программного обеспечения.

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

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

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