Я прочитал различные сообщения об этой проблеме, и я могу проверить, что использование -t при выполнении удаленной команды ssh действительно вынуждает tty выделять и разрешать выполнение команды.Однако проблема, с которой я столкнулся, состоит в том, что за двенадцать часов до этого момента у меня был беспроблемный доступ к этому серверу.Теперь, без известных изменений, я больше не могу подключиться.
Я могу войти на этот сервер без проблем весь день.Тем не менее, когда я пытаюсь выполнить удаленную команду, скажем, ssh servername 'ls / var / tmp', соединение разрывается без зарегистрированной ошибки на сервере.
Итак, что изменилось?
Вот мой конфиг git:
wwwin-svn-sjc:142> git config --list
receive.denynonfastforwards=false
user.name=joericks
user.email=joericks@cisco.com
http.postbuffer=52428800000
Я поднял свой http.postbuffer до непристойного уровня, чтобы устранить это как потенциальную проблему.Я могу без проблем переключиться на другую учетную запись и клонировать эти репозитории с этого сервера, используя те же URL-адреса.Другие администраторы и пользователи также не пострадали.Локально к серверу и используя проблемную учетную запись, я могу без проблем добавлять, фиксировать и передавать на удаленные серверы весь день.
Вне Git я могу заставить удаленные команды ssh завершать работу с помощью ssh -t, но это действительно обходной путь, и мои пользователи просто не примут обходной путь, если я не могу сказать им, почему / как этослучилось или что вызвало это.Я сдул мои настройки конфигурации .ssh и ключи ssh.Попытка клонировать без ключей вызвала требуемое приглашение пароля и тот же сбой.
Я убедился, что разрешения для файлов .ssh и родительских каталогов были нормальными:
> ls -alrt
total 712
-rw-r--r-- 1 58 Sep 15 17:02 config
-rw-r--r-- 1 681826 Mar 7 12:24 known_hosts
-rw------- 1 1675 Mar 7 15:22 id_rsa
-rw-r--r-- 1 405 Mar 7 15:22 id_rsa.pub
drwx------ 2 4096 Mar 7 15:23 .
-rw-r--r-- 1 405 Mar 7 15:23 authorized_keys
drwxr-xr-x 78 24576 Mar 7 15:25 ..
У меня специальносохранил мою конфигурацию ssh максимально простой:
>cat config
ForwardX11 yes
ForwardAgent yes
StrictHostKeyChecking no
Используя ssh -vvv, я возвращаюсь с этим выводом.(сокращено для краткости)
Прервано соединение с проблемным сервером:
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug2: channel 0: rcvd adjust 2097152
debug2: channel_input_status_confirm: type 99 id 0
debug2: exec request accepted on channel 0
debug2: channel 0: rcvd eof
debug2: channel 0: output open -> drain
debug2: channel 0: obuf empty
debug2: channel 0: close_write
debug2: channel 0: output drain -> closed
Хороший вызов для функционального сервера:
debug3: packet_send2: adding 48 (len 67 padlen 13 extra_pad 64)
debug2: we sent a password packet, wait for reply
debug1: Authentication succeeded (password).
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug1: Entering interactive session.
debug2: callback start
debug2: client_session2_setup: id 0
debug1: Sending command: ls
debug2: channel 0: request exec confirm 1
debug2: fd 3 setting TCP_NODELAY
debug2: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug2: channel 0: rcvd adjust 2097152
debug2: channel_input_status_confirm: type 99 id 0
debug2: exec request accepted on channel 0
11:43
На данный момент ядействительно в растерянности, и, к сожалению, у меня есть по крайней мере еще один пользователь, который сталкивается с этой же проблемой.Кто-нибудь когда-нибудь выяснял, что именно вызывает эту проблему (tty распределение завершается неудачно, если явно не принудительно), и, если не считать перезагрузки системы с помощью коленного рывка, было найдено решение проблемы?
Jon