Как исправить запрос не удалось на канале 0

когда я хочу подключиться к моему серверу, как это

ssh -a [email protected] -p 22

он дает мне два сообщения об ошибках:

PTY allocation request failed on channel 0
shell request failed on channel 0

когда я использую параметр -T, первое сообщение об ошибке исчезает. Но как исправить второй? Я не могу подключиться. На другой сервер я могу подключиться без каких-либо проблем.

Я на MAC OS 10.9 Параметр -v показывает мне этот отладочный вывод:

OpenSSH_6.2p2, OSSLShim 0.9.8r 8 Dec 2011
debug1: Reading configuration data /etc/ssh_config
debug1: /etc/ssh_config line 20: Applying options for *
debug1: Connecting to xxx.your-server.de [188.40.3.15] port 22.
debug1: Connection established.
debug1: identity file /Users/xxx/.ssh/id_rsa type -1
debug1: identity file /Users/xxx/.ssh/id_rsa-cert type -1
debug1: identity file /Users/xxx/.ssh/id_dsa type -1
debug1: identity file /Users/xxx/.ssh/id_dsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.2
debug1: Remote protocol version 2.0, remote software version mod_sftp/0.9.8
debug1: no match: mod_sftp/0.9.8
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Server host key: RSA 55:f5:ca:ca:01:45:0f:7b:71:0a:1f:ba:9e:25:17:fb
debug1: Host 'xxx.your-server.de' is known and matches the RSA host key.
debug1: Found key in /Users/xxx/.ssh/known_hosts:1
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
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: Trying private key: /Users/xxx/.ssh/id_rsa
debug1: Trying private key: /Users/xxx/.ssh/id_dsa
debug1: Next authentication method: password

после ввода пароля я получаю это

debug1: Authentication succeeded (password).
Authenticated to xxx.your-server.de ([xxx.xxx.3.15]:22).
debug1: channel 0: new [client-session]
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending env LANG = de_DE.UTF-8
shell request failed on channel 0

Ответ 1

Ошибка передачи PTY на канале 0

В системе существует предел 256 псевдотерминалов. Возможно, у вас есть приложение, которое пропускает псевдотерминалы. Используйте

lsof /dev/pts/*

чтобы узнать, какие процессы имеют открытые псевдотерминалы

запрос оболочки не выполнен на канале 0

Я получал эту ошибку (без ошибки распределения PTY). Оказывается, одно из моих приложений (QtCreator 3.0.?) Просачивало процессы Zombie. Другие пользователи смогли войти в систему, чтобы, возможно, я попадал в мою квоту каждого пользователя (если есть такая вещь). Я обновился до QtCreator 3.3. Пока все хорошо.

Ответ 2

unmount и mount /dev/pts работали для меня

umount /dev/pts

mount devpts /dev/pts -t devpts

Ссылка: http://www.iitk.ac.in/LDP/LDP/lfs/5.0/html/chapter06/proc.html

Ответ 3

Просто добавьте эти строки в ваши /etc/mtab и /etc/fstab и перезагрузите систему.

none    /dev/pts    devpts    defaults    0    0

Ответ 4

У меня была точно такая же ошибка при попытке подключиться через SSH к моему серверу. Как я вижу, вы используете сервер, предоставленный Hetzner, подключающийся к нему через порт 22:

debug1: подключение к порту xxx.your-server.de [188.40.3.15].

Официальная вики/документация от Hetzner гласит:

Протокол для зашифрованной удаленной диагностики для серверов/компьютеров (консолей). Используемый порт SSH - 222.

Таким образом, вы должны подключиться через порт 222:

ssh -p 222 [email protected]server.de

Ответ 5

Я решил аналогичную проблему с одним из наших пользователей, который использовался только для перенаправления портов ssh, поэтому ему не нужно иметь доступ к PTY, и это было запрещено в файле .ssh/authorized_keys:

no-pty ssh-rsa AAA...nUB9 someuser

Итак, когда вы пытались войти в систему этого пользователя, только сообщение

PTY allocation request failed on channel 0

. Поэтому проверьте файл user authorized_keys.

Ответ 6

только что выяснил, в чем была проблема в моем случае (провайдерская страта): у меня была такая же проблема с выводом "запрос оболочки завершился неудачно на канале 0" в конце.

Я должен использовать мастер-пароль с именем веб-домена в качестве логина. (На немецком www.wunschname.de, где wunschname - ваш веб-адрес.)

Вход в систему через ssh с именами пользователей sftp и соответствующими паролями безуспешен. (Хотя scp и sftp работают с этими пользователями sftp!)

Ответ 7

перезагрузка экземпляра из консоли AWS работала для меня. Был сервис, который lsof файловые соединения, которые lsof помог найти.

Ответ 8

Это старый вопрос, но если кто-то попадет сюда, как я...

Это может быть результатом неправильной даты на сервере. Если вы работаете со встроенной системой, это может быть причиной... Так что проверьте свою дату:

$ date

Ответ 9

shell request failed on channel 0

означает, что у вас нет доступа к командной оболочке или удаленным командам, исправьте свое пользовательское разрешение на сервере для доступа к оболочке или если вы просто хотите использовать туннелирование, используйте -N и -T

Ответ 10

Попробуй это:

vi /etc/security/limits.d/20-nproc.conf
*          soft    nproc     4096   # change to 65535 
root       soft    nproc     unlimited

Ответ 11

Перемонтирование /dev/pts работает для меня. вы можете сделать это удаленно через ssh, если вы запускаете ssh таким образом на зараженной машине. ssh не запрашивает tty при запуске таких команд, что позволяет удаленно перемонтировать /dev/pts

ssh user @host - 'mount -o remount, rw/dev/pts'

Ответ 12

Я иногда вижу это, когда раскручиваю виртуальную машину. Наша система автоматизации начинает применять обновления, поэтому в зависимости от времени может произойти обновление критических пакетов.

Upshot - это может произойти, если на целевом компьютере обновляются ssh или другие связанные пакеты.

Ответ 13

Я столкнулся с этой ошибкой при использовании моего git bash. Я смог решить эту проблему, переустановив git для Windows. Подробнее в этом ответе.

Ответ 14

Я также столкнулся с той же проблемой. Просто перезапуск моих серверов решил проблему.

Ответ 15

Если кто-то обнаружит, что читает этот тест, когда он пытается ssh подключить устройство NetGear ReadyNAS, убедитесь, что флажок "только rsync only" un установлен в диалоговом окне для службы ssh в интерфейс администратора.