sshでPTYを使うかどうかでの小ネタ

angel (as ㌵㌤の猫) @angel_p_57

というわけで。締め切り来たので解説を。 回答していただいた皆様、有難うございました。 結構ばらけたものの「to stdoutのみ」が優勢で、まあ常識的な反応だったかなと思う。 twitter.com/angel_p_57/sta…

angel (as ㌵㌤の猫) @angel_p_57

ふとクイズ。 次のtweetのように、sshログインして標準出力・標準エラーに1行ずつ(～to stdout, ～to stderr)出力するスクリプトがある。遠隔実行( ssh cent8 ./test.sh )も可。 で、この状況で"ssh cent8 ./test.sh 2>/dev/null"とリダイレクトすると、その2行のうちターミナルに表示されるのは?

2022-03-26 13:09:02

angel (as ㌵㌤の猫) @angel_p_57

ふとクイズ。 次のtweetのように、sshログインして標準出力・標準エラーに1行ずつ(～to stdout, ～to stderr)出力するスクリプトがある。遠隔実行( ssh cent8 ./test.sh )も可。 で、この状況で"ssh cent8 ./test.sh 2>/dev/null"とリダイレクトすると、その2行のうちターミナルに表示されるのは?

angel (as ㌵㌤の猫) @angel_p_57

この状況をとった画像。sshログインしてリダイレクトを試して、それぞれ標準出力、標準エラーへの出力であることも確認してる。 ※遠隔実行すると別のスクリプトに差し替えられてる、なんてこともないので念のため。 pic.twitter.com/MJ3dGgSCNy

拡大

angel (as ㌵㌤の猫) @angel_p_57

ただまあ、先に謝っておくと、これ「イジワル問題」なので、そんな素直な答えではなくて。この画像の通り「両方表示される」が正解。 pic.twitter.com/KdenSsoG6x

拡大

angel (as ㌵㌤の猫) @angel_p_57

「え? なんで?」と思うのは、多分正常な感覚で。実際に違う状況ならそうもなるから。 だから敢えて「この状況で」と問題に書いてあったのがさりげなく重要で。なので「イジワル問題」と。 pic.twitter.com/uuwDA0zQjA

拡大

angel (as ㌵㌤の猫) @angel_p_57

ひょっとしたら、もっと色々環境を調整することで、見た目の状況が同じでも、どっちの結果も引き出せるかも知れないので、そういう意味では「断言できない」が正解の可能性もある。 ※sshの実装自作するとか、そういうのはナシで。 でも、多分今回だと答えは決め打ちできるはず。

angel (as ㌵㌤の猫) @angel_p_57

では、「この状況」の何がポイントだったのか。実際に2行分表示されているのと、to stdoutのみの場合とを比較してみる。 …実はリダイレクトしない場合に "closed" のメッセージが出るかどうか。ここで違いがあるんだよね。 pic.twitter.com/vAqbQnb9Pn

拡大

拡大

angel (as ㌵㌤の猫) @angel_p_57

で、問題の時の状況をよく観ると、遠隔コマンド実行した時に "closed" のメッセージがある。なので、2行分出る方の状況になっていたということ。 twitter.com/angel_p_57/sta…

angel (as ㌵㌤の猫) @angel_p_57

「そんなの微妙過ぎんだろ」と言われそうで、実際そうなんだけど、「普段出ないはずのメッセージの出現」「わざわざこんな問題を出している」という違和感から、辿り着く人いるかな～、という背景があった。 ※別に正解しなかったらpgrするとか、そんな意図はないので念のため

angel (as ㌵㌤の猫) @angel_p_57

で、じゃあ、同じコマンドなのに状況が変わるのはなぜかと言うと、それは ssh の設定 ( ~/.ssh/config ) に仕込みを入れていたから。 ssh -G で設定内容を見られるけど、その中の requesttty を、敢えて標準の auto から true に変えていた。そこが原因。 pic.twitter.com/3w2K0LHWFZ

拡大

拡大

angel (as ㌵㌤の猫) @angel_p_57

この設定は、コマンドラインオプション -t/-T どちらを採用するのかの効果。autoの場合、ログインなら -t 相当、遠隔コマンド実行なら -T 相当。true の場合、遠隔コマンド実行でも -t 相当に。 この画像のように、-t/-T を明示してあげると、closed のメッセージの有無の違いが出ることが分かる。 pic.twitter.com/minQYAcSBA

拡大

angel (as ㌵㌤の猫) @angel_p_57

で、-t ってなんだっけ、というとリモートホスト側の入出力経路にPTYを使う、という効果。ログインの場合はPTYがないと対話処理に不便なので、なので auto+ログインの場合は -t 相当になる。 逆に、-T の場合はPTYを使わずにパイプを使う形になる。対話処理を行わないならPTYは不要だから。

angel (as ㌵㌤の猫) @angel_p_57

ちなみに、パイプを使う場合の入出力経路は、以前こんな形で解説したことがある。 出展: バックグラウンドのSSH処理がジョブを停止させる問題 qiita.com/angel_p_57/ite… つまり、リモートコマンドの3つの標準ストリーム(stdin/stdout/stderr)に合わせて、3本のパイプでデータをやりとりする。 pic.twitter.com/LvEz4aagVm

拡大

angel (as ㌵㌤の猫) @angel_p_57

パイプが別々に用意されているので、遠隔コマンドが標準出力/標準エラーから出力されたデータは区別されて、手元のSSHでも標準出力/標準エラー(に接続されたファイル)へ出力されることになる。 pic.twitter.com/T4ncJIASi4

拡大

angel (as ㌵㌤の猫) @angel_p_57

一応ねんのため。このパイプを使う方が通常なので ( 今回のは「イジワル問題」 )。 なので、ssh 自体の標準エラーをリダイレクトすると、あたかもリモートコマンドの標準エラーをリダイレクトしているような感覚で使える。 twitter.com/angel_p_57/sta…

angel (as ㌵㌤の猫) @angel_p_57

ところが、-t 相当でPTYを使うと、入出力経路がこのようになる。 遠隔コマンドの3つの標準ストリームは全て1つのPTYにまとめられて、sshd から「データがどこから来たか」は区別できなくなる。 pic.twitter.com/locCf2ibcA

拡大

angel (as ㌵㌤の猫) @angel_p_57

つまりこういう感じ。遠隔コマンドでstdout/stderrどちらから出力しようと、PTYを経由するときにまとめられて区別されなくなり、手元のsshでは全部標準出力(に接続されたファイル)に出力される。 pic.twitter.com/weYFDHpqo9

拡大

angel (as ㌵㌤の猫) @angel_p_57

「そういう状況」だと、ssh側で標準エラーをリダイレクトしても、そもそもデータが全部まとめて標準出力側に行ってるので影響がない、と。これが今回の問題の謎解きということ。

angel (as ㌵㌤の猫) @angel_p_57

対話処理なら別に気にするポイントではないし、非対話処理で敢えて -t で PTY は使わないので、別に実用上重要ではないと思うけど。でも、パイプなのかPTYなのかで違うよなーと考えて、ふと思いついて問題にした、という感じ。

angel (as ㌵㌤の猫) @angel_p_57

なお、"closed" のメッセージが出るかどうか、微妙過ぎるポイントだとは思うんだけど、これも多分ちょっと意味がある。 パイプとPTYの特性の差から出る違い、ということで。

angel (as ㌵㌤の猫) @angel_p_57

それは何かと言うと、「sshが接続終了と判断する条件」の違い。なんというか、PTY の方が「打ち切りました」感がちょっと出てる感じがする。