Не вдалося виправити запит на каналі 0

Коли я хочу підключитися до свого сервера таким чином

ssh -a username@my-server.de -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

Помилка запиту на розподіл PTY на каналі 0

У системі обмежено 256 псевдотерміналів. Можливо, у вас є програма, яка витікає з псевдотерміналів. Використовуйте

lsof /dev/pts/*

щоб побачити, які процеси мають відкриті псевдотермінали

Помилка запиту оболонки на каналі 0

Я отримував цю помилку (без помилки розподілу PTY). Виявляється, в одному з моїх додатків (QtCreator 3.0.?) Протікали процеси зомбі. Інші користувачі змогли ввійти, тому я міг би досягти своєї квоти на кожен процес користувача (якщо така ситуація є). Я оновився до QtCreator 3.3. Все йде нормально.

демонтаж і кріплення /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

У мене була точно така ж помилка при спробі підключитися через ssh до мого сервера. Як я бачу, ви використовуєте сервер, наданий Hetzner, підключаючись до нього через порт 22:

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

Офіційна вікі / документація від Гецнера говорить:

Протокол шифрованої віддаленої діагностики для серверів / комп’ютерів (консолей). Використовуваний порт SSH - 222.

Отже, вам доведеться підключитися через порт 222:

ssh -p 222 username@my-server.de

Я вирішив подібну проблему з одним із наших користувачів, який використовувався лише для переадресації портів ssh, тому йому не потрібно мати доступ до PTY, і це було заборонено у файлі .ssh / санкціонованих_ключей:

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

Отже, коли ви намагалися увійти до цього користувача, лише повідомлення

PTY allocation request failed on channel 0

було повернуто. Тож перевірте файл санкціонованих ключів вашого користувача.

Просто додайте ці рядки до вашого /etc/mtabі /etc/fstab, і перезавантажте систему.

none    /dev/pts    devpts    defaults    0    0

Спробуйте це:

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

щойно з’ясував, у чому проблема в моєму випадку (strato strato): Зрештою, у мене виникла така сама проблема з результатом „не вдалося виконати запит оболонки на каналі 0”

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

Логін ssh з іменами користувачів sftp та відповідними паролями не вдався. (Хоча scp і sftp працює з цими користувачами sftp!)

Це давнє запитання, але якщо хтось потрапить сюди, як я ...

Це може бути наслідком неправильної дати на сервері. Якщо ви працюєте із вбудованою системою, це може бути причиною ... Тож перевірте дату:

$ date

перезавантаження екземпляра з консолі AWS у мене спрацювало. Була служба, яка просочувала файлові зв’язки, що lsofдопомогло знайти.

shell request failed on channel 0

означає, що у вас немає доступу до оболонки або віддалених команд, зафіксуйте дозвіл користувача на сервері, щоб мати доступ до оболонки, або якщо вам просто потрібне використання -Nта -Tпараметри тунелювання

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

Це те, що мені допомогло з різних наданих відповідей.

• Спробуйте увійти як root, що допоможе вам у більшості випадків
• Спробуйте увійти як інший користувач, це вдало, це означає, що проблема пов’язана з певним обліковим записом, і це означає, що певні процеси вже запущені проблемним обліковим записом, які споживають ресурси, що перешкоджають входу (швидше за все, жоден процес )
• Збільште обмеження в /etc/security/limits.d/20-nproc.conf, як зазначено вище у xmduhan
• Спробуйте ще раз ssh, це повинно спрацювати

перемонтування / dev / pts працює для мене. Ви можете зробити це віддалено через ssh, якщо запустите ssh таким чином на ураженій машині. ssh не вимагає tty під час запуску таких команд, і тому це дозволить вам віддалено перемонтувати / dev / pts

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

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

Підсумок - це може статися, якщо ssh або інші пов'язані пакети оновлюються на машині призначення.

Я зіткнувся з цією помилкою під час використання мого git bash. Я зміг це вирішити, перевстановивши git для windows. Більше деталей у цій відповіді .

Якщо людині знайти себе читають цю QA в той час як вони намагаються sshв пристрій NetGear ReadyNAS, переконайтеся , що «Rsync тільки» прапорець ООН перевіряється в діалоговому вікні для служби SSH в інтерфейсі адміністратора.

Це відбувалося, коли я намагався використовувати sudo ssh -t git@github.comпісля додавання відкритого ключа мого локального користувача до github

Просто голова залежить від таких щасливих людей, як я

Просто перезавантаження екземпляра AWS працює для мене, щоб видалити помилку "Помилка запиту оболонки на каналі 0"

спробуйте з опцією -NT

ssh -NT ...

у моєму випадку сервер SFTP відхилить ваше з'єднання SSH.