我已經閱讀了各種帖子,我可以驗證在執行遠程ssh命令時使用-t確實會強制tty分配並允許命令完成。但是,我遇到的問題是,在這之前的十二小時,我無法自由訪問此服務器。現在,沒有任何已知的更改,我無法再連接。Git:遠程端意外掛起
我可以整天無故登錄到這臺服務器。但是,當我嘗試執行遠程命令時,比如ssh servername'ls/var/tmp',連接將斷開連接,而服務器上沒有記錄錯誤。
那麼,什麼改變了?
這裏是我的混帳配置:
wwwin-svn-sjc:142> git config --list
receive.denynonfastforwards=false
user.name=joericks
[email protected]
http.postbuffer=52428800000
我撞到我的http.postbuffer到一個淫穢的水平,以消除一個潛在的問題。 我可以切換到另一個帳戶,並使用完全相同的URL從這臺服務器克隆這些存儲庫,沒有問題。其他管理員和用戶也不受影響。 當本地服務器和使用問題帳戶時,我可以整天添加,提交和推送到遠程服務器,而不會出現問題。
在Git之外,我可以強制使用ssh -t完成遠程ssh命令,但這實際上是一種解決方法,如果我不能告訴他們爲什麼會發生這種情況,我的用戶就不會接受解決方法,或者是什麼造成的。我吹走了我的.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分配失敗,除非明確強制),並且系統沒有重新啓動,因此找到了修復問題的方法?
喬恩
http://www.btaz.com/misc/fatal-the-remote-end-hung-up-: 更改從下面的行放在.bashrc文件意外/可能有幫助 – Bijendra 2012-03-09 10:27:17