奇妙なSSHの問題、sshは-tで動作しますが、それなしでは動作しません。

奇妙なSSHの問題、sshは-tで動作しますが、それなしでは動作しません。

私のサーバーの1つにログインすると、ログインしているようにssh見えますが、プロンプト(message debug2: shell request accepted on channel 0 is the last log entry)が表示される前に停止します。

奇妙にssh -t "/bin/bash"動作しないときも動作します。ssh

私が今まで見つけたもの

  • 同じ地理的な場所にあるサーバーから正常にログインできます。
  • もしそうならssh -t '/bin/bash'- どこからでも完全にログインできます。
  • 私が使うならrsync 到着サーバーが動作しているようで、ロックされました。
  • 私が使うならrsync ~からサーバー、問題なく実行中

私が試したこと

  • すべてのログインオプションを削除または変更.profileする.bashrc /etc/profile
  • 変化ssh_config そして/または sshd_config正常に実行されているのと同じサーバー上
  • 路線を確認してみる
  • ネットワークの専門家に確認を求めたが、tcpdump役に立たなかった。 (再送信が多いようですが)

本当に違うのは思わない。

疑わしいネットワークカードドライバ/ファームウェアは除外されます。

答え1

これは、構成ファイルの問題によって発生する可能性があります。シェルを
接続するとssh -t /bin/bash 「ログイン」もされず、ソースでも /etc/profileなく...~/.profile~/.bashrc

したがって、一度接続すると、シェルをデバッグモードに切り替え、各ファイルをソーシングして内部でブロックされている項目を見つけます。

set -x 
. /etc/profile 
...and so on

編集する

私が間違っていることに注意してください。 .bashrcファイルはすべての対話型シェルで選択されます(したがって、ここではプロファイルであるprofile.dファイルのみが重要です)。

接続プロセスのさまざまな手順をリストしてみてください。このような

1) SSH 接続(構成,...)
2) ログイン(PAM, tty, wtmp,...)
3) シェル起動(構成ファイル、ホームディレクトリアクセス、...)

(1) を確認するには、デバッグモードで sshd デーモンを起動できます。これを行うには、専用ポート(ポート22ではないため、通常のsshdデーモンを停止する必要はありません)でリッスンしながら他のsshdを起動する必要があります。

# /usr/sbin/sshd -p 2222 -ddd 

sshdは1つの接続のみを許可し、バックグラウンドに移動しません。別の端末を開き、SSHセッションに接続します。

# ssh -vvv -p 2222 user@host

受信したメッセージを同じブランドの他のサーバーから送信されたメッセージと比較できます。これにより、問題がSSH側にあるかどうかがわかります。

(-dddと-vvvは調整可能な最大デバッグレベルです。)

わかりました。協会、詳細な詳細。

答え2

私の質問に対する答え ネットワークの問題として確認されました。結局、すべてのネットワークカードのMTUを少し下げると問題が解決することがわかりました。

ネットワーク構成が間違っている可能性が高くなりますが、これを証明し、ネットワークチーム(継続サーバーの問題と呼ばれる)に渡すことができます。

しかし、これは最後の手段であることに注意してください。 私の特徴は、sshサーバーは同じサブネット上で動作しますが、外部では機能せず、ssh -t '/bin/bash'はどこでも動作することです。

また、rsyncもありますが、うまく起動しますが、ある時点でハングアップしたり接続が切断されたりします。

したがって、この回答を見ている場合は、上記の他の回答を最初に試してください。これは私のような奇妙な問題がある場合にのみ役立ちます。

すべての助けに感謝します。私はすべてを試してみました、それは私に多くを教えてくれました、そしてそれがサーバーとは何の関係もないことを確認することができました(これは私が望んでいたものです)。

助けてくれた皆さんに感謝します。

答え3

最近ネストされた仮想化プラットフォームを使用しているときに同じ問題が発生しました。

ソースサーバーまたはターゲットサーバーでMTUを1500から1400に減らすことができます。

/sbin/ip link set dev eth0 mtu 1400

答え4

これにより、ssh some_user@some_host /bin/bash実行するだけです。ユーザーシェル(で定義され/etc/passwdている所有者) 次に、/bin/bashそのシェルで指定されたコマンドを実行します。

今、ユーザーシェル(私たちも想定していますbash)は対話式ではありません(代わりに与えられたコマンドを実行します)。したがって、pty(a擬似端末)、これは実行されたコマンドに使用できるptyがないため、非対話型で始まることを意味します。

この例では、要求された/bin/bashコマンドは開始されましたが停止したようです。

sshシェルとそのサブプロセスで使用できるようにptyを作成する必要があるため、この問題を解決できます。それがまさにそのことです-t

    $ ssh -t some_user@some_host bash

ptyを生成するようにコマンドを実行してこの問題を解決することもできます。の場合、パラメータを渡すことでこれを行うことがbashできます。-i次のコマンドラインも機能します。

$ ssh some_user@some_host bash -i

ただし、後者の場合、シェルにアクセスできないため、/dev/tty警告が発生します。

bash: no job control in this shell

理由は次のとおりです。ここ。これは、シェルで実行したい操作によっては問題になる可能性がありますが、使用しない方が良いかもしれませんssh -t

bashとにかく、ユーザーのデフォルトのシェルパスにある必要があるため、コマンドとして渡すことができます。)

関連情報