郭立 (leeguoo)

# Synology DSM で SSH ポートを開けても接続できない:ポートずれの振り返り

Synology DSM パネルで SSH を有効化したりポートを変更したりしても、ポートが開かないことがあります。原因はパスワード、アカウント、ルーターのポート転送とは限らず、DSM のフロントエンド状態と sshd_config に残った古いポート設定が重なっている場合もあります。

2026年6月27日 · 記事 · 公開

このページの目次

<ruby>群晖<rt>シノロジー</rt></ruby> DSM <ruby>前端<rt>フロントエンド</rt></ruby>ポートと sshd <ruby>設定<rt>せってい</rt></ruby>の<ruby>分裂<rt>ぶんれつ</rt></ruby><ruby>模式図<rt>もしきず</rt></ruby>

Synology DSM で、たしかに SSH を有効ゆうこうにして、ポートも変更へんこうしたのに、外部がいぶからはまだ接続せつぞくできない。この問題もんだいは、一見いっけんするとルーターのポート転送てんそうが間違まちがっているか、アカウントやパスワードが違ちがうように見みえます。今回遭遇そうぐうしたのは、そのどちらでもありませんでした。

本当ほんとうの落おとし穴あなは、Synology 自身じしんのフロントエンド状態じょうたいと OpenSSH の設定せっていファイルの間あいだにありました。DSM パネルには新あたらしいポートが表示ひょうじされていますが、/etc/ssh/sshd_config にはまだ古ふるいポートが残のこっていました。その結果けっか、同おなじ sshd プロセスが同時どうじに2つのポートを待まち受うけることになりました。1つは DSM が認識にんしきしている新あたらしいポート、もう1つは手動しゅどう設定せっていで残のこった古ふるいポートです。

現場げんばはどんな状態じょうたいだったか

個人こじん環境かんきょうを公開こうかいページに書かかないため、以下では実際じっさいのホスト、アカウント、ポートを一般化いっぱんかしています。状況じょうきょうはこうでした。

  • DSM の「端末たんまつ」ページで SSH を有効ゆうこうにしていた。
  • 手元てもとの機器ききから <nas-host>:<old-port> に接続せつぞくすると、最初さいしょは Connection refused だった。
  • 一時的いちじてきな入口いりぐちからシステムに入はいったあと、OpenSSH の設定せっていファイルが構文こうぶんチェックに通とおらないことが分わかった。

そのとき、/etc/ssh/sshd_config の先頭せんとうに OpenSSH には属ぞくさない YAML 設定せっていが混まざっていました。内容ないようは重要じゅうようではありません。重要じゅうようなのは、それによって sshd が普通ふつうの YAML を SSH 設定せっていとして解析かいせきし、起動きどうに失敗しっぱいしたことです。

$ text
Bad configuration option: version:
Bad configuration option: services:

これにより、/bin/sshd -t -f /etc/ssh/sshd_config は Bad configuration option を連続れんぞくして報告ほうこくします。つまり、第一だいいちの根本こんぽん原因げんいんは明確めいかくでした。OpenSSH の設定せっていファイルが壊こわれていて、sshd がそもそも起動きどうできなかったのです。

そこで、/etc.defaults/ssh/sshd_config から既定きてい設定せっていを復元ふくげんし、SSH を起動きどうしました。この手順てじゅんで、私は小ちいさな間違まちがいをしました。最初さいしょに Port <old-port> をファイル末尾まつびへ追記ついきしたのですが、既定きてい設定せっていの末尾まつびはすでに Match ブロックに入はいっていました。OpenSSH はこう報告ほうこくしました。

$ text
Directive 'Port' is not allowed within a Match block

この誤あやまりは複雑ふくざつではありません。修正しゅうせい方法ほうほうは、Port を全体ぜんたい設定せってい領域りょういき、つまり Match より前まえに置おくことです。修正しゅうせい後、sshd -t は通とおり、古ふるいポートが待まち受うけを始はじめました。

2つ目めの落おとし穴あな:フロントエンドを変かえても、古ふるい設定せっていは消きえなかった

その後、DSM のフロントエンドで SSH を新あたらしいポートに変更へんこうしました。すると、さらに直感ちょっかんに反はんする状態じょうたいになりました。

$ text
tcp 0 0 0.0.0.0:<old-port> LISTEN sshd
tcp 0 0 0.0.0.0:<new-port> LISTEN sshd

同おなじ sshd プロセスが2つのポートを同時どうじに待まち受うけていました。sshd -T もそれを直接ちょくせつ確認かくにんしました。

$ text
port <old-port>
port <new-port>

なぜフロントエンドはすでに新あたらしいポートなのに、システムにはまだ古ふるいポートが残のこるのでしょうか。答こたえは2つのファイルにあります。

$ text
/etc/synoinfo.conf: ssh_port="<new-port>"
/etc/ssh/sshd_config: Port <old-port>

DSM 自身じしんのポート状態じょうたいは /etc/synoinfo.conf に保存ほぞんされています。手動しゅどう修復しゅうふくのときに残のこした Port <old-port> は OpenSSH 本来ほんらいの設定せっていです。Synology が sshd を起動きどうするとき、両方りょうほうを重かさねるため、二重にじゅうポートになります。

これで、フロントエンドでは「新あたらしいポートへの変更へんこうに成功せいこうしている」ように見みえるのに、実際じっさいのネットワーク動作どうさがすっきりしない理由りゆうも説明せつめいできます。フロントエンドは嘘うそをついていません。DSM 自身じしんが記録きろくしているポートだけを表示ひょうじしているのです。問題もんだいは、こちらが別べつに OpenSSH のポート設定せっていを手書てがきで1行ぎょう追加ついかしており、DSM はそれを代かわりに掃除そうじしてくれないことでした。

なぜ古ふるいポートは認証にんしょう後に切断せつだんされるのか

この点てんについては Synology のソースコードを見みていないため、現場げんばの証拠しょうこから判断はんだんするしかありません。

古ふるいポートは完全かんぜんに接続せつぞくを拒否きょひするわけではありません。認証にんしょう成功せいこうまでは進すすみます。sshd -ddd で一度いちどデバッグしたところ、ログでは public key が通とおり、PAM account/session も通とおったあと、子こプロセスが stderr に短みじかいエラーを書かいていました。クライアントにはこう見みえます。

$ text
Permission denied, please try again.

同おなじ機器きき、同おなじ管理者かんりしゃアカウント、同おなじ鍵かぎで、新あたらしいポートに変かえると入はいれます。この差さはアカウント権限けんげんの問題もんだいには見みえず、むしろ Synology がセッション段階だんかいで /etc/synoinfo.conf の SSH ポートだけを認みとめているように見みえます。古ふるいポートは OpenSSH 設定せっていによって余分よぶんに出でてきた入口いりぐちであり、もう DSM が認みとめる入口いりぐちではない、ということです。

この判断はんだんを過度かどに広ひろげる必要ひつようはありません。運用うんようにとって十分じゅうぶんな結論けつろんは、DSM の SSH ポートと sshd_config の Port に同時どうじに話はなさせないことです。

収束しゅうそく作業さぎょう

修復しゅうふくで行おこなったのは1つだけです。DSM のポート情報じょうほうを残のこし、手書てがきの残骸ざんがいを消けしました。

元もとの設定せっていをバックアップします。

$ bash
cp -a /etc/ssh/sshd_config /etc/ssh/sshd_config.before-remove-old-port

この行ぎょうを、

$ text
Port <old-port>

コメントに変かえます。

$ text
#Port <old-port>
# Removed local stale override; DSM SSH port is stored in /etc/synoinfo.conf ssh_port.

その後、チェックして reload します。

$ bash
/bin/sshd -t -f /etc/ssh/sshd_config
/bin/systemctl reload sshd

修正しゅうせい後の有効ゆうこう設定せっていには、ポートが1つだけ残のこりました。

$ text
port <new-port>

別べつの機器ききから検証けんしょうします。

$ bash
ssh -p <new-port> <admin-user>@<nas-host>
# ok

nc -vz -G 3 <nas-host> <old-port>
# Connection refused

nc -vz -G 3 <nas-host> 23
# Connection refused

これでようやく収束しゅうそくです。SSH は新あたらしいポートだけを残のこし、古ふるいポートは待まち受うけておらず、Telnet の 23 も閉とじています。

今回、どこで判断はんだんが遅おくれたか

最初さいしょは、アカウント、パスワード、PAM、shell、authorized_keys の権限けんげんに注意ちゅういを向むけていました。これらのチェックは間違まちがいではありません。しかし、「同おなじアカウントで新あたらしいポートなら入はいれるのに、古ふるいポートでは認証にんしょう後に切断せつだんされる」という現象げんしょうは説明せつめいできません。

もっと早はやく、この3つを実行じっこうすべきでした。

$ bash
/bin/sshd -T -f /etc/ssh/sshd_config | grep '^port '
grep -n 'ssh_port' /etc/synoinfo.conf
netstat -ltnp | grep -E '(:<new-port>|:<old-port>|:23)'

この3つで、「フロントエンド状態じょうたい」「OpenSSH の有効ゆうこう設定せってい」「実際じっさいの待まち受うけポート」を直接ちょくせつ並ならべられます。3つが一致いっちしないなら、まずパスワードや PAM を推測すいそくしないことです。

もう1つの教訓きょうくんは、メーカーの既定きてい設定せっていを復元ふくげんするとき、構文こうぶんが通とおることだけを見みてはいけない、ということです。DSM のようなシステムは純粋じゅんすいな Linux サーバーではありません。独自どくじの設定せっていデータベース、フロントエンド状態じょうたい、サービススクリプトがあります。/etc/ssh/sshd_config に手動しゅどうで書かき込こんだものは、DSM の管理かんりパネルを上書うわがきするのではなく、重かさなることがあります。

次回じかいはこの順番じゅんばんで調しらべる

今後 DSM の SSH ポート問題もんだいに遭遇そうぐうしたら、この順番じゅんばんで進すすめます。

  1. sshd -t で、まず設定せっていファイルを OpenSSH が解析かいせきできるか確認かくにんする。
  2. sshd -T | grep '^port ' で、OpenSSH が最終的さいしゅうてきにどのポートを認識にんしきしているか見みる。
  3. grep ssh_port /etc/synoinfo.conf で、DSM フロントエンドがどのポートを認識にんしきしているか見みる。
  4. netstat -ltnp で、実際じっさいの待まち受うけを見みる。
  5. 新あたらしい SSH セッションを開ひらいて検証けんしょうし、確認かくにんしてから Telnet を閉とじる。

今回の問題もんだいを修正しゅうせいしたあと、安定あんていした入口いりぐちは1つだけ残のこしました。

$ bash
ssh -p <new-port> <admin-user>@<nas-host>

推測すいそくを減へらし、最終さいしゅう状態じょうたいをよく見みること。NAS のような半分 appliance、半分 Linux のシステムでは、フロントエンド状態じょうたいと下層かそう設定せっていが同時どうじに存在そんざいします。両者りょうしゃが一致いっちしないとき、実際じっさいの動作どうさは起動きどうされたプロセスだけに従したがいます。

← 前の記事
agent にクロスオリジン iframe をクリックさせる:chrome-use がこの難題を突破した話
次の記事 →
Claude Code が自分で自分を怖がらせた:一度の「プロンプトインジェクション」騒動

コメント

コメントは即時公開されますが、ポリシー違反時は非表示になる場合があります。

最大 1000 文字。