2020-10-24

劇場版 銀河鉄道999

2020年10月4日にBS12で「劇場版 銀河鉄道999」が放送されたので(録画しておいて)観てみました。有名な作品なので大体の内容は知っていたのですが、以前に観た記憶はないので、最初から最後まで通してみたのは初めてです。おおまかなストーリは、母親を機械伯爵に殺された少年(星野鉄郎)が機械の身体を貰えるという星に行くため、銀河超特急999号にメーテルと一緒に乗車して旅を続ける、という話だったと思います。1979年公開なので、40年ほど前の作品です。


鉄道が出てくる作品ですが、鉄道ファン向けの作品という訳ではないでしょう。しかし鉄道ファン的に鑑賞することは可能だと思います。そのような視点で考えると、まず「超特急」というのが時代を感じます。1964年に開業した東海道新幹線で「超特急ひかり号」が登場(ちなみに「こだま号」は特急です)しました。特急よりも速いのが「超特急」というイメージです。今日の東海道新幹線の主役は「のぞみ」なので、「ひかり」に過去の輝きは失われています。


また1979年頃は、鉄道を趣味とする人は「鉄道ファン」もしくは「鉄道マニア」と呼ばれていたのではないかと思います。その後「鉄道オタク」という呼び方が生まれ、さらには「鉄ちゃん」などの呼び方もされ、最近では細分化して「乗り鉄」とか「撮り鉄」のような「○○鉄」という呼び方が多くなっています。そう思うと、主人公である星野鉄郎はメーテルから「鉄郎」と呼ばれていますが、もっとカジュアルに「鉄ちゃん」と呼ばれる可能性だってあったかもしれません。そういう呼び方になると、なんだかなぁという気もしますが。


999号を牽引したのは(見かけ上だけですが)「C62」の姿をしています。現実のC62は東海道本線などの幹線で優等列車を牽引した名機です。しかしSLの代表がC62なのかと考えると、そうも言えないところがあるのではないでしょうか。「デゴイチ」の愛称で有名な「D51」の方が蒸気機関車の代表のような気もします。しかし銀河超特急999号の牽引機がD51では物語にならないとは思いますので、C62で良かったのでしょう。

VSIから新しいPAKが届いた

VSIが提供するCommunity License Programを利用してOpenVMS Alpha 8.4-2L1を利用しています。先日新しいPAKの連絡が来ました。


PAKを更新する必要のある積極的な理由はありませんでしたが、入れ換えておきました。

Active licenses on node PWS500:

------- Product ID --------    ---- Rating ----- -- Version --

Product            Producer    Units Avail Activ Version Release    Termination

ALPHA-LP           VSI             0  H     0      0.0  (none)      20-SEP-2021 

ALPHA-SYSTEM       VSI             0  A     0      0.0  (none)      20-SEP-2021 


2020-10-21

西村義樹・野矢茂樹『言語学の教室』を読んで

放送大学で受講中の「新しい言語学('18)」の第2章で参考文献としてあげられていた『言語学の教室』を読んでみました。この本は対談形式で書かれていますが、リアルな対談ではないようです。本書には「付録――対談のひとこま」として、リアルな対談のやりとりが掲載されています。本書全体がリアルな対談だと冗長だったりするので、手を入れているということのようです。したがって、著者が書き下した文章ではないが、発言(を基にしているものの)した言葉そのものというわけでもない形式です。

それはともかくとして、全体として興味深く読み進めることが出来ました。本書には「哲学者と学ぶ認知言語学」という副題がついています。しかし本書を読んだからと言っても、「言語学」や「認知言語学」の入門にはならないでしょう。そのような分野に入門するための「入り口」ではないかと思います。

2020-10-17

『ソシュール超入門』(ポール・ブーイサック/【訳】鷲尾 翠)を読んで

放送大学教養学部で受講している「新しい言語学('18)」の中で「近代言語学」の”父”としてソシュールについて記されています。ソシュールの名前は、これまでも目にしたことがあり、本人が書いたわけでもない『一般言語学講義』が代表作と誤解もされています。


ソシュールについて概要を押さえておこうと思い図書館に行ったら『ソシュール超入門』を見つけたので、読んでみました。「第1章 ソシュールの最終講義」から読み始めたら、なにやら日記のような時系列の記述がはじまったので面喰いましたが、そこで投げ出さず最後まで読了しました。人によって良し悪しの評価は分かれるでしょうが、「超入門」としては悪くないのではないかと思います。もっと深く知りたいのであれば、さらに類書に進めば良いと思います。入門段階で、右も左もわからないので、難解な専門用語が出てきて、読む気を失くすよりも、よほどマシだと思います。

『はじめての構造主義』(橋爪大三郎)を読んで

放送大学教養学部で 2020年度第2学期は「新しい言語学('18)」を受講することにしました。講義の第1回は、「新しい言語学と言うからにはその前の言語学がある」ということで、これまでの言語学の歴史について説明がありました。


そこで出てきたのが「構造主義」です。「構造主義」とか「ポスト構造主義」という言い方は、論文を読んでいると目にすることがあります。関係する人物としてレヴィ・ストロースの名前が挙げられますが、結局なんなのか良くわかりませんでした。


図書館で入門書を探したところ、講談社現代新書898の『はじめての構造主義』(橋爪大三郎)を見つけたので読んでみました。出版されたのは昭和63年ですから、30年以上前の書籍です。しかも以下のような記述もあり、もはや構造主義(とポスト構造主義)は過去の話にすぎないのかもしれません。

ところで最近では、「ポスト構造主義」というのが主流です。「ポスト」とは「それ以後」といういみですから、構造主義なんかにいまごろまだひっかかっているようでは、”遅れてる”もいいところでしょう。だいいちポスト構造主義でさえ、もうけっこう”古い”わけです。


古い話を今頃になって勉強する意義はともかく、本書を読んで、なんとなく構造主義の考え方や関連人物の関係が見えてきた気がします。筆者の語り口は、新書だからかもしれませんが、普通の学術書に比べれば、くだけています。わかりやすくしようという試みのひとつなのかもしれません。


本書は入門書なので、これを読んだだけで構造主義について完全な理解が得られるわけではないと思いますが、十分に「入門」の役割をはたしていると思います。さらに深く知りたいのであれば、本書を基礎に、別の書籍を読み進めていけばよいのでしょう。


2020-10-09

pythonのargparseモジュールでコマンドラインで指定した文字列を数値に変換するロジック

Pythonを利用して簡単なツールを作成しているところです。ツールを組むにあたり、Pythonが標準的に提供しているモジュールを活用することを基本とし、同じようなロジックを自前で作らないようにしたいと考えています。この方針のもとに、コマンドライン引数を解釈するのはモジュール「argparse」 を、ログ出力にはモジュール「logging」を使用しようと思っています。


モジュール「logging」では、ログレベルの表記と数値が「16.6.2. ロギングレベル」で定められています。例えば「DEBUG」なら「10」、「WARNING」なら「30」のようになります。このようなログレベルをコマンドライン引数で指定できるようにしたいのですが、考えておく必要のある事項があります。

  1. コマンドラインでは文字列(「DEBUG」など)を指定したとしても、ツール内部では対応する数値(「DEBUG」が指定されたのであれば「10」)で処理したい。
  2. どの文字列がどの数値に対応しているのかという「知識」をユーザが持つ必要が無いようにしたい。

モジュール「argparse」ではメソッド「add_argument()」において「choices」を使えば、考えているような事ができると思います。しかし注意しておかなければのは、選択肢を「choices={'debug', 'warning', ...}」のように定義すれば、考えているような形でコマンドライン引数を指定することができます。ただしモジュール「argparse」のメソッド「parse_args()」の結果としては、変数に格納される値も「文字列」になってしまいます。これを対応する数値にする方法はないか考えてみました。

当初はメソッド「add_argument()」の仕組みの中で対処しようと考えていました。例えば「choices」に指定しておくのは対応する数値の方にしておき、「type=lambda s: myfunc(s)」のようにしておけば、自前の関数「myfunc()」の中で「コマンドラインで与えられた文字列を、対応する数値に変換」することができるようになります。これで意図した動作をするのですが、もしコマンドラインでオプション「-h」を指定すると表示されるヘルプメッセージでは、選択肢として「数値の列」が出てきてしまいます。この問題は「metavar」を使えば対処できます。

これで問題が全て解決したかと思いましたが、まだ問題が残っていました。もし選択肢にない文字列をコマンドラインで指定した場合、エラーメッセージ「invalid choices」が表示され、そこでは正しい選択肢として「choices=」で指定している情報が出力されます。それは「数値」であり「文字列」にはなっていません。モジュール「argparse」の実装(/usr/lib64/python3.6/argparse.py)を確認すると、以下のようになっていました。この問題はモジュールの実装に手を入れない限り解決できないようです。

def _check_value(self, action, value):
# converted value must be one of the choices (if specified)
if action.choices is not None and value not in action.choices:
args = {'value': value,
'choices': ', '.join(map(repr, action.choices))}
msg = _('invalid choice: %(value)r (choose from %(choices)s)')
raise ArgumentError(action, msg % args)


モジュール「argparse」の仕組みの中では問題を解決することはできませんので、モジュールの外で対処するしかなさそうです。その結果として以下のようなロジックにしました。これならば意図していたような動作にはなりそうです。

#!/usr/bin/python3

import argparse
import logging

def parseArgv():
        loglevel = {'debug':10,'info':20,'warning':30,'error':40,'critical':50}
        parser = argparse.ArgumentParser()
        parser.add_argument('-l', '--level',
                choices=loglevel.keys(),
                default='info',
                type=str.lower,
                help='log level not case sensitive (default: %(default)s)')
        parser.add_argument('-v', '--version',
                action='version',
                version='%(prog)s 1.0')
        args = parser.parse_args()
        args.level = loglevel[args.level]
        return args

def outputLog():
        # create logger
        logger = logging.getLogger(__name__)
        logger.setLevel(logging.DEBUG)

        # create console handler
        handler = logging.StreamHandler()
        handler.setLevel(logging.DEBUG)

        # create formatter
        formatter = logging.Formatter(
                '%(asctime)s %(name)s:%(levelname)s:%(message)s',
                datefmt='%Y/%m/%d-%H:%M:%S')

        # add formatter to handler
        handler.setFormatter(formatter)

        # add handler to logger
        logger.addHandler(handler)

        # application code
        logger.setLevel(args.level)
        logger.warning('Watch out!')
        logger.info('I told you so')
        logger.debug('often makes a very good meal of %s', 'visiting tourists')

if __name__ == "__main__":
        args = parseArgv()
        outputLog()
#[EOF]

2020-10-07

VMware上のCentOS7でavahiを試す

DHCPでアドレスが割り当てられたマシンに対してホスト名でアクセスできるようにするためにはavahiが使えるという情報を得ました。そういうパッケージが存在することは耳にしていました。しかし、どのような設定をすれば良いのか、 何が出来て何が出来ないのか、よくわかりません。そこでVMwareでCentOS7を動かして実験してみることにしました。


設定の参考にしたのはWebで見つけた記事「 CentOS 7でmDNS(Avahi Daemon)を有効にする」です。やる事はシンプルです。設定後に念のために再起動しました。

  1. yumでavahiを入れる。
  2. avahi-daemonを有効にする。
  3. ファイアウォールでサービス「mdns」を通す。


ここでWindows10からpingを飛ばしてみます。すると反応がありました。すばらしい。

C:\Users\FURUSAWA>ping -4 vmware.local

vmware.local [192.168.1.17]に ping を送信しています 32 バイトのデータ:

192.168.1.17 からの応答: バイト数 =32 時間 <1ms TTL=64

192.168.1.17 からの応答: バイト数 =32 時間 <1ms TTL=64

192.168.1.17 からの応答: バイト数 =32 時間 <1ms TTL=64

192.168.1.17 からの応答: バイト数 =32 時間 <1ms TTL=64

192.168.1.17 の ping 統計:

    パケット数: 送信 = 4、受信 = 4、損失 = 0 (0% の損失)、

ラウンド トリップの概算時間 (ミリ秒):

    最小 = 0ms、最大 = 0ms、平均 = 0ms


それでは逆にCentOSからWindows10に向かってpingを投げてみましたが、うまくいきません。コマンド「avahi-resolve」ではIPアドレスが見つかっているのに、pingでは名前をわかってくれません。ファイル「/etc/nsswitch.conf」にはmDNSを見に行くように指定している(つもり)なのですが、他にも何かする事があるのでしょうか。
[root@vmware log]# avahi-resolve -n windows10.local
WINDOWS10.local  192.168.1.31
[root@vmware log]# ping -4 windows10.local
ping: windows10.local: Name or service not known
[root@vmware log]# grep '^hosts:' /etc/nsswitch.conf
hosts:        files mdns_minimal [NOTFOUND=return] dns myhostname

2020-10-06

変体漢文とJapanese English

放送大学教養学部で2020年度第2学期は「漢文の読み方('19)」 (宮本 徹・松江 崇)を受講することにしました。そこで図書館に行き、参考になるような書籍を探し、『漢文と東アジア―訓読の文化圏』(金 文京)を借りてきました。日本語を表記するために漢字は欠かせませんし、中学高校でも漢文の授業があります。漢文を読むために訓読がありますが、よく考えると「訓読」は日本だけではなく、漢文の影響を受けた東アジアでは(訓読とは呼ばないとしても)同様のことがおこなわれたハズです。


学校で習う漢文の時間では軽く流してしまうような事柄についても、本書では実例を踏まえて詳述されており、とても興味ぶかく読了しました。


「第3章 漢文を書く/2 さまざまな漢文」の192~194頁では「変体漢文の分類」として、変体漢文が生じる理由として4つに分類されています。

  1. 書き手が未熟で、規範的漢文を書くつもりが、変則的になってしまう。
  2. 母国語の語法が無意識に反映される(これを日本では「和習」とか「和臭」と呼ぶようです)。
  3. 母国語の語法を意識的に反映させる。
  4. 漢字を表音的に用いて自国語を記述する。

変体漢文というのは規範的な漢文に対する用語です。日本人が漢文だと思っているのは古代中国語に相当しており、(本書によれば)近現代の中国語とは違うもののようです。

それはともかく、変体漢文が生じる理由は、今日において日本人が英文を書こうとしたときにも生じているのではないでしょうか。1番目の理由のように、「書き手が未熟で、規範的英文を書くつもりが、変則的になってしまう」ことを「ブロークン・イングリッシュ」と呼ばれています。2番目の理由のような「和習や和臭」のことを「Japanese English」と呼ばれていると思います。

いつの時代でも、どのような外国語でも、生じる現象は同様であるようです。

2020-10-05

Windows10 2004はまだか

Windows10の次期アップデート「20H2」が間もなくリリースされるという情報があります(まもなく登場のWindows 10のアップデート「20H2」でこう変わる)。これは「安定性と品質を重視した「マイナーアップデート」となる。このため、新機能は細かいものばかりだ」との情報がありますが、それ以前にアップデート「2004」が届いていません。


Windows10 2004が未だに届いていないユーザは他にもいるようです。

  1. Windows 10 Ver.2004 が配信されてこない」(2020年9月23日)
  2. Windows 10 バージョン2004(May 2020 Update)が未だにこない件」(2020年9月30日)

アップデート「2004」が届かないままに「20H2」がリリースされた場合、未だにアップグレード「1909」のままのマシンは「2004」がスキップされるのでしょうか。それとも、まず「2004」がインストールされ、次いで「20H2」がインストールされることになるのでしょうか。


そもそもWindows10のアップデートが約半年ごとにリリースされるというのは、マイクロソフトの方針に過ぎないのです。半年ごとでなければならない理由がユーザ側にある訳ではありません。1ヵ月ごとだろうが1年ごとだろうが、マイクロソフトの方針として実現させてくれればよいことです。それなのに半年たってもリリースされないような状況が生まれるのは、いったいどうなっているんだと思います。

2020-10-03

VT端末で使われるLK201キーボードを意識したRLoginにおけるキー配置

OpenVMS Alpha 8.4-2L1にRLoginを用いてSSH接続することが出来るようになりました。コマンドラインで普通にキー入力している分には問題になりませんが、エディタを使おうとすると多少厄介な問題があります。


OpenVMSはDEC製なので、端末もDEC製のVTシリーズが利用されます。VTシリーズで使われる標準的なキーボードLK201はファンクションキー等の配置がPCで使われているキーボードとは異なります。両者の違いをどのように吸収して配置するかを考えなければなりません。


まずLK201のファンクションキーは20個ですが、PCは12個しかありません。そこでPCのファンクションキーF1~F10を使って対応付けます。

  1. PCのF1~F10を、LK201のF1~F10に対応させます。
  2. PCのF1~F10を「ALT」キーと共に押した場合、LK201のF11~F20に対応させます。

LK201はテンキーの上の段の4個をPF1~PF4として扱います。このようなものはPCのキーには存在しません。そこでPCのF1~F4に割り当てることにします。これでは上述したファンクションキーと重なってしまうように思えます。しかしVTではF1~F5は特殊目的に使われているので、問題ないでしょう。

VTではF15を「Help」、F16を「Do」として扱います。エディタでも良く使われます。そこでこの2個をF11とF12に割り当てることにしました。当然ながらALTを押しながらF5やF6を押しても同等のはずです。


以上のような方針でRLoginのキー配置を変更します。デフォルトではVT52に対応させる設定が入っていますが、全て削除しました。 

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にSSH接続する

RLogin 2.25.5(2020/09/25)でOpenVMSにSSHで接続する設定を行いました。


普通にSSH接続のための設定をおこなうことで無事に接続できて、それは良かったのですが、ログアウトしようとすると問題がおきました。 


ログアウトすると「ssh Receive 'CBuffer Get32Bit'」というダイアログが出てきて接続が閉じません。仕方ないのでメニューから[ファイル]>[接続を閉じる]をおこなうと「現在、接続中です。接続を閉じますか?」というダイアログが出てきます。ここで「はい」を選べば、接続は閉じますが、釈然としません。

C:\Windows\System32\OpenSSH\ssh.exeでOpenVMSにSSH接続する

C:\Windows\System32\OpenSSH\ssh.exeでOpenVMSにSSH接続しようとしたらエラーが出ました。

C:\Users\FURUSAWA\.ssh>ssh -i id_rsa furusawa@192.168.1.161

Unable to negotiate with 192.168.1.161 port 22: no matching key exchange method found. Their offer: diffie-hellman-group1-sha1

C:\Users\FURUSAWA\.ssh>


エラーメッセージを頼りにWebを検索したら「macでssh接続をしたときno matching key exchange method found. Their offer: diffie-hellman-group1-sha1と言われて接続できない」という情報が見つかりました。この記事によるとファイル「config」を作成すれば良いようです。その通りにしたところ、無事に接続できました。

C:\Users\FURUSAWA\.ssh>type config

KexAlgorithms +diffie-hellman-group1-sha1

C:\Users\FURUSAWA\.ssh>ssh -i id_rsa furusawa@192.168.1.161


 Welcome to OpenVMS (TM) Alpha Operating System, Version V8.4-2L1

Enter passphrase for key 'id_rsa':


    Last interactive login on Saturday, 3-OCT-2020 15:20:29.27


$ logout

Connection to 192.168.1.161 closed.-2020 15:21:03.67

C:\Users\FURUSAWA\.ssh>


2020-10-02

OpenVMS Alpha 8.4-2L1のSSH設定

OpenVMS Alpha 8.4-2L1に対してWindows10からSSH接続できました。設定する上で注意が必要な点が幾つかありました。

C:\Users\FURUSAWA\.ssh>ssh -i id_rsa furusawa@192.168.1.161

 Welcome to OpenVMS (TM) Alpha Operating System, Version V8.4-2L1

Enter passphrase for key 'id_rsa':


    Last interactive login on Friday, 2-OCT-2020 11:03:16.17


$ logout

Connection to 192.168.1.161 closed.-2020 12:05:27.60

C:\Users\FURUSAWA\.ssh>


最も注意しておくべきなのは、TCP/IP Services for OpenVMSにおけるSSHはOpenSSHではないことです。Webを検索した場合、OpenSSHを前提とした情報が多く見つかるので、それを鵜のみにして設定作業をおこなっても、うまくいかないでしょう。設定作業の参考になったのはWebで見つけた記事「SSH public key authentication on OpenVMS」でした。


OpenVMSで使える鍵にED25519は利用できません。最近のOpenSSHではED25519が使えるので、他のサイトに入るための鍵に僕はED25519を使っています。それとは別にRSAなどで鍵を準備しなければなりません。


最近のWindows10では標準でOpenSSHが入っているようです。

C:\Users\FURUSAWA\.ssh>C:\Windows\System32\OpenSSH\ssh.exe -V

OpenSSH_for_Windows_7.7p1, LibreSSL 2.6.5


これを使ってRSA鍵を作ります。このままではOpenSSH形式なので、SECSH形式に変換します。

C:\Users\FURUSAWA\.ssh>ssh-keygen

(略)

C:\Users\FURUSAWA\.ssh>ssh-keygen -f id_rsa.pub -e > id_rsa.secsh


OpenVMS側には、Windows10で作成したSECSH形式の公開鍵を置きます。ファイル名は変えなくても構いません。しかしOpenSSHでは~/.ssh/authorized_keysに公開鍵が格納されるのでファイル名を気にする必要がありませんでしたが、OpenVMSでは独立したファイルとして置かれるため、秘密鍵のあるサイトを連想しやすい名前にしておいた方が(必須ではありませんが)無難です。

$ dir/sec

Directory KAZ$USER:[FURUSAWA.SSH2]

AUTHORIZATION.;1     [FURUSAWA]                       (RWED,RWED,RE,)

FURUSAWA-WINDOWS.PUB;1

                     [FURUSAWA]                       (RWED,RWED,RE,R)

Total of 2 files.

$ type authorization.;

KEY FURUSAWA-WINDOWS.PUB


以上の設定で、Windows10からOpenVMSにSSHでログインできました。