アカウント名:
パスワード:
こういう説明をするからだめなんだよ。改行の直後でのみエスケープ文字は有効、て理解しなきゃ。RTFMThe escape character must always follow a newline to be interpreted as special.
正しくは「改行の直後」じゃなくて「行の先頭」だと思います．例えば，接続直後なら "~." って打つだけで切断されます．改行は不要です．
openssh のman page (ネット上で見るならhttps://man.openbsd.org/ssh)を確認すると確かに
The escape character must always follow a newline to be interpreted as special.
と書いてあります．しかしよく読むと以下の記述もあります
The escape character is only recognized at the beginning of a line.
たぶん前者の記述は間違っています．newlineがなくても良い場合があるからmustではありません．後者の記述のほうがより正しい説明だと思われます．
いや、そもそもsshが解釈している「キーボードの入力」と、表示されている「行」とは一対一対応するものでもないので、行の先頭というのもそれはそれで不正確ですよ。
今回のケースでも「password:」と表示されているところに入力する形になるから、「行の先頭」じゃないですし。
正確を期すなら、「接続直後 または 改行を送信した直後」といったところでしょう。
特定個人の意図と反する動作したら誤動作と言われたりするからな仕様通りなんだわ
仕様知らないやつが変なこと言ってるだけのパターンだな。ssh にも記号のパスワードにも何の問題もない。
改行の直後に ~ を打つと ssh の制御コードになるのはまっとうな仕様。作業中に固まったら return ~. って打って強制切断とか普段から良く使うだろ。(文句言うやつは使ってないんだろうな)~. で切断の他にも ~B でブレークの送信とか必要になることもある。(~C で port forward 用のメニューとかも便利)改行の直後に ~ を入れたい場合には ~~ と2回打てば良い。(ssh を2段踏んでれば ~~~ と3回入れる。3段なら4回)
OpenSSHの個別の実装のことをさもSSHプロトコルのように言われましても。
RFC4254にも記述してないしね
Secure Shellプロトコルで決まってるわけじゃないが、「~」をこのように使うのは OpenSSH だけじゃなくてTatu Ylönenによるオリジナルのsshもそうだし、rlogin も cu も tip もそうなわけで、UNIX上のCLI型リモートアクセスコマンドではむしろ常識ですよ
けどなんで普通の印字可能文字を使うようにしたんだろ
昔の端末は普通の印字可能文字しかキーボードから入力できない可能性があったからでは。viのhjklカーソルもカーソルキーがない端末のためのものだったし
「OpenSSHの個別の実装」ではない。元は、シリアル回線のターミナルプログラム cu や tip の仕様だよ。
慣例であっても、標準化されていない以上個別の実装でしょ。世の中には、~.が特別な意味を持たないSSHクライアントもたくさんあるわけで。
これはターミナルエミュレーターの仕様だからSSHのプロトコルで標準化されていないのは当然では? SSHのプロトコルに乗せて送受信されるものはターミナルエミュレーターの通信だけではないのだから。ターミナルエミュレーターの標準化された仕様が存在するのかどうかは知らんが
>これはターミナルエミュレーターの仕様だから
違います。ターミナルエミュレーターは関係ありません。sshクライアントの実装です。
仮にターミナルエミュレーターだとすると、あなたはrxvtやitermが~.を処理しているとでも思っているのでしょうか。
putty や teraterm を想定してるんでしょう。SSHクライアントとターミナルエミュレータが脳内でくっついているのでは。
これからは Windows Terminal で openssh がスタンダードになるんだろうけど。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
ソースを見ろ -- ある4桁UID
パスワードの途中に「~.」があっても問題は無い (スコア:3, 興味深い)
こういう説明をするからだめなんだよ。
改行の直後でのみエスケープ文字は有効、て理解しなきゃ。
RTFM
The escape character must always follow a newline to be interpreted as special.
Re:パスワードの途中に「~.」があっても問題は無い (スコア:2)
正しくは「改行の直後」じゃなくて「行の先頭」だと思います．
例えば，接続直後なら "~." って打つだけで切断されます．改行は不要です．
openssh のman page (ネット上で見るならhttps://man.openbsd.org/ssh)を確認すると
確かに
と書いてあります．しかしよく読むと以下の記述もあります
たぶん前者の記述は間違っています．newlineがなくても良い場合があるからmustではありません．
後者の記述のほうがより正しい説明だと思われます．
Re:パスワードの途中に「~.」があっても問題は無い (スコア:1)
いや、そもそもsshが解釈している「キーボードの入力」と、表示されている「行」とは一対一対応するものでもないので、行の先頭というのもそれはそれで不正確ですよ。
今回のケースでも「password:」と表示されているところに入力する形になるから、「行の先頭」じゃないですし。
正確を期すなら、「接続直後 または 改行を送信した直後」といったところでしょう。
Re: (スコア:0)
特定個人の意図と反する動作したら誤動作と言われたりするからな
仕様通りなんだわ
Re:パスワードの途中に「~.」があっても問題は無い (スコア:3, 参考になる)
仕様知らないやつが変なこと言ってるだけのパターンだな。
ssh にも記号のパスワードにも何の問題もない。
改行の直後に ~ を打つと ssh の制御コードになるのはまっとうな仕様。
作業中に固まったら return ~. って打って強制切断とか普段から良く使うだろ。(文句言うやつは使ってないんだろうな)
~. で切断の他にも ~B でブレークの送信とか必要になることもある。(~C で port forward 用のメニューとかも便利)
改行の直後に ~ を入れたい場合には ~~ と2回打てば良い。(ssh を2段踏んでれば ~~~ と3回入れる。3段なら4回)
Re: (スコア:0)
OpenSSHの個別の実装のことをさもSSHプロトコルのように言われましても。
Re: (スコア:0)
RFC4254にも記述してないしね
Re:パスワードの途中に「~.」があっても問題は無い (スコア:2, 参考になる)
Secure Shellプロトコルで決まってるわけじゃないが、
「~」をこのように使うのは OpenSSH だけじゃなくて
Tatu Ylönenによるオリジナルのsshもそうだし、
rlogin も cu も tip もそうなわけで、
UNIX上のCLI型リモートアクセスコマンドではむしろ常識ですよ
Re: (スコア:0)
けどなんで普通の印字可能文字を使うようにしたんだろ
Re:パスワードの途中に「~.」があっても問題は無い (スコア:1)
昔の端末は普通の印字可能文字しかキーボードから入力できない可能性があったからでは。viのhjklカーソルもカーソルキーがない端末のためのものだったし
Re: (スコア:0)
「OpenSSHの個別の実装」ではない。
元は、シリアル回線のターミナルプログラム cu や tip の仕様だよ。
Re: (スコア:0)
慣例であっても、標準化されていない以上個別の実装でしょ。
世の中には、~.が特別な意味を持たないSSHクライアントもたくさんあるわけで。
Re: (スコア:0)
これはターミナルエミュレーターの仕様だからSSHのプロトコルで標準化されていないのは当然では? SSHのプロトコルに乗せて送受信されるものはターミナルエミュレーターの通信だけではないのだから。ターミナルエミュレーターの標準化された仕様が存在するのかどうかは知らんが
Re: (スコア:0)
>これはターミナルエミュレーターの仕様だから
違います。ターミナルエミュレーターは関係ありません。
sshクライアントの実装です。
仮にターミナルエミュレーターだとすると、あなたはrxvtやitermが~.を処理しているとでも思っているのでしょうか。
Re: (スコア:0)
putty や teraterm を想定してるんでしょう。
SSHクライアントとターミナルエミュレータが脳内でくっついているのでは。
これからは Windows Terminal で openssh がスタンダードになるんだろうけど。