郭立 (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_configBad 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_configPort同時どうじはなさせないことです。

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

修復しゅうふくおこなったのは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 のシステムでは、フロントエンド状態じょうたい下層かそう設定せってい同時どうじ存在そんざいします。両者りょうしゃ一致いっちしないとき、実際じっさい動作どうさ起動きどうされたプロセスだけにしたがいます。

次の記事 →
Claude Code が自分で自分を怖がらせた:一度の「プロンプトインジェクション」騒動

コメント

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

最大 1000 文字。