2026/02/13(金)Windows 11の新しいメモ帳を消して古いメモ帳を使う

更新日:
投稿日:

昔懐かしのシンプルなメモ帳

Windows 11の新しいメモ帳は、CVE[1]が出たり、Markdownをコピペしたら勝手にエスケープされたり、毎回新機能の設定をOFFさせられたりと、新しいメモ帳に愛想が付いてきたので古いメモ帳に戻すことにしたのでそのログ。

新しいメモ帳にはお亡くなり頂き、古いメモ帳だけにした。

やったこと

  1. 新しいメモ帳をアンインストール
    • 実は普通にアンインストールできてしまう
  2. Win+Rでファイル名を指定して実行を出し、notepadを叩く
  3. 「新しいバージョンのメモ帳が利用可能です」「インストール」とか帯が出るので帯の右にある×ボタンを押して消す
  4. タスクバーにいるメモ帳を右クリックしてスタートにピン留めする
    • この作業を行い、notepadと入力して起動、noteと入力して起動、nと入力して起動のように繰り返すことで、以後の起動が楽になる

トラブルシュート

テキストファイルの新規作成ができなくなった

以下のレジストリを登録することで出すことができるようになる。

[HKEY_CLASSES_ROOT\.txt\ShellNew]
"NullFile"=""

[HKEY_CLASSES_ROOT\txtfilelegacy]
"FriendlyTypeName"="テキストファイル"

新しいメモ帳を復活させたい

Microsoft StoreにあるWindows Notepadというやつが恐らく同じものだと思われるので、これを入れるといい。

実際にこれをインストールすると「メモ帳」が復活した。

あとがき

メモ帳なんかプレーンテキストが書ければそれ以上は要らないので昔のメモ帳に戻ってこれてよかった。

UIも無駄に場所を取っていたのがすっきりした。


  1. CVE-2026-20841でWindows Notepad アプリのリモートでコードが実行される脆弱性

2026/01/31(土)Xubuntu環境でThunarを使ってSSHをマウントする

投稿日:

Xubuntu環境のノートPCからSSH経由でネットワークストレージを繋ぐときに調べたログ。

確認環境

Env Ver
OS Ubuntu 24.04.3. LTS
Thunar 4.18.8
gvfs 1.54.4
sshfs 3.7.3

前提条件

  • パスフレーズ付き公開鍵認証を使ったSSH接続を行う
  • ~/.ssh/configssh ホストで接続可能な設定があり、実際に接続できる
    • 設定ファイルの一例
      Host hoge
          HostName hoge.example.com
          User piyo
          IdentityFile hoge.example.sec
          Port 12345
      

やり方

  1. gvfs[1]とsshfs[2]を入れる
    sudo apt install -y gvfs sshfs
    
  2. Thurarのアドレスバーにsftp://<ここにsshホスト>を入れると繋がる
    • 例:ホスト名がhogeであれば:sftp://hoge
  3. パスフレーズを聞かれるので入力する
  4. 今後もアクセスする予定があるならブックマークに入れておくと便利

  1. URIスキーマを扱えるようにするためのやつらしい
  2. SSHをファイルシステムとしてマウントできるようにできるやつ。Windowsでやるときにも同じやつ使うと思う

2025/11/12(水)Windows 11をWindows Updateでversion 25H2にしたら発生した問題と、その対処法

更新日:
投稿日:

Windows 11でWindows Updateを行ったところ、色々壊れたので、その対処ログとして残す。

アップデートした内容

Windows 11 24H2→Windows 11 25H2

OSビルドまでは控えていないため不明。

発生した問題

根本原因の大半はファイアウォールのルールが激減したせいであることが分かった。

SSHDに繋がらなくなった

当該のWindows端末ではLAN内でファイル共有をする目的でSSHDを立てているのだが、これに繋がらなくなった。

原因としては単にファイアウォールのルールが消し飛んでいただけだった。

WindowsにSSHDを立てるでやった方法で穴あけしなおすことで解決した。

LAN内にあるサーバーにIPv6 GUAを利用した疎通が出来なくなった

これはWindowsからLAN内にあるUbuntuサーバーにIPv6 GUAを利用し接続しようとしたところ、接続できなくなった問題だ。WAN側、インターネット上のIPv6 GUAには問題なく接続できた。

これも単にファイアウォールのルールが消し飛んでいただけだったが、どのルールが原因だったのかは特定できていない。

私の環境では基本的にIPv6運用をしているため、例えば自宅でホスティングしている公開MastodonにローカルからアクセスするだけでもGUAを利用しているが、まずここに繋がらなくなった。PINGも通らなかった。但しサーバー側からWindows側へのPINGはFWに穴をあけると繋がった。

ひとまずパケットがサーバーに富んでいるかどうかを見るためにWiresharkで眺めてみることにした。

以下はファイアウォール有効時と無効時でそれぞれPINGを飛ばした時のものだが、有効時はIPアドレスが変換されていることがわかる。

FW有効時 FW無効時

ネットワークにはあまり詳しくないので何とも言えないが、帰りのパケットが届いているように見えることから、IPアドレスの変換が起きることによってステートフルインスペクションが機能不全を起こし、結果として正しく疎通しない状態になっていたのではないかと思う。

ステートフルインスペクションというのはパケットが出ていくときに、戻りのパケットを受け入れるためにポートを開けておく仕組みのことで、ここが塞がっていると戻りのパケットがFWで塞がれて入ってこれなくなる。今回は送信時のIPと、戻ってくるときのIPが異なるため、これが機能しなかったのではないかと考えている。

ステートフルインスペクションについて昔調べていたことがあったので、これはすぐに当たりがついてよかった。調べようとした動機としてはサーバーが待ち受けている場合はポートに穴がないとパケットを受けられないのに、応答はなぜポートに穴が開いてなくても抜けられるのか?と疑問に思ったことがあり、その時に調べていた。

MS Edgeがファイアウォールの許可要求を出すようになった

これは原因がよくわかっていないが、FWを許可してもセキュリティホールにしかならなさそうなので不許可でよいと思う。

ファイアウォールのルールが極端に減った

諸悪の根源はこいつだが、コマンドプロンプトを管理者権限で起動して以下のコマンドを叩くことで解決した。

netsh advfirewall reset

アップデート直後の状態は確かこんな感じだったと思う。なおこの画像は微妙にルールを追加あとに、追加した記憶のあるルールを消しているので内容が正確でない可能性がある。

解決した方法

コマンドプロンプトを管理者権限で起動して以下のコマンドを叩き、SSHDについてはWindowsにSSHDを立てるでやった方法で穴あけし直し。

netsh advfirewall reset

MS Edgeがファイアウォールの許可要求を出すようになった件については対処法が不明なので、とりあえずFWはブロックにしている。

雑感

どうも今回のアップデートでファイアウォールのルールが大きく書き換えられるようで、特にLAN内でIPv6 GUAを利用するときに著しい障害が発生することが分かった。

このクラウド全盛期に自宅サーバーを立てていたり、一般的に避けられがちなIPv6運用を軸にしている人間が少ないこと、ネットがクソみたいなAIコンテンツで溢れていることなどもあり、中々解決に手間取ったが、IPv6を使った自宅サーバー運用者としてIPv6で接続できないのは屈辱的だし、WAN上のIPv6には問題なくつながっており、MSもこんな致命的なバグを長らく放置はしてないだろうから、どこかに抜け穴があるはずと調べていたらどうにか見つけることができた。

調べたといっても、私はネットワークの知識に乏しく、手掛かりになるキーワードを持たないので無料のMS Copilotに聞いただけではあるが、いい収穫が得られた。

参考までに以下のプロンプトを投げた。

Windows 11でWindows Updateをしました。 Updateした端末をクライアントとし、GUAを利用してLAN内のサーバー端末にIPv6接続できなくなりました。

Firewallのルールがすべて削除されていたので、試しにFirewallを無効化すると接続できました。

有効にした場合、LAN内の端末にIPv6 GUA接続した場合に、宛先のIPアドレスを書き換えているようです。これはどうすれば解決できますか? IPアドレスが書き換えられるため接続ができないものとみられます。

例えば2400:4153:8f01:c800:c14b:3f7a:2b54:353aに接続しようとするとff01::1:ff54::353aに書き換えられます。ファイアウォールを無効化した場合、書き換えられません。

2025/10/21(火)Ubuntu 24.04.3 LTSにApache2を入れる

投稿日:

確認時のApache2のバージョンはApache/2.4.58 (Ubuntu)

Apache2のインストール

sudo apt -y install apache2

公開ディレクトリを触りやすくする

公開ディレクトリの所有者はデフォルトだとroot:rootで、そのままでは扱いづらいため自分自身でも手軽に扱えるように権限を調整する。

# 公開ディレクトリを見たりいじる為に自分をwww-dataに入れる
sudo usermod -aG www-data <自分のユーザー名>
# 公開ディレクトリを扱いやすくするためwww-data:www-dataに変える
sudo chown -R www-data:www-data /var/www
# 公開ディレクトリを扱いやすくするためにグループに全権限を付与する
sudo chmod -R g+rwx /var/www

mod_rewriteやmod_cgiを使えるようにする

CGIの実行に必要なPerlなどのランタイムは必要に応じて別途入れておく。PHPは一般的にCGIとして実行しないため、次項の方法で動かせるようにする。

sudo a2enmod rewrite
sudo a2enmod cgi

sudo service apache2 restart

PHPを使えるようにする

バージョンの部分は適宜書き換える。PHP本体をインストールしていない場合は別途インストールしておく(依存解決で勝手にインストールされるかもしれないが)

sudo apt install -y libapache2-mod-php8.3
sudo a2enmod php8.3

sudo service apache2 restart

2025/09/30(火)GitHubのリポジトリをSSH認証経由で扱えるようにする

更新日:
投稿日:

なんか突如としてGitHubにHTTP経由で繋ぐのが面倒くさくなったのでSSHで繋げるようにしたときのメモ。

確認環境

  • Windows 11 Pro 25H2
  • Ubuntu 24.04.3 LTS
  • RLogin 2.30.8

やり方

SSH鍵の作成

  1. RLoginを開き、サーバーに接続→新規→サーバー→プロトコルを開く
  2. 認証キーボタンを押しED25519辺りで適当な名前で鍵を作成する
  3. 適当な場所に秘密鍵をエクスポートする。ここでは便宜上github.secとする
  4. 鍵を右クリックし、公開鍵をコピーして、どっかにメモっておく

GitHubへの登録

  1. GitHubを開き、アカウント設定に移動、SSH and GPG keysを開く
  2. SSH keys→New SSH Keyを開く
  3. Titleに適当な名前を設定
  4. Key typeはAuthentication Keyにする
  5. RLoginで作った
  6. コピーした公開鍵をKeyに貼り付ける
  7. Add SSH keyボタンを押す

鍵束へのSSH鍵の登録

Windowsの場合

忘れた。

Ubuntuの場合

正攻法では以下だが、keychainを使ったほうが運用が楽。

# 鍵束への登録
eval "$(ssh-agent -s)"
ssh-add ~/.ssh/github.sec

# 接続確認
ssh -T git@github.com

SSH Configを書く

Windowsの場合

ここではWindowsのSSHクライアントを利用する。

  1. Gitに利用するSSHクライアントの設定をする
    git config --global core.sshCommand "C:/Windows/System32/OpenSSH/ssh.exe"
    
  2. 作成したSSH鍵をC:/Users/<ユーザー名>/.ssh/に置く
  3. C:/Users/<ユーザー名>/.ssh/configを開き、次の内容を記述
    Host github.com
        User <ユーザーID>
        Hostname github.com
        IdentityFile C:/Users/<ユーザー名>/.ssh/github.sec
    
    パス表現に%USERPROFILE%は通用しないので注意
Ubuntuの場合
  1. 作成したSSH鍵を~/.ssh/github.secに置く
  2. chmod 600 ~/.ssh/github.secとかして自分しか見れないようにする
  3. ~/.ssh/configを開き、次の内容を記述
    Host github.com
        User <ユーザーID>
        Hostname github.com
        IdentityFile ~/.ssh/github.sec
    

既存のリポジトリをSSH対応にする

ここではoriginがリモートであるとして進める。

  1. git remote -vでリモートリポジトリの状況を確認
  2. git remote remove originでHTTP通信になってるのを消す
  3. git remote add origin git@github.com:Hoge/piyo.gitでSSH通信に書き換える
  4. git fetchが通ればOK

トラブルシューティング

Permission Denied (publickey)が出る

  1. 鍵のパーミッションが600、.ssh/のパーミッションが700なのを確認する
  2. ssh -T git@github.comで繋がるか確認する。繋がらなければこれまでの手順が何か漏れないか確認する
  3. ユーザー名が間違っていても出る