scp(1) を使用してあるホストから別のホストにファイルをコピーする実行中のシステムがあります。システムは一連のファイルを処理していますが、そのうちの1つで停止しました。つまり、昨日はscpコマンドを起動しましたが、今日でも実行され続けています。
strace を実行すると、scp が ssh サブプロセスの stdout に関連付けられたパイプファイルの読み取りを待っていることがわかります。つまり、このサブプロセスはfd 4の読み取りを待っています/dev/tty。
known_hostsSSH 宛先のホストキーがソースホストのホストキーと競合します。長い間実行されているSCPの起動に触れました。これでknown_hostsすべてが設定されているため、メッセージを表示せずにソースからすべての宛先にSSHを接続できます。
私の前提は、ssh小さなタイミングウィンドウが発生し、ユーザーに不明なホストキーが表示され、確認（"yes\n"）が続くのを待っていることです。
ユーザーが入力したようにread呼び出しが機能するようにする方法はありますか（もしそうなら、どうすれば）？sshyes
echo foobar > /dev/tty私がxterm（別のコンピュータ）にいるときにfoobar私のコンソールに書き込みます。当然、echo foobar > /proc/<pid>/fd/4Iがへのシンボリックリンクであっても同じ結果が発生します/dev/tty。それでは、sshにどのように入力を受けますか？
私の仮説をテストしたり、別の方法で動作させる方法を知っている人がいる場合は、sshその話も聞きたいです。
答え1
作成時にプロセスIDを考慮しないでください/dev/tty。これで成功することはできません。
同じですが装備、プロセスは特定のデバイスで別のファイル記述子を開きます。 Linuxの場合、プロセスID（/ proc /）がわかっている場合は、個々のファイル記述子を操作できます。PID/ fd / 0は、IDを持つプロセスの標準入力です。PID。
あなたの場合、プログラムはデバイスを開き、そのファイル記述子は/ proc /にもあります。PID/fd（ただしわからない）。アプリケーションは、このディレクトリにあるシンボリックリンク情報を「表示」して機能します。
詳しくは、/proc/の項目はPID/ fdはすべて異なるinode値を持ちます（ファイル記述子が異なるため）。 proc/の項目をエコーします。PID/ fdはファイル記述子をエコーするという意味です。
しかし、sshはその方向の入力を期待せず、補足的なヒントを提供しません。使用している回避策はおそらく最善でしょう。
答え2
頻繁に再インストールされる（したがって新しいホストキーを生成する）、組み込みシステムを使用するときにこの問題を回避しました。新しいホストキーを盲目的に受け入れたい場合は、そうすることができますが、この点に注意してください。相手の詐欺に対する防御手段を削除します。。十分に制御されたネットワークでは、リスクの低い作業に適している可能性がありますが、パブリックインターネットでは使用しないことをお勧めします！
問題のホストについては、ssh writeに新しいホストキーを自動的に受け入れさせ、代わりに作成してください/dev/null。
Host h
UserKnownHostsFile /dev/null
StrictHostKeyChecking no
PasswordAuthentication no
SSHには絶対に確認しないオプションがないようですknown_hosts。
あなたの質問の問題は、ホストキーがクライアントにまったく知られていないことであれば（知っていましたが、今変更されているのとは対照的に）-o StrictHostKeyChecking=noSSHコマンドラインに追加するだけで十分です。
つまり、セキュリティの縮小を受け入れた場合にのみこれを実行してください。。私はあなたがyesインタラクティブSSHが無条件に応答したいと言ったようにこれを行うと仮定します。