TTSSH.LOGを生成する方法

Tera TermでSSH接続時の詳細情報は「TTSSH.LOG」に記録されるようです。Tera Termの設定ファイルで「TTSSH が TTSSH.LOG に記録するログのレベルを設定します。」のような記述があります。ここで疑問が生じます。そのファイル「TTSSH.LOG」は「何処に」出来るのでしょうか？ 

設定ファイルで出力先ディレクトリを指定するのでしょうか？もしそうであるなら、その指定をおこなうためのキーワードは何でしょうか？

いろいろと調べてみたら、ログファイル「TTSSH.LOG」は、実行ファイル「ttermpro.exe」のあるディレクトリに作成されるそうなのです。そのディレクトリは「C:\Program Files (x86)\teraterm」ですが、ファイルはありません。いったいどうなっているのでしょう。

もしかすると書き込み権限が悪さをしていてファイルが出来ていないのかもしれません。そこでTera Termを管理者権限で実行させてみました。すると「TTSSH.LOG」が出来ていました。やはり権限の問題なのでしょう。

管理者権限でなくてもログファイルが出来るようにするため、ディレクトリに権限を与えておきたいと思いましたが、どうしたら良いか分かりません。これは将来の課題としておきます。

Tera TermでOpenVMSにSSH接続する

Tera Term 4.105（Tera Term Secure Shell extension 2.91）でOpenVMSにSSH接続しようとしましたが、最終的に接続できませんでした。Windows10附属ssh.exeやRLoginでは接続できていますし、同じ鍵を使っているので接続できるはずだと思いますが駄目でした。

Windows10でTera Termを使っているだけでは、何が悪くて接続できないのか、さっぱり分かりません。SSHで接続しようとした際のログファイルを確認する必要があります。

• Tera Term側のログは「C:\Program Files (x86)\teraterm\TTSSH.LOG」にあります。
• OpenVMS側のログは「SYS$SYSDEVICE:[TCPIP$SSH]TCPIP$SSH_RUN.LOG」にあります。

ログを確認すると、Tera Term側から「SSH2_MSG_DISCONNECT」を送っているようです。その前後のログは以下のようになっていました。

2020-10-03 06:05:05.656Z [27016] ssh2_kex_finish: SSH2_MSG_NEWKEYS was sent. 2020-10-03 06:05:05.677Z [27016] SSH2_MSG_IGNORE was received. 2020-10-03 06:05:05.677Z [27016] SSH2_MSG_NEWKEYS was received(DH key generation is completed). 2020-10-03 06:05:05.696Z [27016] Server reports supported authentication method mask = 65580 2020-10-03 06:05:05.696Z [27016] Entering secure mode 2020-10-03 06:05:05.696Z [27016] User authentication will be shown by 0 method. 2020-10-03 06:05:05.902Z [27016] CRYPT_set_random_data: RAND_bytes call 2020-10-03 06:05:05.906Z [27016] finish_send_packet_special: built packet info: aadlen:0, enclen:32, padlen:10, datalen:52, maclen:20, mode:E&M 2020-10-03 06:05:05.906Z [27016] SSH2_MSG_SERVICE_REQUEST was sent at do_SSH2_userauth(). 2020-10-03 06:05:05.906Z [27016] SSH2_MSG_IGNORE was received. 2020-10-03 06:05:05.906Z [27016] SSH2_MSG_SERVICE_ACCEPT was received. service-name=ssh-userauth 2020-10-03 06:05:05.906Z [27016] CRYPT_set_random_data: RAND_bytes call 2020-10-03 06:05:05.916Z [27016] finish_send_packet_special: built packet info: aadlen:0, enclen:48, padlen:4, datalen:68, maclen:20, mode:E&M 2020-10-03 06:05:05.917Z [27016] SSH2_MSG_USERAUTH_REQUEST was sent do_SSH2_authrequest(). (method 0) 2020-10-03 06:05:05.927Z [27016] SSH2_MSG_IGNORE was received. 2020-10-03 06:05:05.927Z [27016] SSH2_MSG_USERAUTH_BANNER was received. 2020-10-03 06:05:05.927Z [27016] Banner len: 69, Banner message: Welcome to OpenVMS (TM) Alpha Operating System, Version V8.4-2L1 . 2020-10-03 06:05:05.927Z [27016] Banner ltag len: 2, Banner Language Tag: en 2020-10-03 06:05:27.859Z [27016] CRYPT_set_random_data: RAND_bytes call 2020-10-03 06:05:27.859Z [27016] finish_send_packet_special: built packet info: aadlen:0, enclen:48, padlen:6, datalen:68, maclen:20, mode:E&M 2020-10-03 06:05:27.859Z [27016] SSH2_MSG_DISCONNECT was sent at SSH_notify_disconnecting(). 2020-10-03 06:05:27.876Z [27016] SSH2_MSG_IGNORE was received. 2020-10-03 06:05:27.876Z [27016] SSH2_MSG_USERAUTH_FAILURE was received.

OpenVMS側では以下のようなログを出しています。

debug( 3-OCT-2020 15:05:54.30): Ssh2Transport/TRCOMMON.C:2832: >TR packet_type=50

debug( 3-OCT-2020 15:05:54.31): SshUnixUser/SSHUNIXUSER.C:3122: ovms_pw->pw_dir:KAZ$USER:[FURUSAWA]  unix_passwd.pw_dir:/dka100/user/furusawa/ 

debug( 3-OCT-2020 15:05:54.31): Sshd2/SSHD2.C:1655: user 'furusawa' service 'ssh-connection' client_ip '192.168.1.31' client_port '53402' completed ''

debug( 3-OCT-2020 15:05:54.32): Sshd2/SSHD2.C:2108: output: publickey

debug( 3-OCT-2020 15:05:54.32): Ssh2Transport/TRCOMMON.C:1139: Sending packet with type 2 to connection

debug( 3-OCT-2020 15:05:54.32): Ssh2Transport/TRCOMMON.C:1139: Sending packet with type 53 to connection

debug( 3-OCT-2020 15:05:54.32): Ssh2Transport/TRCOMMON.C:1139: Sending packet with type 2 to connection

debug( 3-OCT-2020 15:05:54.32): Ssh2Transport/TRCOMMON.C:1139: Sending packet with type 51 to connection

debug( 3-OCT-2020 15:06:16.25): Ssh2Transport/TRCOMMON.C:2832: >TR packet_type=1

debug( 3-OCT-2020 15:06:16.25): Ssh2Common/SSHCOMMON.C:180: DISCONNECT received: authentication cancelled

Sat 03 15:06:16 INFORMATIONAL: Remote host disconnected: authentication cancelled

debug( 3-OCT-2020 15:06:16.25): Sshd2/SSHD2.C:760: locally_generated = FALSE

Sat 03 15:06:16 INFORMATIONAL: disconnected by application in remote: 'authentication cancelled'

Tera Termを使わなくてもRLoginならばOpenVMSにSSH接続できるので、実害はありません。この場合、Tera Term側が「SSH2_MSG_DISCONNECT was sent」となっており、OpenVMS側が「Remote host disconnected」となっているので、Tera Term側が接続を断っているように見えます。他のSSHクライアントであれば接続できているので、Tera Term側の問題であることが疑われます。

RLoginでOpenVMSに接続した際の端末タイプの設定方法

先日インストールしたOpenVMS Alpha 8.4-2L1にRLoginで接続すると、端末タイプが「VT500相当」になります。VT500相当ではいけないという事ではありませんが、VT100などにはならないのか、そもそも任意に変更できるのか、不明でした。

$ show term

Terminal: _OPA0:      Device_Type: VT500_Series  Owner: SYSTEM

RLoginのWebサイトにある「エスケープシーケンス一覧」によると、「DA1」の応答はTermID設定によって変化すると書かれています。その「TermID設定」とは「3.6.1 ESC/CSI/DCSの設定」によれば次のように書かれています。

各種IDでは、DA1,DA2,DA3で応答する番号の初期値を設定できます。

試してみたところ、次のように変化しました。

1. TermIDを「10」とした場合「VT500_Series」になる。
2. TermIDを「9」とした場合「VT400_Series」になる。
3. TermIDを「7」か「8」とした場合「VT300_Series」になる。
4. TermIDを「5」か「6」とした場合「VT200_Series」になる。
5. TermIDを「2」か「3」か「4」とした場合「VT102」になる。
6. TermIDを「0」か「1」とした場合「VT100」になる。

OpenVMSに接続する場合、どのVT互換として利用すれば良いのかは、迷うところです。VT220などのキーボードは、IBM-PCのキーボードとは（似ていますが）重要なキー（DOキーなど）に差異があります。このハンドリングをRLoginで対応できるのかを、見極めなければならないと思います。

SSHのエージェント転送をTera TermやRLoginで実行

SSHの秘密鍵を多数の接続先に置かないで済むため、エージェント転送をおこなうにはU*IXならば次のような手順となります。

1. ssh-agentを実行しておく。
2. ssh-addで秘密鍵を登録しておく。
3. sshで接続する際にオプション「-A」を指定する。

これは接続元がU*IXの場合の手順ですが、もし接続元がWindowsなら手順はどうなるのでしょうか。

端末エミュレータとしてRLoginを使うなら、接続設定において「サーバー」>「プロトコル」で「エージェント転送を有効にする」を指定するだけです。とても簡単です。

端末エミュレータとしてTera Termを使う場合はどうでしょう。RLoginのように簡単なのかと思って、SSH認証において「エージェント転送する」を指定しましたが、これでは駄目で、以下のようなエラーが出てしまいました。

Permission denied (publickey,keyboard-interactive).

どうやらU*IXの手順で必要だったssh-agentやssh-addに相当するものが無いと駄目のようです。

1. ssh-agentに相当するのはPageantというソフトのようです。これはWinSCPに不増kしていたものを使いました。元々はPuTTYに付属するようですが、事情はよくわかりません。
2. ssh-addに相当するのはPageantに秘密鍵を登録することです。
3. Tera Termで「エージェント転送する」を指定するという行為は、オプション「-A」を指定することに相当するのでしょう。

Tera Termの挙動はU*IXでの手順とおなじですが、RLoginの方が使い勝手が良い気がします。

SSHを鍵認証する場合の鍵作成の方針とは？

SSHで鍵認証を利用する際に必要となる秘密鍵・公開鍵は、どのような方針で作成するものなのでしょうか？ssh-keygenで鍵を作成するわけですが、コマンドを打てば鍵が出来てしまいますが、それがSSH鍵認証で想定している方針に合致しているとも限らないわけです。

ssh-keygenで作成した公開鍵は、以下のような形をしています。右端にあるのはコメントでオプションで変更することができますが、デフォルトでは鍵を作成したユーザ名が入ります。

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABErI+RbZ foo@bar.com

このデフォルトで与えられるコメントを考えると、鍵は「ユーザ（とホスト）」を単位に作成されるものと考えるのが基本なのかと思います。SSH鍵認証の入門レベルの説明としては、それで構わないと思います。しかし現実の環境において、多数のサーバを扱う管理者であれば、どうなってしまうのでしょうか。サーバが何十台もあったとしても、各サーバでssh-keygenを用いて鍵を作成することは可能でしょう（サーバ上に秘密鍵を置くことの是非はあるかもしれませんが）。作成された公開鍵を全サーバに配置していく作業は（できるかもしれませんが）大変です。さらに作業が大変か否かという実務的な問題だけではなく、各サーバに秘密鍵が置かれていることがセキュリティ的に妥当といえるのかという問題もあるでしょう。

このような問題はssh-agentとssh-addを利用することで解決できそうです。「エージェント転送」を使えば、クライアントマシンだけに秘密鍵を置いておけば、その他のサーバに秘密鍵を置く必要がなくなるようです。

管理者が使用しているクライアントマシンで鍵を作成しておけば、全サーバでは鍵を作成しなくて良くなるのですから、これで疑問は解消したと言えるのでしょうか。つまり鍵は「個人」を特定するものなのでしょうか。

それでは管理者が複数のマシンをクライアントとして利用している場合には、どうなるのでしょうか。鍵が「個人」を特定するのであれば、同一管理者が使用する全クライアントマシンでは、秘密鍵を使いまわすことになります。それでも構わないのかもしれませんが、そのような運用を認めると、複数の管理者で秘密鍵を使いまわすことに繋がる恐れもないとは言えません。

運用次第で何とでもなるという話ではなく、SSH鍵管理の発想とは何だったのかという事を知りたいと思います。

Tera TermでもRLoginでもOpenVMSの利用に問題はないのか

Microsoft Windows上で使う端末エミュレータは、昔からTera Termを利用していました。しかし接続先の日本語環境をUTF-8にすると、（何かの設定が悪いのだと思いますが）ちゃんと日本語が出なくなりました。そこで代わりとなる端末エミュレータを探すとRLoginに辿りつきました。それ以来、Tera Termを使うことは無く、もっぱらRLoginを利用していました。

最近OpenVMS Alpha 8.4-2L1をインストールし始めた際にも、RLoginで接続していました。コマンドライン操作をしている分にはRLoginでも別に差し支えありません。ところがスクリーンエディタを利用しようとすると、ちょっと問題が出てきました。

OpenVMSのスクリーンエディタは、VT端末のキーボード配置を期待して操作するようになっています。今日のパソコンのキーボードと似ていますが、ファンクションキーの配置など多少キー配置が異なっています。RLoginでVT端末と同一の操作をするためには、何か設定すれば良いのか、そもそも不可能なのか、よくわかりません。そこで最近は利用していなかったTera Termを使ってみました。VT端末のキーボードとの対応関係を理解しておく必要はありますが、少なくともVT端末と同等の操作をすることができます。

接続先によってTera TermとRLoginを使いわける事は避けたいと考えています。できればRLoginに統一したいのですが、そううまくいくかどうか調査してみようと思います。