駄文。

プログラマーの日常でつまずいたこと・気づいたことなどの記録です

pythonとクライアント証明書認証とhttp通信

ひさびさにプログラミングネタです。このネタなら毎日書けると思ってブログを始めたのですが 意外に書けないものでした。

さて、本日のネタはpython

pythonでクライアント証明書認証でhttp通信をしようというものです。 基本的に よく使われるrequestsやhttpxでサポートされているので、 証明書ファイルがあれば簡単。

requests*1の場合にはSessionオブジェクトに証明書情報を設定すれば あとは普通にhttp処理を書けばOK。

証明書情報は、以下の順に設定する

  1. クライアント証明書
  2. 秘密鍵

証明書、秘密鍵はpemフォーマットで保存されたものが良い。 秘密鍵パスフレーズを設定してるものはrequestsではサポートされていないので 事前にパスフレーズを解除しておく必要がある

from requests import Session

session = Session()
session.cert = ("./client.pem", "./privkey.pem")
session.get(url)

httpx*2の場合もほぼ同様 ただ、httpxの場合にはパスフレーズ付きの秘密鍵をサポートしており、certを指定する情報の3番目にパスフレーズを設定することが可能になっている。

from httpx import Client

client = Client()
client.cert = ("./client.pem", "./privkey.pem",  "passphrase")
client.get(url)

まぁ、これだけならブログにあらためて書いて共有する話でもないのだが。 というか、ぐぐりゃいいじゃんってことなのだが、これからが言いたいところ。

証明書情報をファイルでしか指定できないのはどうかと思う。

秘密情報をファイルで不揮発化するなんて。。。

秘密情報をファイルで不揮発化するなんて。。。

秘密情報をファイルで不揮発化するなんて。。。

大事なことなので、3回言いました。

せっかくクラウドで秘密情報管理(AzureならKeyVaultとか)で管理しているのに ローカル環境に不揮発化しないと認証できないとか、絶句。

と、なりこの記事に至っているわけである。

なんとか、オンメモリでのデータで引き継げないかとか調べていたのだが まぁ、ほぼクライアント証明書認証は外部のライブラリ実装依存になって いるぽく、調べた限りファイル以外に選択肢がないのがPythonの現状でした。

PowerShellですらできるのに...

残念です、Python...

いずれできるといいな。

sshとzshとホスト名補完

最近、SSHの環境をちょっとずつ改善してきている。

以前まではVSCodeがらみの改善でしたが今回はshell。

zshsshを実行する時にホスト名を入れる際に、いつも ホスト名がどうだったか悩んでしまう。

なぜかといえば、sshのconfigファイルでホスト名をalias しているが、まぁ、いつもいい加減に名前をつけている せいである。

VSCodeはconfigで定義したホスト名が一覧で表示され それを選択するだけで良かったので、それでも良いが zshではそうはいかず、いつもなんだっけと思い返す時間 キーボード操作が止まってしまっていた。

ふと、キーボード入力時にホスト名を補完してくれれば 最高なのにと思って、ネットで調べるとありました。

以下の2行を.zshrcに仕掛ければあら不思議、先頭数文字 入れるだけでconfigで定義しているホスト名を補完したり 候補の一覧を表示してくれるようになった。

autoload -U compinit
compinit

これでいい、これがいい。

VSCodeとGithubと秘密鍵のパスフレーズ

前回VSCodeを記事にした。

ついでにもう一つ書いておく。 VSCodeでは開発系エディタなのでGitのサポートもされている。

GitHubのレポジトリをsshプロトコルでcloneすると公開鍵で認証されるので操作する時にパスワードが 求められないので非常に重宝している。

非常に使い勝手が良いので一緒に作業する人にも勧めているのだが ある時、ある人がうまくGitのPush操作がうまくいかない人が出てきた。

commit操作はできるだが、サーバにpushしようとするとエラーが出て うまくいかない。 直前に同じレポジトリをhttps経由で操作してPUSHしていたので、ネットワーク的な 問題はあまり考えづらい状況(もちろんhttps/sshでポートが違うので厳密には うまくいかないケースもありますが、隣で私がsshでうまくっているのでこちら 原因は感がづらい感じ)

で、いろいろ試してみると秘密鍵パスフレーズをかけていることが判明。 念の為、パスフレーズを外してみるとあっさり問題解決。

セキュリティとしては設定しておくべきですが、意外な副作用で うまくいかなくなることもあるというお話でした。

VSCodeのリモート開発環境とSSH

開発者としての筆記用具として、エディターはもう好みがはっきり分かれるもの。 昔はEmacs一筋だった私ですが、時代と共に今はVisual Studio Codeなしには やっていけない状況です。

マイクロソフトはそんなに好きではないのですが、Visual Studio Code, VSCodeは別です。 でも、Visual Studioはそんなに好きではないです。

なにがいいかというと、いろいろあるのですが、最近お気に入りはリモート開発環境, (remote development environment, RDE)です。 リモートのサーバやコンテナ上でVSCodeがあたかも動いているように手元のデスクトップ環境で動作させることができるのです。

この接続方法が至れり尽くせりで本当に痒いところに手が届いているので、手放せなくなっています。 単純な接続方法にSSHを使ったものがありますが、よく使っていて助かっています。

ただ一点だけ、ちょっと改善してほしいなと思っていたことがありました。 SSH接続時に.ssh/configに定義されているホスト名を一覧に出したり入力時に補完してくれるのですが これがconfigファイルに書かれているものだけで、Include文で外部のファイルを参照したものは含まれ なかったのです。

まぁ、なくても困らなかったのですが先日一念発起してネットを探してみるとやっぱり同じことを思う 同志は多くネットでもいろいろ取り上げられていました。

なかでも、Include xxx/*.confといった形でワイルドカード指定だとダメだというものがあり、 実際にいままでワイルドカード指定だったのでこれを普通にファイル指定に直してみましたが 改善がなかった。

ように見えたのですが、数個Include先のホストが表示されるようになって若干糸口が見えた 感じですが。

その上で表示されるものとされないものをよくみると、設定でHostを宣言している部分を 全て大文字のHOSTと書いていると認識していないことがわかりこれを修正するとあっさり 表示されるようになった。なぜか、ほぼHOSTで書いていたため全く対応されていなかった のだ。

ふと、これが原因?と考えてIncludeをワイルドカードに直してみるとこちらもあっさり 表示された。

つまりこれが原因。

Host:と宣言する部分はHOST:でもhost:でもダメで、正しくHost:と書く必要がある ということだった。

ネットではIncludeには対応していないとか、ワイルドカードは対応していないとか ありましたが、最新版ではちゃんと対応されていたのだった。

CLIsshで直接ホストを指定する時には全くどの表記でも認識していたのでまさかのオチに びっくりだが、これからはかなり楽にホスト指定ができるようになって嬉しい。

ただ、昔の設定ファイルでHostに修正したものを最後に試したら、ダメだった。 もうちょっとダメな理由があるかもしれない。

なので、これで全てOKではないとは思うがこれをみてリモート開発環境であと一つ直して くれたらなと同じ思いを持っている人がいたら試してもらえるといいかも。

Quest3のバッテリー付きEliteストラップ、交換できました

もう、1ヶ月経ちました。*1

何が?

あ、Quest3のバッテリー付きEliteストラップです。

海外で本体とストラップのでバッテリーの給電連携が あまりうまくいかないということで交換が始まっている とのことで、実際私の小有している機器も同様の現象が みられました。

ということで、連絡してどうだったかということのレポート になります。

結果としては私の応対が遅いことがほぼ主因ですが1ヶ月 かかりましたが、無事交換できました。

さて実際の流れはは、Metaのサポートサイト*2からフォームで 充電ができない旨連絡したところ、折り返しでメールで以下の ようなやり取りの後、交換となりました。

  1. 一般的な対応方法の確認と充電時のケーブル接続の写真の依頼
  2. 対応については指定方法では効果がなかったことと写真を送る
  3. 交換対応を検討するため、シリアルや購入時情報等の情報の提供依頼
  4. 不具合の可能性が高いため交換手続きに入る旨の連絡

その後交換品の発送手続きがあり、1週間程度で手元に。

実際は1ヶ月もかかる話ではなく、Meta側としては2日程度でクローズを 目指しており、密に連絡をすれば1週間ちょっとで手元に交換品がとどく 流れになっている気がしました。

ということで、発売早々にバッテリー付きEliteストラップを購入した方で うまく本体へ給電ができていないという方はサポートに連絡してみると よいでしょう、という報告でした。

三たびvCenterの証明書更新

vCenterの証明書の更新は3ヶ月おき。

もうすでに毎度のことなので心配せず、SSHでvCenterにログインしてコマンドで更新すればと 安易に考えてたら、今回もしっかり罠にハマって手間取ってしまった。

よく考えたら2つの問題に出くわして解決に2週間かけてしまった。

一つ目は、証明書にワイルドカードが使えないということ。 すっかり忘れてワイルドカード証明書を適用してエラーになってしまった。

これがケチのつき始め。

この後、証明書のロールバック処理がうまくいかず散々な目に遭うことに なるのである。

さて、証明書をワイルドカードだとダメということでvCenterのFQDNを 設定した証明書を再設定してみる。

そうするとなぜだか、エラーになってしまい設定がロールバックして しまうのだ。

この状態になるともうGUI側のvCenterサーバが起動されなくなり、 GUI側からのオペレーションを受け付けなくなりかなり追い込まれて いくことになる。

どうしようもなくなり、ネットを調べるとvCenterを別VMでrestoreする 方法が見つかりこちらも試してみるが、証明書が期限切れで最後のサービス 起動でセットアップが失敗してしてしまう。

dateコマンド等で日付をもどして証明書期限内と誤認識させてサービス 起動を試すがこちらもうまくいかず、ヤァ万策尽きたって状況。

しょうが無いのでこちらの方法はあきらめ元のvCenterで証明書を リセットする方法を試してみるとこちらはうまくいった。

ようやくvCenterがGUIで起動できるところまで復旧。

ただ、自己発行証明書なので使い勝手が悪くどうしてもちゃんとした 証明書にしたい。

ということでネットを調べるとどうも私が認識していた証明書の 割り当てがおかしい感じなのである。これが2つ目の罠。

CLIで最初に設定するサーバ証明書には fullchain.pemを指定し (以前は cert.pemを指定した)、ルート証明書チェーンについては chain.pem(以前はfullchain.pemを指定した)と指定し直すと あっさり更新できた。

そもそも最初からこちらの指定パターンで設定していたら 何の問題もなく更新ができていた可能性が高い。

ファイル指定の件については3ヶ月後に再度検証してみることとするが、 かなり遠回りしたが無事目的が達成できてよかった。

Quest3のバッテリー付きEliteストラップの初期のものは不具合があるらしい

なんとなくはそう感じていた。 そう、感じてはいたのですが、なんとか誤魔化して使えていたので気がつかないふりをしていた。

でも、記事*1を見てしまったからしょうがない。

どうやら海外では不具合を認めて交換が始まっているらしい。

なんの話かと言えば、Meta Quest3のバッテリー付きEliteストラップのことである。

これに不具合があり、どうやら海外ではMetaが正式に不具合を認めて交換を始めているらしいのだ。

どのような不具合かというと、バッテリーと本体の充電・給電の連携がうまく取れず 本体にうまく充電されないというものらしい。

実際私の経験で行けば、本体のバッテリーが異常に少ないにもかかわらず ストラップ側のバッテリーがほぼ残っていて結局電池切れになって本体が 落ちたりする。

とはいえ、いつもそうかと言えばそうでもない。

でも、たまに起こるのであるがそういう時は大概本体側のバッテリーが かなりなくなっていて、バッテリーがあまりありませんの警告がでた 時なのである。そんな時は本体側にUSBケーブルで充電を始めても手遅れ なのでちょっとイライラするわけである。

まぁ、海外でと注意書きがあるが日本でもきっと同じような取り扱いに なりそうなので明日にでもMetaのサポートに問い合わせてみよう。

これでもっと使い勝手が上がれば最高である。

なんたってこんな状況でも毎日使い続けられるぐらい良い製品なのだから。


update 2024-01-05

無事交換できました。*2

参考情報