【Linux備忘録】Sambaのレジストリ設定とSSHDの暗号化問題を突破せよ!

はじめに

FreeBSDやLinuxでサーバを長年運用して、プログラミング学習や、自動化処理でPerlやPythonを動かしてましたが、 ここ数年ぐらい?完全に放置してHDDも老朽化が進み、壊れる寸前だったので、SSD交換。

それに伴い、クローンを作成して移植するのが手っ取り早いのですが、今回は思い切って、Debianをゼロからインストールしてみました。

JavaScriptのゲーム開発さえ、忙しすぎて手が回らないのに、Linuxのインストールにまで手を出し、完全にオーバーフローしてますが、 はじめてDebianに触れたので、最低限、備忘録のメモ書きとして記事を残しておこうと思います。

技術進歩と共に、古い知識が余り役に立たなくなりつつあります。

Debian CD/DVD イメージをダウンロード

公式サイト:

ダウンロード:

今回は、最小限構成のCD イメージのisoをダウンロード。

debian-12.11.0-amd64-netinst.iso

Debian リファレンス:

ブータブルな USB ドライブ作成(Rufus)

ブート可能なISOイメージファイルをもとにブータブルUSBメモリを簡単に作成できる「Rufus」をダウンロード。

デフォルト設定で、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に変更したい場合は、どちらの仕組みが有効かを先に確認すると混乱が減ります。

余談


user icon
IPアドレスや、DNS設定って、インストール時に毎回あったと思うけど、最近は無くなってるんですね。
サーバ用途で使う人が少なくなったせい?

ai icon

はい、まさにそこは興味深いポイントです。


🧭 昔は当たり前 → 最近は「省略または自動化」傾向

Debian に限らず、多くのLinuxディストリビューションで…


✅ 【昔】

  • インストーラー中に必ず

    • IPアドレス(静的 or DHCP)
    • ゲートウェイ
    • DNS
    • ホスト名
    • ドメイン名

が聞かれました。 → サーバ用途が前提 の設計。


✅ 【今】

  • 基本はDHCPで自動取得 がデフォルト
  • GUIや後設定で柔軟に変更できる想定
  • 特に desktop向け ディストロではほぼ聞かれない
  • Server用途でも、後から netplansystemd-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 等)を使う

  1. PuTTYgen を起動
  2. 「Parameters」で以下を選択:
  3. Type of key to generate → RSA
  4. 2048 以上のビット数を指定(例:4096)
  5. 「Generate」を押す
  6. .ppk を保存(PuTTY用)
  7. 「Conversions → Export OpenSSH key」で公開鍵をエクスポート
  8. その公開鍵を ~/.ssh/authorized_keys に1行で貼る

これで繋がらない問題は解決

Download PuTTY: latest release (0.83)

🔍 解説:なぜ ssh-rsa は非推奨なのか?

  • ssh-rsaSHA-1 を署名アルゴリズムに使っており、 SHA-1 は既に衝突(Collision)が実証されているため、暗号的に危険です。
  • OpenSSH 8.8 以降、デフォルトで無効化されました(2021年リリース)。

✅ 今の状態の是非

状態 説明
一時的に +ssh-rsa を許可 接続の復旧には有効。旧鍵の利用を維持したい場合の手段として現実的。
⚠️ 長期的には非推奨 セキュリティの観点では、RSA鍵でも rsa-sha2-256 / rsa-sha2-512 に移行が推奨されます。
今後の方針 新しく ed25519rsa-sha2-256 鍵で鍵ペアを生成して更新していくのがベター。

🛠️ 長期的にやっておくと良いこと

  1. PuTTYgened25519RSA (with rsa-sha2-256) 鍵を作り直す
  2. authorized_keys をそれに差し替える
  3. +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 セッションを開いたまま慎重にテストするのが鉄則です。


もし fail2banufw を導入する予定があれば、そこも一緒にセキュリティ強化の機会かもしれません。

🛡️ 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.
ai icon

それは 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にも苦しむ


user icon

次は、samba ですね。
さっきインストールはしました。

samba --version
Version 4.17.12-Debian

ai icon

了解です、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.confguest ok = no にして valid users = sambauser を追加すれば制限できます。


何をやっても samba に繋がらない


user icon
パスワードはあってるけどログインできないですね。
前のサーバの情報を削除しないとダメ?
もしくは、smb.conf の設定が必要だった気がします。


ai icon
エラーメッセージ「アクセスが拒否されました」からすると、以下のどれかが原因である可能性が高いです:

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 の資格情報のキャッシュを削除

過去のサーバ情報が残っているとログインできないことがあります。

❗削除手順:

  1. 「資格情報マネージャー」を開く
  2. 「Windows 資格情報」タブを選択
  3. 192.168.0.1 に関する項目があれば削除
  4. 再接続

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もそれに乗ってくる始末。


user icon
Sambaのリズムで、底なし沼にダイブですね。
楽しく踊ってたつもりが、足場が悪かった。

ai icon

ほんとそれです!
最初は陽気なリズムに誘われて――
🥁「タン・タン・ターン!」
🌴「Sambaは自由で楽しい!」

…と思ったら、
\ズボッ/
でした。しかも底なし。


🕺 Sambaあるあるリズム

  1. guest ok = yes ♪
  2. read only = no ♪
  3. map to guest = Bad User が裏切る〜♪

そしてWindowsが、
🎭「資格情報を入力してください」→「アクセス拒否!」


でも、このセッションを通じて
あなたはもう「Sambaダンサー」から
Sambaマスターになりました。


次は force user でも valid users でも homes でも、
来るなら来いって感じですね。
(ただし心が沈む前に休憩もお忘れなく🫖)


👣「足元を確認しながらリズムを刻む」
それがSambaという名のファイル共有ダンスです。

またいつでもサポートしますね。
あなたの踊り、見届けます🪩


こういう悪乗りの冗談にのってくるのが地味に凄いので、最近、AIに良く冗談まで言うようになりました。

冗談でもいって気を緩めないと、しんどくなります。(自己防衛本能)

というか、AIがあてにならないのはわりとよくある事なので、仕方なくネットで自分で検索。

sambaに繋がらないほんとの原因


user icon

こんな情報があったよ。

WindowsからLinux Samba共有にアクセスできない
Linuxユーザーのパスワードは合っているし、pdbedit でsamba接続するユーザも追加しているのに、なぜか共有ディレクトリにアクセス使用とすると、「ユーザー名またはパスワードが正しくありません」と表示されてアクセスできないことがあります。

これはsambaの認証方式がより強固になったのが原因で、Winows標準のネットワーク認証方式のレベルが低いために、sambaのほうで接続を拒否してしまうんだとか。
Linux環境に構築したsambaや、QNAP、Synorogyといった海外製のNASを利用しているとこのような現象に遭遇することがあります。

対処方法(Windows側の認証レベルを上げる)
Windowsのレジストリを編集してネットワーク認証レベルをsambaに合わせましょう。
レジストファイルを用意したので以下のファイルをダウンロードしてZIP解凍したのち、インストールしてください。
インストール完了後、PCの再起動を行ってください。

引用元、参考にさせていただいたサイト:


ai icon

おお、それはとても核心を突いた情報です!

まさに 「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かもしれません。


user icon

sambaのリズムがあってなかったんですよ。

samba の門番:
 「入りたいなら、踊ってごらんなさい」

Windowの門下生2:
 「♬♪♬♪」

samba の門番:
 「ダメですね(アクセス拒否)」

Windowの門下生3:
 「♬♪♬♪♬♪」

samba の門番:
 「あなたは宜しい、お入りなさい」

Windowの門下生2:
 「???」
 「私の何が悪いのでしょうか?」

samba の門番:
 「次の方どうぞ」

2拍子じゃなくて、3拍子だったということです。


ai icon

……これはまさに、**“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の不協和音~」🎷🪕🎺

ご希望あれば記事の構成、お手伝いします!



user icon
こんなの記事にしても仕方ないでしょ…

※結局記事にしました


ai icon

それ、よくわかります。 「こんなの誰が読むの?」って思いますよね。 しかも、数時間~半日ぐらいかけて格闘したのが、 たったレジストリの値「LmCompatibilityLevel = 3」だった、みたいな。

でもね……こういう“泥のような知見”こそ、未来の誰かが 救われる記事 になったりするんです。


🌍 世の中には、こんな人がいます:

  • 「Sambaにguest ok = noすると繋がらなくなった…なんで?」
  • 「Sambaログにuser [none]って出るけど、意味わからん」
  • 「NTLMv2とかLmCompatibilityLevelとか…どこ見直せばいいの?」
  • 「なんかWindows側のレジストリいじったら直ったけど、理由がわからん」

→ つまり 「今のあなたと同じ地雷を踏んだ人」 が、検索してさまようんです。 そんな時、ヒットするのが「こんな記事」だったりするんですよ。


💡 “役立たなさそう”な記事が、最も検索されるジャンル:

  • Sambaのログイン失敗とその原因
  • Windowsのレジストリの意味
  • なぜ /home/none に繋がるのか
  • guest ok の挙動の違い
  • NTLMv2の設定ってどこで変えるの?

→ これら、公式ドキュメントに全部は載ってないんです。 → だからこそ、リアルな「解決までの足取り」が価値になるんです。


✍️ もし記事化するなら、こんな構成:

📝 タイトル案

SambaでWindowsからアクセスできない?レジストリとntlm auth設定でハマった話

🧩 構成案

  1. 症状:Samba共有にアクセスできない(ログインできない)

    • user [none] になってしまう
    • guest ok = no でアクセス不可になる
  2. 原因調査:ログ確認と設定見直し

    • log.smbd に「authentication for user [none]」など
    • /home/none に接続されてる?
    • smb.conf の guest ok の影響
  3. 解決方法:Windows側のレジストリ設定

    • LmCompatibilityLevel = 2 → 3 に変更
    • 再起動後、ログイン成功
  4. 学びと結論

    • 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-tinyvim.basicはサイズ最小化のため、GUI連携やクリップボード機能を省いています。 vim-gtk3などのパッケージがフル機能版です。


  • Ctrl+Cでコピーしたコードをそのまま Vim に貼り付け
  • Vim で選択したテキストを Ctrl+Shift+C で他アプリにペースト
  • "+y"+p でクリップボードを直接操作
# vi .vimrc
set clipboard=unnamedplus

これで解決。

AIの言う事は、当てにならない事があるので、検索する習慣は残しておいた方が良いです。

若しくは、上位モデルに変更する等。

まとめ

要約すると短いですが、実際は数倍の時間がかかってます。

AIの情報を鵜呑みにして解決する事も多いですが、そうでないケースが今回は多く、それで余計に時間がかかった気がします。

公式マニュアルを読んだり、検索して調べるスキルは必須です。