Tera Term

記憶に頼って書いてます。

認証処理は以下の順番でパケットが送られます。

1. C: SSH_MSG_SERVICE_REQUEST
2. S: SSH_MSG_SERVICE_ACCEPT
3. S: SSH_MSG_USERAUTH_BANNER (Optional)
4. C SSH_MSG_USERAUTH_REQUEST
5. S: SSH_MSG_USERAUTH_SUCCESS/FAILURE
6. -以下略-

ttsshでは、認証方式が決まってSSH_MSG_USERAUTH_REQUESTを送る際の前処理としてSSH_MSG_SERVICE_REQUESTを送る(ただし送信済みの場合はスキップする)という実装だったと思います。

なので認証ダイアログが開いた段階ではSSH_MSG_SERVICE_REQUESTが送られていない為サーバーは認証処理がまだ開始していないと認識しているので、SSH_MSG_USERAUTH_BANNERもまだ送られてきていないとういう状態だったはずです。

ただ、CheckAuthListFIrst=1ならば一度SSH_MSG_USERAUTH_REQUESTを送信するので、状況が変わるかも。 CheckAuthListFIrst=1でも起きるならば、他にも原因があるかもしれません。

ブレークポイントを設定しながらログを取って確認しました。

CheckAuthListFirst=0 だと認証前に表示されているので、正確ではありませんでした。CheckAuthListFirst=1 だと遅れて表示されているように見えます。

CheckAuthListFirst=0 だと、このように動いているようです。これは期待通りです。

認証ダイアログが開く
ユーザ名を入力する
パスワードを入力する
認証ダイアログのOKボタンを押す
認証ダイアログが消える
C: SSH_MSG_SERVICE_REQUEST
S: SSH_MSG_SERVICE_ACCEPT
C SSH_MSG_USERAUTH_REQUEST("none")
S: SSH_MSG_USERAUTH_BANNER
バナーが表示される
S: SSH_MSG_USERAUTH_FAILURE ("none" は必ず FAILURE になる)
C: SSH_MSG_USERAUTH_REQUEST (本当の認証)
S: SSH_MSG_USERAUTH_SUCCESS

CheckAuthListFirst=1 だと、このように動いているようです。

認証ダイアログが開く
ユーザ名を入力して、フォーカスアウトする
C: SSH_MSG_SERVICE_REQUEST
S: SSH_MSG_SERVICE_ACCEPT
C SSH_MSG_USERAUTH_REQUEST("none")
S: SSH_MSG_USERAUTH_BANNER ... ログされているので、ここで受信はしている
バナーが表示されない ... このあたりからおかしい
handle_SSH2_userauth_failure() に来ない ... S: SSH_MSG_USERAUTH_FAILURE ("none" は必ず FAILURE になる) が送られてきているはずだが...

-> 認証ダイアログのOKボタンを押す
   何も起こらない ... ログインできない ticket #40995
-> 認証ダイアログのDisconnectボタンを押す
   C: SSH_MSG_DISCONNECT
   バナーが表示される ... 「ここまでバナーが表示されない」ということでこの ticket を切った
   S: SSH_MSG_USERAUTH_FAILURE

CheckAuthListFirst=1 のときの期待する動き

認証ダイアログが開く
ユーザ名を入力して、フォーカスアウトする
C: SSH_MSG_SERVICE_REQUEST
S: SSH_MSG_SERVICE_ACCEPT
C SSH_MSG_USERAUTH_REQUEST("none")
S: SSH_MSG_USERAUTH_BANNER
バナーが表示される
S: SSH_MSG_USERAUTH_FAILURE ("none" は必ず FAILURE になる)

パスワードを入力する
認証ダイアログのOKボタンを押す
C: SSH_MSG_USERAUTH_REQUEST (本当の認証)
S: SSH_MSG_USERAUTH_SUCCESS

# wireshark と KeyKey.log を使ってパケットの中身まで見たかったのですが、手元でうまくいきません（ログファイルを指定しても復号されない）。

しかし、やりとりとパケットサイズを見た感じでは、以下のことが起こっているようです。

CheckAuthListFirst=1 で、認証ダイアログを出したまま（ユーザ名のフォーカスアウトで）送った SSH_MSG_USERAUTH_REQUEST の返事（SSH_MSG_USERAUTH_FAILURE）が返ってきません。

C: SSH_MSG_SERVICE_REQUEST
S: SSH_MSG_SERVICE_ACCEPT
C: SSH_MSG_USERAUTH_REQUEST("none")
S: SSH_MSG_USERAUTH_BANNER
S: SSH_MSG_USERAUTH_FAILURE ("none" は必ず FAILURE になる) <- これが来ていない

• 問題1
  • サーバから SSH_MSG_USERAUTH_FAILURE が返ってこない（ような変な送り方をしている？）
• 問題2?
  • DISCONNECT に対する FAILURE が返ってくると。バナーが VTWinodw に表示されている様子
  • 「SUCCESS/FAILURE が返ってくるまでバナーが VTWinodw に表示されない」という問題？

サーバから SSH_MSG_USERAUTH_FAILURE が返ってこない（ような変な送り方をしている？）

SSH のパケットを見ると SSH_MSG_USERAUTH_FAILURE が返ってきていました。

ですので、サーバは同じレスポンスを返しているのに、TTSSH 側が受信する動きに違いがあります。

CheckAuthListFIrst が 0 でも 1 でも SSH_MSG_USERAUTH_REQUEST("none") は送られます。認証ダイアログが生きた状態かどうか？の違いかもしれません。

SSH_MSG_USERAUTH_BANNER の message が長くて PKT_recv() に渡されているバッファの長さを超えた場合、続きを読む必要があります。

続きを読むために PostMessage() を呼んでいるようですが、続きが読み込まれず処理が止まっています。

この現象は、CheckAuthListFIrst が 1 のとき（SSH 認証ダイアログが表示されているとき）のみ発生します。

問題が起きているTCPパケット（SSH_MSG_USERAUTH_BANNER と SSH_MSG_USERAUTH_FAILURE が同じ TCP パケットに乗っている。これで1パケット)

• SSH Packet 1 (1200 byte)
  • SSH packet length 4 byte (1164)
  • Padding length 1 byte (13)
  • Payload
    • Message Type 1 byte SSH_MSG_USERAUTH_BANNER
    • string message
      • string length 4 byte (0x475 = 1141)
      • string data 1141 byte
    • string language tag
      • string length 4 byte (0)
  • Padding 13 byte
  • MAC 32 byte
• SSH Packet 2 (64 byte)
  • SSH packet length 4 bytes (28)
  • Padding length 1 byte (12)
  • Payload
    • Message Type 1 byte SSH_MSG_USERAUTH_FAILURE
    • string list
      • string len 4 byte
      • string data 9 byte ("publickey")
    • bool 1 byte
  • Padding 12 byte
  • MAC 32 byte

処理の流れ @ PKT_recv()

• パケットが読み込まれる
  • pvar->pkt_state.buf にデータが入る
• SSH2_handle_packet(), その先の handle_SSH2_userauth_banner() が呼ばれ、pvar->ssh_state.payload_datastart, pvar->ssh_state.payload_datalen がセットされる
• while の先頭に来て、pvar->pkt_state.buf から 1024 バイトが buf にコピーされる（message の途中まで）
  • この段階で VTWindow への描画指示が行われているようだが、認証ダイアログが消えるまでは描画が行われない模様 ※2
• データの長さが 1024 より大きいので buflen が 0 になる
  • while を抜ける
• SSH_is_any_payload(pvar) が TRUE なので、pvar->NotificationWindow に PostMessage() する
  • ここでふたたび PKT_recv() に来て SSH_MSG_USERAUTH_BANNER の残りを読み取り、続けて SSH_MSG_USERAUTH_FAILURE が処理される。のが正しい動きだと思われるが、CheckAuthListFIrst が 1 だとそうはならない。※1
  • CheckAuthListFIrst が 0 だとふたたび PKT_recv() に来ている

まとめ

前のコメントに書いたように

• ※1 #40995 SSH_MSG_USERAUTH_FAILURE が処理されずに先に進まない
• ※2 #46471 （このチケット）SSH認証ダイアログがあるうちは VTWindow への描画が反映されない

の二つの問題がありそう。

問題※2についてですが、Tera Term の仕様と言えそうです。

Tera TermはWindowsのメッセージをすべて処理したのち、 アイドル処理として受信バッファのデータを処理します。

例えば、SSH認証ダイアログが出ている間、 DialogBoxIndirectParamW()に入ったまま返って来ないので アイドル処理ができなくなり、受信バッファのデータが処理されません。

たとえば、出力が少し遅延するコマンドを入力して、

sleep 5 && ls

SSH_MSG_USERAUTH_BANNER受信処理内で、描画まで行うなどで 対処できるかもしれませんが特別処理となりそうです。

アイドル処理をスレッドに置き換えたいなと思いますが 取り掛かるのは先になりそうですね。

確認ありがとうございます。すぐに修正するのは難しそうですね。

取り得る選択肢：

• 今のまま「認証後」に表示される、でよいとする
• 今のままで RFC の「認証前」「ログインプロンプトの前」に従おうとする。AuthBanner のデフォルトを 2 か 3 にして回避する

いずれにしろ「5.0 で根本的な解決はしない」という認識に修正します。