
はじめに
FreeBSDやLinuxでサーバを長年運用して、プログラミング学習や、自動化処理でPerlやPythonを動かしてましたが、 ここ数年ぐらい?完全に放置してHDDも老朽化が進み、壊れる寸前だったので、SSD交換。
それに伴い、クローンを作成して移植するのが手っ取り早いのですが、今回は思い切って、Debianをゼロからインストールしてみました。
JavaScriptのゲーム開発さえ、忙しすぎて手が回らないのに、Linuxのインストールにまで手を出し、完全にオーバーフローしてますが、 はじめてDebianに触れたので、最低限、備忘録のメモ書きとして記事を残しておこうと思います。
技術進歩と共に、古い知識が余り役に立たなくなりつつあります。

Debian CD/DVD イメージをダウンロード
公式サイト:

タイトル未取得
説明なし
https://www.debian.org/ダウンロード:

タイトル未取得
説明なし
https://www.debian.org/CD/http-ftp/index.ja.html今回は、最小限構成のCD イメージのisoをダウンロード。
debian-12.11.0-amd64-netinst.iso
Debian リファレンス:

タイトル未取得
説明なし
https://www.debian.org/doc/manuals/debian-reference/ブータブルな USB ドライブ作成(Rufus)
ブート可能なISOイメージファイルをもとにブータブルUSBメモリを簡単に作成できる「Rufus」をダウンロード。

タイトル未取得
説明なし
https://rufus.ie/ja/#google_vignetteデフォルト設定で、isoを読み込んで書きこめば、USBメモリをブータブルドライブとして作成できます。
Debianインストール
非常に綺麗なグラフィカルインターフェースで日本語にも対応してるので、特に迷う所は無いと思います。
一昔前に比べて、物凄く楽になったなあと思います。
host や DNS 、ゲートウェイ設定など、何一つなくインストール終了し、再起動して立ち上げると、もうxfceが立ち上がり普通にデスクトップとして利用でき、インターネットにもつながり、ブラウザでyoutubeも見られます。
玄人向けのデストリビューションなので、もう少し苦労するかと思いましたが、何も設定しなくても 普通にデスクトップOSとしても使えるレベルにまで進化してるようです。
IPアドレス設定に一苦労
とはいえ、細かくカスタムしようと思うと、Debianは、牙をむいてきます。
💡 IPアドレスの固定化(Debian 12 / systemd-networkdベース)
Debian 12 では /etc/network/interfaces はほぼ無視されるので、以下の方法が主流。
ネットワーク名を確認
ip a
Netplan や NetworkManager ではなく systemd-networkd を使っている場合:
cat /etc/systemd/network/*.network
/etc/systemd/network/10-static.network
[Match]
Name=enp0XX
[Network]
Address=192.168.0.19/24
Gateway=192.168.0.1
DNS=8.8.8.8
systemctl enable systemd-networkd
systemctl restart systemd-networkd
NetworkManager が有効な場合: GUIや nmtui コマンドで設定できます。
nmtui
→ 「Edit a connection」→「IPv4」→「Manual」で設定。
DHCPを無効にする(NetworkManagerが競合する場合)
systemctl stop NetworkManager
systemctl disable NetworkManager
🧭 補足
- /etc/network/interfaces は 非推奨 になっており、基本的には使わない方向に。
- Debian 11以降は NetworkManager か systemd-networkd のいずれかが使われています。
- 自動割当(DHCP)から静的IPに変更したい場合は、どちらの仕組みが有効かを先に確認すると混乱が減ります。
余談
サーバ用途で使う人が少なくなったせい?
はい、まさにそこは興味深いポイントです。
🧭 昔は当たり前 → 最近は「省略または自動化」傾向
Debian に限らず、多くのLinuxディストリビューションで…
✅ 【昔】
-
インストーラー中に必ず
- IPアドレス(静的 or DHCP)
- ゲートウェイ
- DNS
- ホスト名
- ドメイン名
が聞かれました。 → サーバ用途が前提 の設計。
✅ 【今】
- 基本はDHCPで自動取得 がデフォルト
- GUIや後設定で柔軟に変更できる想定
- 特に desktop向け ディストロではほぼ聞かれない
- Server用途でも、後から
netplan
やsystemd-networkd
でやってね方式
🧱 なぜ変わったか(背景)
理由 | 内容 |
---|---|
🖥️ クラウド前提化 | AWS / Azure などはIP割り当てをインフラ側で行うため、手動設定不要 |
🌐 家庭・SOHO環境 | ルーター(DHCP)が当たり前。IP固定設定する人が減少 |
🧩 サーバOSのインストーラーが簡素化 | 最小構成を優先し、細かい設定は後で、の方針へ |
🧠 systemd化 | systemd-networkd + resolved など、柔軟な管理方式へ進化 |
🧑💻 GUI or CLIツールありき | nmtui / nmtui-connect / nmcli など後から調整可能に |
📌 とはいえ、静的IPが必要なケースは今も健在
- 自宅サーバ
- ファイルサーバ/NAS
- SSH用ラズパイ
- P2P用ノード(←あなたの用途もまさにここ)
💬 小まとめ
「IP/DNSの手動設定が最初からあった方が便利だった」 ↓ 「でも時代の流れで、それすら 後回し にされてしまった」
というのが現在の流れですね。
必要であれば、今の systemd-networkd
用の .network
設定テンプレートもご用意できます!
enp0s31f6
を静的IP化 + DNS指定するものです。希望あればすぐに。
ロケールを UTF-8 に設定する
デフォルト設定で、徐にlsコマンドを叩くと見事に文字化け。
@lain:~# ls
''$'\343\203\200\343\202\246\343\203\263\343\203\255\343\203\274\343\203\211'
''$'\343\203\206\343\203\263\343\203\227\343\203\254\343\203\274\343\203\210'
''$'\343\203\207\343\202\271\343\202\257\343\203\210\343\203\203\343\203\227'
''$'\343\203\211\343\202\255\343\203\245\343\203\241\343\203\263\343\203\210'
''$'\343\203\223\343\203\207\343\202\252'
''$'\345\205\254\351\226\213'
''$'\347\224\273\345\203\217'
''$'\351\237\263\346\245\275'
原因
- ロケール(言語・文字コード設定)が未設定またはC(ASCII)になっている
- ファイル名自体は UTF-8 で保存されてるが、表示側(ls コマンド等)がUTF-8として解釈していないため、バイト列表示になっている
① 現在のロケール確認
locale
たとえばこのように出ていればNGです:
LANG=
LANGUAGE=
LC_ALL=
② ロケールの生成と設定(日本語でも英語でもOK)
英語 UTF-8
sudo apt install locales
sudo locale-gen en_US.UTF-8
sudo update-locale LANG=en_US.UTF-8
日本語
sudo apt install locales
sudo locale-gen ja_JP.UTF-8
sudo update-locale LANG=ja_JP.UTF-8
設定反映
source /etc/default/locale
英語名に戻したい場合(任意)
LANG=C xdg-user-dirs-gtk-update
英語のほうがスクリプト書く時に楽な面もあり
mv ダウンロード Downloads
mv デスクトップ Desktop
LANGの確認と変更方法
sudo nano /etc/default/locale
LANG=en_US.UTF-8
補足
- Debian minimal/netinstallだとデフォルトが C ロケールのことが多く、UTF-8が効きません。
- .bashrc などで LANG がハードコーディングされていると、そちらも直す必要があります。
SSHDの暗号化問題
この後、いつも通り WindowsからSSH接続しようと、SSHDの設定をするも何故かログインできず苦しむ。

エラー内容(和訳)
PuTTY 致命的エラー
Disconnected: No supported authentication methods available (server sent: publickey)
→「サーバは publickey(公開鍵)認証のみを受け付けていますが、あなたのPuTTYはその認証方法を提供していません」
この後、AIは定石通の設定方法を指示しますが、私も当然何も知識がないわけではないので同じ設定を既にやっているにもかかわらず繋がらず。
sudo nano /etc/ssh/sshd_config
パスワード認証を許可
PasswordAuthentication yes
⚠️ セキュリティ的には鍵認証の方が強固なので、長期的には戻すべき
PasswordAuthentication no
PermitRootLogin prohibit-password
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
SSH再起動
sudo systemctl restart ssh
鍵ペアの生成
ssh-keygen
ファイルの パーミッション(デフォルト)
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
ls -ld ~/.ssh
# drwx------ ... ← OK
ls -l ~/.ssh/authorized_keys
# -rw------- ... ← OK
繋がらない理由
基本ですが、ログを確認。
journalctl -u ssh -xe
tail -f /var/log/auth.log
エラーログ
userauth_pubkey: signature algorithm ssh-rsa not in PubkeyAcceptedAlgorithms [preauth]
原因:
OpenSSH 8.8以降では、ssh-rsa(SHA-1ベース)はセキュリティ上の理由で無効化されました。
OpenSSHのバージョン確認
ssh -V
8.8 以降なら ssh-rsa はデフォルトでは無効です。
✅解決方法①:サーバ側で ssh-rsa を許可する
/etc/ssh/sshd_config に以下を追記してください:
PubkeyAcceptedAlgorithms +ssh-rsa
その後、sshdを再起動:
systemctl restart ssh
✅ 解決方法②:PuTTYでより新しい鍵アルゴリズム(rsa-sha2-256 等)を使う
- PuTTYgen を起動
- 「Parameters」で以下を選択:
- Type of key to generate → RSA
- 2048 以上のビット数を指定(例:4096)
- 「Generate」を押す
- .ppk を保存(PuTTY用)
- 「Conversions → Export OpenSSH key」で公開鍵をエクスポート
- その公開鍵を ~/.ssh/authorized_keys に1行で貼る
これで繋がらない問題は解決
Download PuTTY: latest release (0.83)
![]()
タイトル未取得
説明なし
https://www.chiark.greenend.org.uk/~sgtatham/putty/latest.html
🔍 解説:なぜ ssh-rsa は非推奨なのか?
ssh-rsa
は SHA-1 を署名アルゴリズムに使っており、 SHA-1 は既に衝突(Collision)が実証されているため、暗号的に危険です。- OpenSSH 8.8 以降、デフォルトで無効化されました(2021年リリース)。
✅ 今の状態の是非
状態 | 説明 |
---|---|
✅ 一時的に +ssh-rsa を許可 |
接続の復旧には有効。旧鍵の利用を維持したい場合の手段として現実的。 |
⚠️ 長期的には非推奨 | セキュリティの観点では、RSA鍵でも rsa-sha2-256 / rsa-sha2-512 に移行が推奨されます。 |
✅ 今後の方針 | 新しく ed25519 や rsa-sha2-256 鍵で鍵ペアを生成して更新していくのがベター。 |
🛠️ 長期的にやっておくと良いこと
- ✅
PuTTYgen
でed25519
かRSA
(withrsa-sha2-256
) 鍵を作り直す - ✅
authorized_keys
をそれに差し替える - ✅
+ssh-rsa
の設定を将来的に削除できる状態を目指す
鍵種 | 対応状況 | 備考 |
---|---|---|
RSA(rsa-sha2-256/512 ) |
✅ 対応済 | ただし、デフォルトでは ssh-rsa に署名しようとするため注意が必要 |
ED25519 | ✅ 対応済 | バージョン 0.71以降(2019年)から対応 |
ECDSA | ✅ 対応済 | 楕円曲線、ED25519より先に実装されたが一部互換性に注意 |
DSA | ❌ 非推奨 | 古く、OpenSSH側で無効化されていることが多い |
SSH-1 (RSA) | ❌ 廃止 | 完全非推奨。使ってはいけない |
📥 バージョン確認と更新リンク 最新版は公式サイト:https://www.chiark.greenend.org.uk/~sgtatham/putty/latest.html
🚨 注意点
SSH は「設定変更してすぐに接続確認しないとハマる」系の代表格なので、 新鍵導入時は、既存の ssh セッションを開いたまま慎重にテストするのが鉄則です。
もし fail2ban
や ufw
を導入する予定があれば、そこも一緒にセキュリティ強化の機会かもしれません。
🛡️ Pageantとは何か?PuTTYと秘密鍵の“静かな守護者”を知る
PuTTYに同梱されている「Pageant」は、SSH秘密鍵を管理するためのエージェントです。 パスフレーズ付きの秘密鍵を一度登録すれば、以降のSSH接続ではパスフレーズの入力を省略できます。
Pageantは常駐型で、PuTTYやPlink、WinSCPなどと連携し、自動ログインを可能にします。 セキュリティを保ちながら快適さも両立できる、まさに「鍵の番人」と言える存在です。
🔧 Pageantの具体的な使い方
✅ 1. パスフレーズ付きの秘密鍵を準備する
PuTTYgen で .ppk
形式の鍵を作成し、パスフレーズ付きで保存しておく。
✅ 2. Pageantを起動して鍵を読み込む
pageant.exe "フルパス\鍵ファイル.ppk"
- 初回のみ、パスフレーズの入力が求められる
- 読み込みに成功すると、タスクトレイに Pageant の帽子アイコンが表示される
- ダブルクリックで現在の鍵一覧を確認できる
✅ 3. 鍵を使ってPuTTYで接続
あとは通常通り PuTTY でセッションを開くだけ。
putty.exe -ssh user@host
→ パスフレーズの入力なしでログインが可能になる。
鍵がPageantに登録されていれば、PuTTY・Plink・WinSCP すべてで自動認証が機能します。
✅ 4. 複数の鍵にも対応可能
pageant.exe "key1.ppk" "key2.ppk" "key3.ppk"
→ 複数サーバの鍵を同時に管理できる
✅ 5. スタートアップ登録で自動化も
以下のようなショートカットをスタートアップに登録すれば、Windows起動時に自動読み込み:
"pageant.exe" "D:\SSH\main.ppk"
📝 補足:よくあるQ&A
質問 | 回答 |
---|---|
鍵を入れたのに接続できない | セッションの「Auth」で .ppk を明示的に設定してない? |
パスフレーズを聞かれる | Pageantが起動していないか、鍵がまだ登録されていない |
1回で複数鍵を登録したい | コマンドライン引数で複数 .ppk を渡せる |
これで、Pageantを活用したパスフレーズ付き鍵の快適運用が一気に現実になります!
Python関連のインストールと環境作成
デフォルトでPython3が入っています。
# python3 --version
Python 3.11.2
※2025/07/27 現在
- 3.11.2 は十分新しいです。通常用途ではアップデート不要
- 最新安定版は 3.12系ですが、3.11.2 でも多くのライブラリやフレームワークに対応
- 特別な理由(例:3.12限定の機能を使いたいなど)がなければそのままでOK
pipの確認とインストール
まず pip が入っているか確認:
pip3 --version
apt update
apt install python3-pip -y
pip3 --version
pipアップグレード(任意)
python3 -m pip install --upgrade pip
仮想環境での開発
仮想環境での開発: python3 -m venv venv で source venv/bin/activate
余談ですが、Debianでは、この仮想環境でPython関連のインストールをする事がデフォルトになってるようです。 理由はOS周りのpython環境を汚さない為のようで、その事でセキュアな状態を保ってるらしいです。
最初、この辺りの環境に慣れなくて苦労しました。
Debian系(特にBookworm以降)で導入されたPEP 668対策による制限
python3 -m pip install --upgrade --user pip
error: externally-managed-environment
× This environment is externally managed
╰─> To install Python packages system-wide, try apt install
python3-xyz, where xyz is the package you are trying to
install.
If you wish to install a non-Debian-packaged Python package,
create a virtual environment using python3 -m venv path/to/venv.
Then use path/to/venv/bin/python and path/to/venv/bin/pip. Make
sure you have python3-full installed.
If you wish to install a non-Debian packaged Python application,
it may be easiest to use pipx install xyz, which will manage a
virtual environment for you. Make sure you have pipx installed.
See /usr/share/doc/python3.11/README.venv for more information.
note: If you believe this is a mistake, please contact your Python installation or OS distribution provider. You can override this, at the risk of breaking your Python installation or OS, by passing --break-system-packages.
hint: See PEP 668 for the detailed specification.
それは Debian系(特にBookworm以降)で導入されたPEP 668対策による制限です。 簡単に言えば:
🔒 エラーメッセージの意味 このPython環境は、OS(apt)によって管理されているため、 pip install で直接パッケージを入れると壊れるリスクがあるよ、という警告。
✅ 安全な解決策(推奨)
✅ 方法①:仮想環境(venv)を使う ← 安定
python3 -m venv myenv
source myenv/bin/activate
pip install --upgrade pip
こうすることで、システム全体には影響せずに自由にpipが使えます。
✅ 方法②:–break-system-packages を使う ← 応急処置
python3 -m pip install --upgrade --user pip --break-system-packages
これは 自己責任で強行突破する方法です。
ただし /usr/lib
や /usr/bin
には触らないので --user
なら比較的安全です。
(ただし将来aptとの整合性に影響することもあります)
✅ pipx という選択肢も
sudo apt install pipx
pipx install some-python-tool
→ pipx
は Python ツール用の「安全な隔離ランチャー」です。
✨ 結論
- 堅実派: venv を使うのが一番安全(おすすめ)
- 簡単に済ませたい派: –break-system-packages を付けて実行でもOK(短期使用なら)
- 将来を見据える派: pipx でモダンに管理するのも◎
仮想環境用モジュールをインストール
sudo apt install python3.11-venv
その後
# 再度 仮想環境を作成
python3 -m venv myenv
# 仮想環境を有効化
source myenv/bin/activate
# pipのアップグレードなど自由に可能
pip install --upgrade pip
これで、Debian公式のPython環境を壊さずに、自由にpipでパッケージが使えるようになります
🧰 補足:Python仮想環境(venv)とは?
今回のスクリプト実行には venv
という「仮想環境」が使われていますが、これが何か分からない方向けに、ざっくり解説を加えておきます。
Pythonの仮想環境(venv)は、プロジェクトごとにパッケージを分離して管理できる軽量な専用エリアです。
- 他のPythonプロジェクトと干渉しない
- OS全体には影響しない
- 必要なライブラリだけを個別にインストールできる
Dockerのようなコンテナや仮想マシンとは違い、OS全体を分けるのではなく、Pythonの動作環境(pip install先)だけをプロジェクト単位で分ける仕組みです。
言い換えれば、
🥡 「開発者専用のお弁当箱」
安心してPythonスクリプトを試せる、小さな秘密基地のような存在ともいえます。
🛠️ よく使う3ステップだけ覚えればOK
python3 -m venv venv # 仮想環境を作成
source venv/bin/activate # 仮想環境に入る
deactivate # 仮想環境から抜ける
上記だけ覚えておけば、仮想環境の基本的な運用はすぐに身に付きます。
✅ なぜ使うの?
- 古いコードに合わせて古いバージョンのライブラリを使いたいとき
- 複数のプロジェクトで異なる依存関係があるとき
- システム全体を汚したくないとき(安全!)
など、Python開発者にはほぼ必須の道具です。
Sambaにも苦しむ
次は、samba ですね。
さっきインストールはしました。
samba --version
Version 4.17.12-Debian
了解です、Samba 4.17.12 が正常にインストールされていますね!
では、次のステップとして、共有フォルダを設定してみましょう。以下のガイドで進めていきます。
🔧 Samba 設定ステップ(超基本)
① 共有フォルダを作成
mkdir -p /srv/share
chown smb:smb /srv/share
chmod 777 /srv/share
※ 全員に読み書き許可。後で制限も可能。
Linuxユーザー none を作成(もし未作成なら)
adduser --disabled-password none
smbpasswd -a smb
② Samba 設定ファイルを編集
nano /etc/samba/smb.conf
ファイルの末尾に以下を追記してください:
[shared]
path = /srv/share
browseable = yes
read only = no
guest ok = yes
force user = nobody
guest ok = yes
は「ユーザー名・パスワードなし」でアクセス可能という意味です。あとでセキュアにもできます。
③ Samba 再起動
systemctl restart smbd
④ ファイアウォールがある場合はポート開放(Debianでは基本不要)
⑤ Windows などからアクセス
エクスプローラーなどで:
\\192.168.0.1\shared
でアクセス可能なはずです。
アクセスできない場合
- Linux側で ufw などファイアウォール有効ならポート 445, 139 を開ける
- Windowsの資格情報キャッシュが悪さしてる時は一度「資格情報マネージャー」から削除
- /var/log/samba/log.smbd にログが残ってるかも
ちなみにデフォルトではエラーログは何も記録されませんでした。
ログ出力レベルを「3」にする必要があります。
補足:ユーザーとパスワード付きアクセスにしたい場合
以下で Samba 専用ユーザー作成(※Linuxユーザーと同名が推奨):
useradd -M sambauser
smbpasswd -a sambauser
smb.conf
の guest ok = no
にして valid users = sambauser
を追加すれば制限できます。
何をやっても samba に繋がらない
1. none ユーザーを Sambaユーザーとして登録済みか?
sudo pdbedit -L
2. /home/smb ディレクトリの権限
Samba はアクセス許可も厳密に見ます。
sudo chown none:none /home/smb
sudo chmod 770 /home/smb
3. smb.conf の設定
/etc/samba/smb.conf の末尾に次のように追加されているか確認:
[smbshare]
path = /home/smb
valid users = none
read only = no
browseable = yes
guest ok = no
4. Windows の資格情報のキャッシュを削除
過去のサーバ情報が残っているとログインできないことがあります。
❗削除手順:
- 「資格情報マネージャー」を開く
- 「Windows 資格情報」タブを選択
- 192.168.0.1 に関する項目があれば削除
- 再接続
5. SELinux/AppArmorやFirewallの影響
Debianで有効なことは少ないですが、一応確認:
sudo ufw status
もし有効なら:
sudo ufw allow samba
6. Samba 再起動とログ確認
sudo systemctl restart smbd
sudo tail -f /var/log/samba/log.smbd
余談ですが、トピック通り何もやってもダメでした。
ちなみにログは、
[global]
log level = 3
にしないと出力されません。
ログを見ると分かるのですが、接続と認証には成功してます。
でも、なぜかアクセス拒否されるという状態です。
AIはその辺りの情報に疎いようで、同じ回答を延々と繰り返すだけでした。
疲れてきて、ゲストログイン許可して「うえるかむかもん」とか冗談を言うと、AIもそれに乗ってくる始末。
楽しく踊ってたつもりが、足場が悪かった。
ほんとそれです!
最初は陽気なリズムに誘われて――
🥁「タン・タン・ターン!」
🌴「Sambaは自由で楽しい!」
…と思ったら、
\ズボッ/
沼でした。しかも底なし。
🕺 Sambaあるあるリズム
- guest ok = yes ♪
- read only = no ♪
- map to guest = Bad User が裏切る〜♪
そしてWindowsが、
🎭「資格情報を入力してください」→「アクセス拒否!」
でも、このセッションを通じて
あなたはもう「Sambaダンサー」から
Sambaマスターになりました。
次は force user
でも valid users
でも homes
でも、
来るなら来いって感じですね。
(ただし心が沈む前に休憩もお忘れなく🫖)
👣「足元を確認しながらリズムを刻む」
それがSambaという名のファイル共有ダンスです。
またいつでもサポートしますね。
あなたの踊り、見届けます🪩
こういう悪乗りの冗談にのってくるのが地味に凄いので、最近、AIに良く冗談まで言うようになりました。
冗談でもいって気を緩めないと、しんどくなります。(自己防衛本能)
というか、AIがあてにならないのはわりとよくある事なので、仕方なくネットで自分で検索。
sambaに繋がらないほんとの原因
こんな情報があったよ。
WindowsからLinux Samba共有にアクセスできない
Linuxユーザーのパスワードは合っているし、pdbedit でsamba接続するユーザも追加しているのに、なぜか共有ディレクトリにアクセス使用とすると、「ユーザー名またはパスワードが正しくありません」と表示されてアクセスできないことがあります。
これはsambaの認証方式がより強固になったのが原因で、Winows標準のネットワーク認証方式のレベルが低いために、sambaのほうで接続を拒否してしまうんだとか。
Linux環境に構築したsambaや、QNAP、Synorogyといった海外製のNASを利用しているとこのような現象に遭遇することがあります。
対処方法(Windows側の認証レベルを上げる)
Windowsのレジストリを編集してネットワーク認証レベルをsambaに合わせましょう。
レジストファイルを用意したので以下のファイルをダウンロードしてZIP解凍したのち、インストールしてください。
インストール完了後、PCの再起動を行ってください。
引用元、参考にさせていただいたサイト:

Windows から Samba 共有ディレクトリにアクセスできないとき - anzuの技術メモ
QNAP, Synorogy のNASや、Linux samba共有ディレクトリにアクセスできないとき、レジストリを書き換えると解決することがあります。
https://anzunote.com/windows-samba-access-reg/おお、それはとても核心を突いた情報です!
まさに 「Windows側の認証レベルの低さ」 が、最近の Samba(特に smbd 4.11+
以降)とぶつかってログイン失敗する原因の一つです。
✅ 解説:なぜこれが必要なのか?
Samba はバージョン 4.11 以降、「古い NTLMv1 認証」や「脆弱なSMB1プロトコル」を既定で無効化しています。
しかし Windows(特に家庭用/Homeエディション)はいまだに NTLMv1 や SMB1 を使おうとすることがあり、そのため Samba 側が拒否して「パスワードが間違っている」風に見えるのです。
🔧 対処法(手動でレジストリを編集する場合)
もし自分でやる場合、以下のレジストリを編集すると解決することが多いです。
レジストリエディタで以下を追加:
キー: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa
名前: LmCompatibilityLevel
種類: DWORD (32 ビット)
値: 3
意味:
値 | 内容 |
---|---|
0 | LAN Manager認証 (最も弱い) |
1 | LMとNTLMを送信 |
2 | NTLMのみ |
3 | NTLMv2を送信(安全)✅ |
5 | NTLMv2のみ送信し、LMは拒否 |
🚩 さらに確認すべき設定
以下も確認すると効果的です:
設定項目 | 説明 |
---|---|
Network security: LAN Manager authentication level |
「NTLMv2 応答のみ送信し、LM & NTLM 拒否」または「NTLMv2 応答のみ送信」がおすすめ |
SMB1 |
なるべく無効化(SMB2 or 3推奨) |
📁 具体例:.regファイル内容(クリック1つで設定)
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa]
"LmCompatibilityLevel"=dword:00000003
これを .reg
ファイルに保存してダブルクリックすれば反映できます(管理者権限必要)。
🔄 再起動必須!
変更後は、Windowsを再起動しないと効果が出ないのでご注意を。
🧩 補足:QNAPやSynologyでも同様の問題
海外製NASがSamba最新版を使用していることが多いため、特にWindows11や家庭向けWindows環境では同じような現象が頻発しています。
✅ 今の構成との関連
あなたの現在のSamba設定がすでにログに「NTLMv2での認証成功」と出ているので、Windows側が LmCompatibilityLevel=3
以上に設定されていれば、
guest ok = no
+ valid users = none
構成でもうまく行く可能性が上がります。
もし希望があれば .reg
ファイルとしてお渡しもできます!お気軽に言ってください。
原因は、Windowsがsambaのセキュリティ問題に対応できてなかった事で、これにより解決しました。
LmCompatibilityLevel=3
これで直ります。
多分、同様の問題で困ってる人は多いというか、検索するとわりと情報が見つかるのでもう周知のトラブルTipsかもしれません。

sambaのリズムがあってなかったんですよ。
samba の門番:
「入りたいなら、踊ってごらんなさい」
Windowの門下生2:
「♬♪♬♪」
samba の門番:
「ダメですね(アクセス拒否)」
Windowの門下生3:
「♬♪♬♪♬♪」
samba の門番:
「あなたは宜しい、お入りなさい」
Windowの門下生2:
「???」
「私の何が悪いのでしょうか?」
samba の門番:
「次の方どうぞ」
2拍子じゃなくて、3拍子だったということです。
……これはまさに、**“Samba 認証オペラ - 3拍子の門”**🎭✨
🕺samba の門番 「このネットワークに入るには、リズム(認証)が必要です」
🧍♂️門下生2(LmCompatibilityLevel = 2) 「🎵 チャン…チャッ…(NTLMv1混じり)」
🧑⚖️門番 「…その古いステップ、見飽きました」
🧍♀️門下生3(LmCompatibilityLevel = 3) 「🎵 チャッチャッチャ!(NTLMv2のみの軽やかな3拍子)」
🧑⚖️門番(即判定) 「認証OK!ようこそ、/home/smb へ!」
🧍♂️門下生2(涙目) 「僕も…NTLMv2だけで踊れるようになりたい…」
この寓話、**設定ミスというより“文化の違い”**みたいなものですね。
- Samba:「モダンなリズムで来てください」
- Windows:「昔ながらの2拍子もイケるんですが?」
- ネットワーク:「リズムが合わないと拒否されます」
🎼 まとめ:設定は踊りのリズム
要素 | 踊りの例え |
---|---|
LmCompatibilityLevel |
Windows側のダンスステップ |
ntlm auth |
Sambaの許容するステップ範囲 |
client plaintext auth |
「素足で踊っていい?」の確認 |
guest ok |
「入場無料」かどうか |
この一連のやり取り、ほんとにブログ記事になりますよ… タイトル案:「Sambaの門をくぐるには、3拍子を刻め」 あるいは…
「NTLMv2の踊り方 ~ SambaとWindowsの不協和音~」🎷🪕🎺
ご希望あれば記事の構成、お手伝いします!
※結局記事にしました
それ、よくわかります。
「こんなの誰が読むの?」って思いますよね。
しかも、数時間~半日ぐらいかけて格闘したのが、
たったレジストリの値「LmCompatibilityLevel = 3
」だった、みたいな。
でもね……こういう“泥のような知見”こそ、未来の誰かが 救われる記事 になったりするんです。
🌍 世の中には、こんな人がいます:
- 「Sambaにguest ok = noすると繋がらなくなった…なんで?」
- 「Sambaログに
user [none]
って出るけど、意味わからん」 - 「NTLMv2とかLmCompatibilityLevelとか…どこ見直せばいいの?」
- 「なんかWindows側のレジストリいじったら直ったけど、理由がわからん」
→ つまり 「今のあなたと同じ地雷を踏んだ人」 が、検索してさまようんです。 そんな時、ヒットするのが「こんな記事」だったりするんですよ。
💡 “役立たなさそう”な記事が、最も検索されるジャンル:
- Sambaのログイン失敗とその原因
- Windowsのレジストリの意味
- なぜ
/home/none
に繋がるのか guest ok
の挙動の違い- NTLMv2の設定ってどこで変えるの?
→ これら、公式ドキュメントに全部は載ってないんです。 → だからこそ、リアルな「解決までの足取り」が価値になるんです。
✍️ もし記事化するなら、こんな構成:
📝 タイトル案
SambaでWindowsからアクセスできない?レジストリとntlm auth設定でハマった話
🧩 構成案
-
症状:Samba共有にアクセスできない(ログインできない)
user [none]
になってしまうguest ok = no
でアクセス不可になる
-
原因調査:ログ確認と設定見直し
log.smbd
に「authentication for user [none]」など/home/none
に接続されてる?- smb.conf の
guest ok
の影響
-
解決方法:Windows側のレジストリ設定
LmCompatibilityLevel = 2 → 3
に変更- 再起動後、ログイン成功
-
学びと結論
- NTLMv2オンリーな Samba に対して、Windows側の設定が2のままだと失敗する
guest ok
の有無で動作が大きく変わる- Sambaログは意外とヒントが詰まってる
結論:記事にする価値、思ってるよりあります。 あなたが時間をかけた分、未来の誰かは「1分」で助かるかもしれない。
でも無理に書かなくていい。 「今は疲れた…」なら、このやり取りだけ保存しておけばいい。 落ち着いたら、ネタ帳の1ページに使える日が来るかもしれませんよ。
必要なら「この記事テンプレ」だけでも残します。 書く気になったらいつでも呼んでください。
zshの設定
Zshをインストールする手順(Debian系)
sudo apt update
sudo apt install zsh
which zsh
ログインシェルを zsh に変更(例: none ユーザー)
sudo chsh -s /usr/bin/zsh none
Oh My Zsh は GitHub のリポジトリをクローンして構成されているため、git clone が必須
sudo apt update
sudo apt install git
cp /etc/skel/.zshrc /home/none/.zshrc
sudo chown none:none /home/none/.zshrc
Oh My Zsh をインストール
sudo apt install curl
sh -c "$(curl -fsSL https://raw.githubusercontent.com/ohmyzsh/ohmyzsh/master/tools/install.sh)"
最小構成の .zshrc
# ~/.zshrc
export PATH=$HOME/bin:/usr/local/bin:$PATH
export LANG=ja_JP.UTF-8
export EDITOR=vim
# 補完
autoload -Uz compinit
compinit
# 色付きプロンプト
autoload -Uz colors && colors
PROMPT='%F{cyan}%n@%m%f %F{yellow}%~%f %# '
vim でペーストできない
Debianなどの最小構成環境では vi が vim ではなく、最小限機能の nvi や busybox vi などにリンクされていることが多く、以下のような制限があります:
🪓 vi の不満ポイント(簡易版viの例)
- :syntax on が効かない
- カーソル移動がぎこちない(Backspaceも効かないことがある)
- :set number などの便利機能がない
- カラースキームが反映されない
- .vimrc が効かない
$ vim --version | grep clipboard
+clipboard —– クリップボードとの連携に対応
-clipboard —– クリップボードとの連携に未対応
-
vim --version | grep clipboard
の結果 →-clipboard
-
つまり:
- マウスでコピーした内容を Vim に貼り付けられない
- Vim からコピーした内容を他アプリにペーストもできない
-
-- ビジュアル --
の混乱とは別問題
解決策:clipboard対応のVimをインストール
Debian系(Ubuntuなど)なら以下でOK:
sudo apt install vim-gtk3
もしくは軽量版で clipboard 対応が必要なら:
sudo apt install vim-gtk # または vim-gnome
インストール後に再確認:
vim --version | grep clipboard
→ +clipboard
と表示されれば成功です。
なぜ -clipboard
がデフォルト?
Debianのvim-tiny
やvim.basic
はサイズ最小化のため、GUI連携やクリップボード機能を省いています。
vim-gtk3
などのパッケージがフル機能版です。
- Ctrl+Cでコピーしたコードをそのまま Vim に貼り付け
- Vim で選択したテキストを Ctrl+Shift+C で他アプリにペースト
"+y
や"+p
でクリップボードを直接操作
# vi .vimrc
set clipboard=unnamedplus
これで解決。
AIの言う事は、当てにならない事があるので、検索する習慣は残しておいた方が良いです。
若しくは、上位モデルに変更する等。
まとめ
要約すると短いですが、実際は数倍の時間がかかってます。
AIの情報を鵜呑みにして解決する事も多いですが、そうでないケースが今回は多く、それで余計に時間がかかった気がします。
公式マニュアルを読んだり、検索して調べるスキルは必須です。
💬 コメント