旅とプログラミングを少々

趣味に関する記録などをします。さしあたっては2017年JGC修行とプログラミング入門に関しての内容を連ねていきます。

Yubikey5にssh用秘密鍵を置く

貸与されたPC等自分のgithubアカウントにアクセスできると便利だが絶対に秘密鍵を置きたくない環境で使うための鍵ペアを準備した
自己同一性の証明用鍵のサブキーではない場合、意外と簡単だった

下記脆弱性のため、2017年6月以降に出荷されたYubikeyであることを確認してから実行すること Security Advisory 2017-10-16 | Yubico

環境

手順

  1. 必要な、あるいは便利なプログラムをインストールしていく
  2. Yubikey as OpenPGP card の PINを設定する
  3. YubiKey上で鍵生成する
  4. ssh公開鍵を確認し、登録する
  5. 生成した鍵をssh鍵として使う

プログラムのインストール

apt install gnupg2 gnupg-agent scdaemon pinentry-gnome3 (pinentry-guiならなんでもいい) 

PINを初期設定から変更する

gpg2 --change-pin

初期設定はPINが123456、Admin PINは12345678なので変更する。

鍵設定する

gpg2 --card-edit

gpg cardとのCLIに入る

gpg/card> help  

このカードでgenerateできる事を確認して、 *1

gpg/card> admin  
gpg/card> generate  

適切に答えていって4096bit RSA鍵を作る。今回は単にgithubと自分の管理するサーバのssh鍵の代わりに用い、pgp上のアイデンティティを想定していないのでオンラインのパソコンでそのまま作り、秘密鍵のバックアップをドライブ上に一切作らない。失くしたらauthorized_keysから消すのみである。
また、sshで使うためにはauthentication機能だけで良いのだがgpg cardに詳しくないためsign等用の鍵も生成してしまった。
エントロピー生成のためにいろいろしながら過ごして待つ。一所懸命に何か入力して過ごしてもそこそこ時間がかかるので、Yubikeyを反射的に抜いてしまわない限り他の事をやって鍵の事を忘れるくらいでいい。(1敗。運良く特に壊れなかった。)

gpg: key <key id> marked as ultimately trusted  

これでgnupgのキーリングで対応する公開鍵が信頼された状態となる。

ssh公開鍵を確認する

今回生成した鍵は普段の環境では使うつもりがない*2ので、gpg-agentの導入を一時的にしかしない。

SSH_AUTH_SOCK="$(gpgconf --list-dirs agent-ssh-socket)"  ssh-add -L

sshがgpg-agentのssh-agentモードに繋ぐようにソケットを変え、agentに登録されている公開鍵のリストを出す。
他にgpg-agent内に鍵がある場合はcardnoでどの鍵かを識別し、これをgithubssh鍵の設定なり必要なマシンのauthorized_keysなりに追加する。
githubにはcommit verification用のgpg鍵の設定もあるので混同しないようにする。

生成した鍵をssh鍵として使う

鍵を使う側のPCの方ではsshからgpg-agentを常用するように設定する。こちらは何が必要で何が必要でなかったのかあまりわからないが、そこまできつく縛る環境でもないので適当に入れている。

sudo apt install scdaemon gpg2 gpg-agent pcscd

環境変数の設定

# In .bashrc etc
export GPG_TTY=$(tty)
gpg-connect-agent updatestartuptty /bye

なお、こちらでもpinentry-gnome3 のたぐいを入れておいた方が多数のttyでPINを入れ直したりせずに済む。

# ~/.gnupg/gpg-agent.conf
enable-ssh-support
pinentry-program /usr/bin/pinentry-gnome3

あとはYubikeyを刺してssh-add -lしてみたり、試しにgit clone等してみて動作を確認する。

補遺

日本のマイナンバーカードの鍵なども一切利用が進まず、他のSmart Cardを使う事がないのでscdaemonのみ使用する環境を想定しているが、IT先進国ではopenscと共存させるための設定が追加で必要となるはず。

*1:gpg2 --card-info みたいなコマンドでどのような鍵を生成できるのか確認できた気もするが、詳しくない

*2:物理的に持ち歩かないタワーPC、鍵付き。USBポートまで行くのが面倒と判断

なぜYubico OTPは専門家から避けられているのか

一般の人々はそこまで深く気にしないかもしれないが、プライバシーを気にする人、例えばスノーデン氏などは絶対にYubikeyのYubico OTP(One Time Password)を使わないだろう。たとえOTPによって本人認証がよりセキュアになるとしてもだ。

Yubico OTPとはYubikeyを使って44桁のOTPを入力させることができる機能だ。YubikeyはUSBキーボードとしてOTPを入力する。ウェブサイトなどのサービスはYubicoのクラウドでOTPが有効なものかどうかを確かめる事ができる。Yubicoの言い分としては6桁のよくあるRFC 6238 TOTPよりもセキュアだそうだ。

だが、このOTPには重大な瑕疵がある。始めの数桁が固定のIDなのだ。デフォルトではYubikeyのシリアルナンバーとなっている。そしてYubikeyがキーボードを模して入力するため、信用できないサイトや通信の時でも間違えてYubikeyに触れでもしたらそのIDが漏れる。せっかく仕事のアカウントと公益通報のアカウントを分けていたとしても、Yubikeyでセキュアにしたつもりが逆に個人特定をされてしまう。

このため、Yubikeyを入手したら、うっかり触れてIDを様々な場所にばら撒かないようにYubikey Personalization ToolでOTP機能を無効化するべきだとされる。

 

# 参考

## yubico OTPの機能

https://www.yubico.com/products/services-software/personalization-tools/yubikey-otp/

## Yubikey Personalization Tool

https://www.yubico.com/products/services-software/download/

32bit版Linuxの2038年問題

一般のPCではもはや64bit CPUが当然となっているが、多様なマシンのために今も32bit版のLinuxはメンテナンスが続けられている。おそらくそういった環境では今後数回のアップデートに対応できるかどうかはシステムの寿命に関わる大事なものとなる。

2038年、2038-01-19 03:14:07 UTCの瞬間に32bitのtime_tでは時刻を表現できなくなり、時刻が1901-12-13 20:45:52 UTCへとループしてしまう。

実は既にここしばらくのカーネルアップデートで密かに対応が進んでおり、32bit版でも内部的には64bitで確保した時刻を32bitにして返している。 (2015年ごろから継続的にコードと議論が続いている https://lkml.org/lkml/2015/5/6/597 etc.)

そして間に合えば次のLinux 5.1かあるいはLinux5.2からはついにユーザー側インタフェースでもtime_tが64bitとなるオプションが追加されるのだ。

変更が入れば23個のシステムコールが影響され、新たにtime64版が提供されるようになる。大抵のソフトウェアはたいてい直接これらシステムコールの呼び出しをせずlibc経由で使っているだろうから、glibcでY2038-Incompatibleとなっている関数などを参考に64bit対応版へ置き換えを進めるか、きっぱりと32bit版をサポートしないと切り捨てていかなければならない。

 

 

参考

64bit time in 32bit system example from some kernel developers: https://git.kernel.org/pub/scm/linux/kernel/git/arnd/playground.git/log/?h=y2038-syscalls

glibc Y2038 design: https://sourceware.org/glibc/wiki/Y2038ProofnessDesign

 

 

SKKを仮に実装する場合の難しそうなところ

自分の備忘録として書いていたら既に良い例が公開されていましたので、まずはそちらへリンクを。

mzp.hatenablog.com

 

いまのところ一工夫がいるのは

1. concat; 単純なエスケープの変換
例: (^o^;)/

> owata /(concat "\(^o^\059)\057")/

/や;や*等の文字がSKK辞書に収録される際、このように収録されている。L辞書にも"I/O"のようなエントリに使われるので、なるべく対応したい。

2. #; 数値変換
SKK 16.2 マニュアル 5.5.4 数値変換エントリ
> だい\#かい /第#1回/第#0回/第#2回/第#3回/第#0回/\#回

のように、見出しの#とエントリ右辺の#と続く数字は特別な意味を持つ。

3. skk-henkan-okuri-strictly; 送り仮名の厳密マッチ
SKK 16.2 マニュアル 5.8.1 送り仮名の厳密マッチ
> おおk /大/多/[く/多/]/[き/大]/

このようなエントリに対し、"O o K i i" は "大き" のみを候補にするようにしたい。
L辞書には使われていないので、ddskk以外ではあまり実装されていないかもしれない?

4. .lisp 辞書サポート
> today /(skk-current-date)/

のようなconcat以外のLispの関数。かなりマニアックな実装だけが限定的な関数を実装している。

5. アノテーション
SKK 16.2 マニュアル 5.11
;で区切られるシステムアノテーションと;*で区切られるユーザアノテーション
L辞書に無いためユーザアノテーションは探せば既存実装でもミスがありそう。

SKKのマニュアルは

SKK Openlab - Documents

のpdfを参照しています。

Miscelous note for building IMs

Ubuntu18.04 で諸々をビルドするために必要だったパッケージ類

libskk

apt install autoconf autopoint libtool gobject-introspection valac libvaladoc-0.40-dev gtkdoc-tools

./autogen.sh --enable-docs

fcitx4

apt install extra-cmake-modules libxkbcommon-dev libxml2-dev libxkbfile-dev libqt4-dev libcairo2-dev

mkdir build && cd build && cmake .. && make && make install

fcitx5

CMakeList内でどれがどう択一なのか等まだ読めていないので、とりあえず共通部分でエラーがなくなるまで。ビルドは通らない。どうもUbuntu18.04のログインスクリーンでgdm on Waylandが使われているせいかWayland関連のライブラリを必須にしてしまっているような気がする。

libdbus1-dev uuid-dev gettext libfmt-dev

XCB-IMDKit https://github.com/wengxt/xcb-imdkit

aptで入るパッケージはまだない。

apt install libxcb-keysyms1-dev libxcb-util-dev

mkdir build && cd build && cmake .. && make && make install

Keycode and Keysym

Keycodeは物理的にどのキーが押されたかの識別子で、たとえばドイツ語キーボードでYが印字されたキーを押した時と英語キーボードでZが印字されたキーを押した時で同一の0x52。

xevで例を見れるが、英語キーボードでAと印字されたキーを押すとkeycode 0x38のkeypress イベントが起こり、Shiftと印字されたキーを押すと0x50のkeypressイベントが起こり、Shiftを押したままAと印字されたキーを押すと同じくkeycode 0x38のkeypressイベントが起きる。ただしkeystateという別のフラグによりShiftが押しっぱなしであることがわかるほか、それぞれのイベントのkeysymは 0x61の'a'と0x41の'A'と別のものになる。

人によってキーの配列が違うのでそれに対応するにはコンフィグ可能にしなければならない。それにはキーを特定する、キーに印字されている文字や機能のシンボルと、ShiftやCtrlなどのModifierに依らず一意な識別子: keycodeが必要になる。

keycodeに対応するキーの印字へのマッピングがない場合、たとえばユーザがコンフィグで機能AをCtrl+Shift+keycode 0x52に割り振った際にその設定状態を表示しようとするとA: Ctrl + Shift + 'Z' としていいのか Ctrl + Shift + 'Y'としていいのかがわからない。通常はkeycodeから無Modキー状態でのkeysymをひいて表示することになるだろう。

keycodeがない場合、たとえば機能をShift+'£'に割り振るというのはどういう事なのだろうか。アメリカの英語ユーザはそのようなキーがなくて使えないだろうし、イギリス人も古いパソコンとキーボードをひっぱり出す羽目になるかもしれない。日本のようなIMEを使う文化では変換して文字を打ち込むとその文字の代わりに機能が実行されると解釈するのかもしれない。機能を割り振りたいのはあくまでキーボードというデバイスのボタンを押した事に対してであり、テキスト入力の表記文字に対して割り振りたいわけではないはずだ。機能のわりあてはキーに対して、つまりキーごとに一意なkeycodeに割り振ることになるべきだ。

 

 

 

 

Linux IME 未整理

Linux IMEについて未整理な雑多な情報

XIM

最古のIMインタフェース, X Window System内に定義されている。

The Input Method Protocol

日本語は全部サーバ・クライアントモデル?

XMODIFIERS=@im=XXXXにて指定したものか、Root windowのXIM_SERVERSリストの先頭のものが使われることになっている。IM serverがXに自分を登録するスタイル(?) 詳細よくわからない。

今でもGTK LibやQt Libをフルに使っていないプログラムでは基本的にこれを用いて入力しているはず。

 

IM Module (総称)

各種GUIツールキットでXIMとの間をうまく取り持つ部分と、そのIMインタフェース。

Qt IM Module

不明。IM Moduleという名前はGtkと同じだが、別のインタフェース。QT_IM_MODULEで指定した名前からどのようにIM server(?) IM Library(?)がわかるのかまだ調べていない。

Gtk IM Module

こちらもよくわかっていない。GTK_IM_MODULE環境変数で指定した文字列から、どのように探索するのか調べていない。

GtkIMContext: GTK+ 3 Reference Manual

EFL Input Method Framework

ECore Input Method Frameworkというものがあるらしいがよくわからない。一応scimibusはあるのでTIZENで使われているのだろう。

efl/ecore_imf_example.c at master · turran/efl · GitHub

 

 

Wayland

Wayland text-input と呼称されている。専門家によるとまだまだ機能が不十分らしい。

Gaps between Wayland and Fcitx (or all Input methods). | CS Slayer

Google Summer of Codeで関連プロジェクト提案があったと思うが、誰もやっていない? 詳細な記録がない?

 

ibus

ibusは2013年の1.5より前と以降で別のIMと考える必要がある。

ibus before 1.5

最後発のIMとして普通に各IMプロトコルに対応し、IMEが状態を管理できた。単純にXIMからの悪い影響を排した良い橋渡しプログラムだったように見受けられる。

ibus post 1.5

ibus自体が状態を持ちそれを共有し、IMEの切り替えによって入力方式を変更する。ここまではまだいいが、GNOME (GNOME Shellというべき?)と密結合しキーボードレイアウトとIMEの組合せでしか変更できないほか、いろいろ機能がなくなっている。

多分このエイプリルフールの漢字キーボードを真に受けると良い設計。

Google Japan Blog: Google日本語入力チームからの新しいご提案

一応mozcはメインIMターゲットがibusだったため日本語変換にibusを使えなくもない程度にアップデートしたが、それ以外のIMEではそんなに重要視されていないように思える。

 

uim

wnnの頃もっとも普及していたIMで、uimに対応すればuimがxim,gtk-immodule,qt-immoduleを全部担当してくれていた(? 記憶不明瞭)

 

fcitx

fcitx4

単一のX Window serverでのみ動作する。モジュール型な設計のように見えてfcitx-gtkなどの初期fcitxからある部分はきちんと分離されていない。IMEは分離したモジュールとなっている。

fcitx5

複数のX Window serverで共有できるほか、Wayland対応を進めている。X のライブラリにXLibではなくxcbを前提としている(?)

4で分離できていなかった部分を含めてかなりの再設計になっている。IMEのインタフェースもfcitx4とは違う。

 

mozc

もずく。OSSの旧Google Japanese Input

品詞の接続コストから文節・品詞を確定し、各品詞内は統計的最頻単語を候補にするらしい。全文ではなく小範囲で変換するくせがある人間には特に「かくりつ」が常に「確立」になって、学習後は常に「確率」になってしまう奴。

ソース読んだことない。

 

kkc

かかし。OSSの新? 次期? Google Japanese Input?

単語単位でtri-gram DBを持っていて予測入力補助に活用しているらしい。小範囲での変換でもより文脈に即してくれるので「かくりつ」問題が緩和されている。

 

 

hledger-webへの移行

会計ソフトのデータを壊したのを機に、プライベートホスト可能かつwebインタフェースがある複式帳簿ソフトウェアへ移行した。備忘録として行った事を記録していく。

Ubuntuサーバーを18.04へ

個人のさほど重要でないサーバーなので適当にバージョンを上げる。さくらのVPSUbuntu 16.04をインストール後、/etc/update-manager/release-upgrades を編集してltsじゃなくともアップデート可能に

# パッケージ情報を反映させる

apt update && apt dist-upgrade

do-release-upgrade と再起動をくりかえした後, do-release-upgrade -dで開発途上のバージョンへ

ssh周りを設定

さくらのVPSiptablesの初期設定があるのでiptables -Lで眺めて障害になりそうなものを消す。さくら提供のUbuntu 16.04では/etc/iptables/iptables.rulesでINPUTへのREJECTルールをコメントアウトして-Dオプションで現在設定も変更、慣れたufwで設定しなおす。

ufw default deny incoming

ufw default allow outgoing

# sshをやたらスキャンの多いポートから変える

ufw allow *****/tcp

# すぐやるので先にweb鯖用も許可

ufw allow 'Nginx Full'

ufw enable

systemctl start ufw

ここからはコンソールではなくssh越しに作業をし、id_rsa.pubを~/.ssh/authorized_keysに加えて鍵でのログインが上手くいった事を確認し /etc/sshd_configでパスワードログイン、ルートログインを不可にする。

 自動アップデート関連

sudo apt-get install unattended-upgrades

sudo dpkg-reconfigure -plow unattended-upgrades

# 一応確認

vi /etc/apt/apt.conf.d/50unattended-upgrades

vi /etc/apt/apt.conf.d/20auto-upgrades

 必要に応じて

APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";
APT::Periodic::AutocleanInterval "1";

 とか通知やautoremoveも適当に設定。とはいえ開発版の間は自動化しない方が良かったか。

https

let's encryptを利用する。certbotのプラグインがころころ変わっていてまだ開発途上なので普通にwebrootで使う。正式版が出ても変にプラグインスクリプトで設定を書き変えられるより、こちらの方が楽ではないだろうか。

sudo apt-get install nginx letsencrypt

mkdir /var/www/letsencrypt

vi /etc/nginx/sites-enabled/設定ファイル

# 適当に使うドメインのserverに追加

location ~ .well-known/acme-challenge/ {
     root /var/www/letsencrypt;
     default_type text/plain;
}

 その後実行

 sudo certbot certonly --webroot --staging --webroot-path /var/www/letsencrypt -d example.com

 これで(staging版の)証明書をもらったのでnginxの設定を追加してまたサービス再起動

listen 443 ssl default_server;
listen [::]:443 ssl default_server;

ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;

# OCSP stapling しなければ不要だった
# ssl_trusted_certificate /etc/letsencrypt/live/exmaple.com/chain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

# 以下好みに応じて。

# こだわりがないならletsencryptの作ったものを使うだけ。

# include /etc/letsencrypt/options-ssl-nginx.conf;

# ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;

# こだわりがあるなら環境に応じて以下などを設定する

# ssl_session_timeout
# ssl_session_cache

# ssl_protocols
# ssl_ciphers
# ssl_prefer_server_ciphers

後でLet's encryptで配布されているFakeCAを認証局として認めるブラウザで接続確認する。

この時点でも--stagingを外して--break-my-certs付けて本番用証明書と置きかえ、さらに--keep-until-expiring付きでコマンドを適当にcron実行させて自動更新としても良いが、一応先の設定をミスするとLet's Encryptの更新を阻害してしまう可能性もあるので念の為後回しにした方が良い。

http client certificate

帳簿は広く公開したいものでもないので鍵認証を行う。

/etc/ssl/openssl.cnf を/usr/local/ssl/example.com/等適当なディレクトリにコピーしてきて編集

[ CA_default ] # デフォルトまたは[ ca ] で指定したセクション

dir = どこか適当なディレクトリ/CA用ディレクト

 

# SAN証明書にするならreqやcaのx509_extensionsで読まれるセクションに追加。デフォルトだと多分usr_certとv3_req

[ usr_cert ]

subjectAltName=@alt_names

[ v3_req]

subjectAltName=@alt_names

[ alt_names ]

DNS.1 = example.com

DNS.2 = *.example.com

 

# 以下は適当に

 

countryName_default = JP

# 他のdistinguished_nameも値を入れておいた方が楽

 

# CA policy は緩めに

stateOrProvinceName = optional
organizationName = optional
organizationalUnitName = optional

 

# CAやreqで使うハッシュ方式

default_md  = sha256 # opensslのビルドによってもっと好みのに変える

default_bits = 2048 # mdによって適当な値が違うのでこちらも変え忘れない

まずはreqを作る。さきほどの設定をさらにコピーしてきて

 basicConstraints=CA:FALSE
 nsCertType = server, email, object

 に変更(clientreqconfig.cfgとする)し、

 sudo openssl genrsa -rand /dev/urandom -aes256 -out ./ClientSecret.key 2048

# /dev/urandom で良しとしているが、環境によっては/dev/randomでも十分使えるかもしれない。使えるなら使ってみたい。

# すぐ使うパスフレーズを入力したりする

openssl rsa -text -noout -in ./ClientSecret.key

sudo openssl req -new -config ./clientreqconfig.cnf -sha256 -key ./ClientSecret.key -out ./CSRrequest.csr

# さきほどのパスフレーズを入力したりする

openssl req -text -noout -in ./CSRrequest.csr

 opensslのビルドによって使える暗号化方式が違うのでその辺りは適宜読み変える。

csrを自分で認証する。CA用にもう一度openssl.cnfをコピーして

basicConstrants=CA:TRUE

nsCertType = client, email

と書きかえ(caconfig.cfgとする)、

 CADAYS="-days 3650" DAYS="-days 3650" SSLEAY_CONFIG="-config ./caconfig.cnf" CATOP=適当なディレクトリ/CA用ディレクトリ sudo -E /usr/lib/ssl/misc/CA.sh -newca

 で作成、

openssl req -text -noout -in ./careq.pem
openssl x509 -text -noout -in ./cacert.pem

# 特にここでCA:TRUEでないと困るのでよく確認
openssl rsa -text -noout -in ./private/cakey.pem

 その後署名してclient証明書を作り、配布用にまとめてpkcs12フォーマットのものも作る。

 sudo openssl ca -config clientreqconfig.cnf -md sha256 -cert CAのディレクトリ/cacert.pem -keyfile CAのデイレクトリ/private/cakey.pem -out Clientのディレクトリ/ClientCert.crt -infiles Clientのデイレクトリ/CSRrequest.csr

 

sudo openssl pkcs12 -export -in Clientのディレクトリ/ClientCert.crt -inkey Clientのディレクトリ/ClientSecret.key -certfile CAのディレクトリ/cacert.pem -out ./ClientCertFile.pfx

 これを自分の使いたいブラウザに個人証明書として配布する。(複雑な設定を避けLet's Encryptを使用しない場合は同様にしてnsCertTypeがserverのリクエストを作り、CAで署名する。)

 nginxに以下のような設定を追加する。 ssl_verify_clientをoptionalにし、ssl_client_verify変数を特定のlocationでのみチェックする事で.well-known/acme-challenge/ 以下によるLet's Encryptの更新を邪魔しないようにする。

ssl_verify_client optional;
ssl_client_certificate 先程のCAのディレクトリ/cacert.pem;

location / {
     if ($ssl_client_verify != SUCCESS) {
         return 403;
     }

    # ここに元からあったlocation /の設定

}

sudo nginx -t # 設定を確認

sudo systemctl restart nginx

sudo certbot certonly --webroot --staging --webroot-path /var/www/letsencrypt -d example.com # .well-known/acme-challenge を止めていない事の確認

 証明書を入れたブラウザ、入れていないブラウザでアクセスし、動作確認する。

hledger-webへのプロキシ

hledger-web自体がwebサーバーの機能を持つので、単純に

proxy_pass http://localhost:5000/;

をnginxの設定で指定すれば良い。

proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-Server $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

 ログを眺める時のためにこの辺りも一応設定しておく。hledger-web --base-url https://example.com/を起動した状態でアクセスすれば確認できる。

hledger-webのサービス化

hledger-webをUnitとしてsystemdに登録し、サーバー起動時に自動的に起こすようにする。

 sudo vi /etc/systemd/system/hledger-web.service

[Unit]
Description=hledger web server

[Service]
ExecStart = /usr/bin/hledger-web -f /ジャーナルファイルへのパス --base-url=https://example.com --serve
Restart = always
Type = simple
User = ubuntu # シェル等のないユーザを作っておきかえた方が本当は良いが、ジャーナルファイルの権限等がちょっと面倒になる。
Group = ubuntu
WorkingDirectory = /var/lock/hledger-web # 現在はロックファイルくらいしか使わない? 上記ユーザが権限を持つところならどこでも良い。

[Install]
WantedBy = multi-user.target

 これでOK。

sudo systemctl daemon-reload

sudo systemctl start hledger-web

sudo systemctl enable hledger-web

 これでssl認証でweb越しに帳簿を編集できるようになった。無骨な画面でとっつきにくいが、複式簿記の帳簿としてはすごく良い。