Synology DSM 6.2.x: 管理者以外のユーザーとして SSH を実行する方法

Question 1

Docker を搭載した DiskStation では、OpenSSH コンテナを使用するのが最も簡単だとわかりました。私はを選択しましたlinuxserver/openssh-server。こうすることで、関連するデータのみをコンテナにマウントでき、Synology の構成を変更する必要がなくなります。

Answer

Docker を搭載した DiskStation では、OpenSSH コンテナを使用するのが最も簡単だとわかりました。私はを選択しましたlinuxserver/openssh-server。こうすることで、関連するデータのみをコンテナにマウントでき、Synology の構成を変更する必要がなくなります。

Question 2

これは、管理者グループのメンバーでなければ、SSH経由でSynology NASにログオンできないという問題の解決策です。これに関するいくつかのオンライン投稿を読むと、この問題はDSM 6.2.xに存在するようです。

ユーザーに ssh アクセス権限を与える正当な理由はたくさんあります。同時に、すべてのユーザーに管理者アクセス権限が必要なわけではないので、Synology Inc. がこのルールを強制するのは誤った判断だったようです。標準の sshd を使用してこの問題を解決する方法が見つからなかったため、独自の sshd をコンパイルしました。

このガイドによってコーヒーをこぼしたり、椅子でつまずいて猫の上に落ちたり、その他の損害を受けたりしても、私は一切責任を負いません。ただし、2019 年 10 月現在、私の研究室ではすべて動作することがテスト済みです。

はじめましょう。

テストに使用されたシステム:

 Synology DS418j with DSM 6.2.2-24922 Update 3, Linux hostname 4.4.59+ 
  #24922 aarch64 GNU/Linux synology_rtd1296_ds418j  
 Qubes release 4.0 (R4.0) with an App-VM running Fedora release 30 (Thirty)

前提条件:

管理者グループに属する既存のユーザーを使用して SSH 経由でアクセスできる Synology NAS。
Linux 環境であれば、仮想化できます。Mac ではシステムターミナルで十分でしょう。私の指示に忠実に従うなら、Fedora 30 をインストールしてください。Ubuntu を使用する場合は、少なくとも dnf ではなく apt-get を使用する必要があります。また、ディストリビューション固有の要素が他にもある可能性があります。

Linux ソフトウェアのインストール時に 'make install' を使用する習慣がある場合、警告です。このガイドに従うときは、自分が何をしているのかを理解していてガイドから逸脱しない限り、これを実行しないでください。そうすると、システムが壊れる可能性があります。さらに、コンパイルホストの観点から、このガイドの作業中は、一般ユーザー以外のユーザーである必要はありません。sudo が必要になるのは、ごくまれです。

さらに、何らかの理由で SSH デーモンが壊れてしまった場合は、いつでも DSM Web UI から Telnet を有効にし、Telnet 経由で Synology CLI に接続して、間違ったことを修正できます。また、実行しているすべてのことをメモし、実行する前に、置き換えているファイルと変更しているファイルをすべてバックアップしておくのが賢明です。このガイドを実行していて、リモート Synology サーバーで作業していて、何をしているのかよくわからない場合は、サーバーから締め出されてしまう危険性があります。少なくとも、アクセスを回復できる管理者の手など、出口があることを確認してください。

このガイドの残りの部分では、Synology と DS (Disk Station) は同じ意味で使用されます。

Synology Inc. はオリジナルの sshd バイナリを変更したと思われるため、このガイドでは、管理者グループ外のユーザーに Synology ボックスへの ssh アクセスを許可する sshd バイナリを追加する方法について説明します。

興味深いことに、クロスコンパイルと呼ばれるものを実行することが可能です。これは、あるプラットフォームでソフトウェアをコンパイルし、それを別のプラットフォームで実行できることを意味します。

openssh のソースコードとその依存関係は入手可能です。つまり、Linux システムでコンパイルし、ARM CPU を搭載した Synology で実行できるということです。

まず、Linux マシンにアクセスします。Linux がインストールされていない場合は、vmware や virtualbox などの仮想化ソフトウェアをダウンロードし、Linux 仮想マシンをインストールまたはロードします。Windows のサブシステムとして cygwin を使用しても機能する可能性があります。これについては、それぞれのドキュメントを参照してください。

このガイドの一部の要素は、お客様の固有の状況には適合しない可能性がありますので、それに応じてガイドの進め方を調整してください。このガイドは、私とまったく同じ設定でなくても、ssh の問題を解決するためのヒントをいくつか提供してくれるはずです。

まず、DS に搭載されているプロセッサを確認します。

特定の Synology モデルをここで見つけてください:https://www.synology.com/en-global/knowledgebase/DSM/tutorial/Compatibility_Peripherals/私の NAS の CPU の種類は何ですか?

また、Synology ターミナルで ssh セッションをチェックし、uname -a を実行するとヒントが得られるはずです。

私の場合、Synologyサポートセンターのリンクとuname -aの出力の両方で、Realtek RTD1293 CPUが搭載されていることがわかりました。これはARMプロセッサです。より興味深い情報については、以下をご覧ください。https://en.wikichip.org/wiki/arm/aarch64

したがって、ソースを取得して Linux ラップトップでクロスコンパイルし、バイナリを Synology に scp してログイン制限を回避する必要があります。

続行する前に、Synology に ssh できることを確認してください。ssh-fu が強力であれば、~/.ssh/config に次のようなエントリが設定されている可能性があります。

#My synology
Host DS
    Port 22
    Hostname 192.168.10.100
    User localuser
    IdentityFile /home/localuser/.ssh/id_ed25519

ローカルの状況に応じて変数を置き換えます。

少なくとも、sshのようなコマンドを実行してSynologyにログインできるはずです。[メールアドレス]デフォルト以外の ID ファイルまたはデフォルト以外のポートがある場合は、それらのパラメータを追加します。パスワードなしの SSH を構成する方法は、このガイドの範囲外です。Synology は、SSH ログインを許可する前に、ユーザーに属するすべてのファイルとディレクトリの権限についても厳しいことに注意してください。これについては、オンラインで多くの投稿があります。パスワードログインを使用して続行することもできますが、ローカルネットワーク上にいて、プライベートなエンドコンシューマーデバイスを使用している場合は、SSH へのログインに SSH キーを使用する方が便利です。秘密キーにパスフレーズを使用することもできます。また、既存のユーザーでログインしたときに、sudo whoami を実行できることも確認してください。これにより、ユーザーのパスワードを必要としないように sudo を構成していない限り、sudo パスワードの入力を求められます。Enter キーを押すと、「root」が表示されます。

さて、ここからが楽しい部分です!!

Linux (Fedora?) インスタンスにログインし、ターミナルを起動してプロジェクトディレクトリを作成し、そこに入ります。

mkdir ~/crosscompile ; cd ~/crosscompile

Linuxインスタンスでウェブブラウザを使用して、https://cdn.openbsd.org/pub/OpenBSD/OpenSSH/portable/、最新バージョンは下部にあります。2019 年 10 月リリース版は openssh-8.1p1 です。

Linux ターミナルに戻ってダウンロードしてください。私は 8.1p1 を使用しますが、新しいリリースが行われた際にこのガイドが表示された場合は、新しいバージョンを使用してください。

wget https://cdn.openbsd.org/pub/OpenBSD/OpenSSH/portable/openssh-8.1p1.tar.gz
wget https://cdn.openbsd.org/pub/OpenBSD/OpenSSH/portable/openssh-8.1p1.tar.gz.asc

2 行目はファイルの PGP 署名を取得します。

まだインストールされていない場合は、pgpdump をインストールします。

sudo dnf install pgpdump

を進めます

pgpdump openssh-8.1p1.tar.gz.asc

サンプル出力:

Old: Signature Packet(tag 2)(451 bytes)
    Ver 4 - new
    Sig type - Signature of a binary document(0x00).
    Pub alg - RSA Encrypt or Sign(pub 1)
    Hash alg - SHA512(hash 10)
    Hashed Sub: issuer fingerprint(sub 33)(21 bytes)
     v4 -   Fingerprint - 59 c2 11 8e d2 06 d9 27 e6 67 eb e3 d3 e5 f5 6b 6d 92 0d 30 
    Hashed Sub: signature creation time(sub 2)(4 bytes)
        Time - Wed Oct  9 02:39:36 CEST 2019
    Sub: issuer key ID(sub 16)(8 bytes)
        Key ID - 0xD3E5F56B6D920D30
    Hash left 2 bytes - 1c 52 
    RSA m^d mod n(3195 bits) - ...
        -> PKCS-1

キー ID 0xD3E5F56B6D920D30 をメモします (新しいバージョンでは異なる場合があります)。また、フィンガープリントもメモします。これについては後で説明します。

gpg2 がインストールされていない場合はインストールします。

sudo dnf install gpg2.

リリース元から PGP キーを取得します。

wget https://cdn.openbsd.org/pub/OpenBSD/OpenSSH/portable/DJM-GPG-KEY.asc

インポートします:

gpg2 --import DJM-GPG-KEY.asc

リリースキーを取得してインポートします。

wget https://cdn.openbsd.org/pub/OpenBSD/OpenSSH/RELEASE_KEY.asc
gpg2 --import RELEASE_KEY.asc

ダウンロードを確認します:

gpg2 --verify openssh-8.1p1.tar.gz.asc openssh-8.1p1.tar.gz

結果：

gpg: Signature made Wed Oct  9 02:39:36 2019 CEST
gpg:                using RSA key 59C2118ED206D927E667EBE3D3E5F56B6D920D30
gpg: Good signature from "Damien Miller <[email protected]>" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: 59C2 118E D206 D927 E667  EBE3 D3E5 F56B 6D92 0D30

フィンガープリントは、pgpdump が pgp 署名から教えてくれたものと一致していることに注意してください。すべて問題なさそうです。キーが署名によって信頼されていないのではないかと心配な場合は、キーの信頼を自分で編集するか、誰かに編集してもらう必要があります。非常に重要なインストールの場合は、Damien Miller に連絡してフィンガープリントを読んでもらうのも 1 つの方法です。おそらく、その分の報酬を支払うべきでしょう。

とにかく、ダウンロードが可能な限り安全であることを確認するには、いくつかのソースで検証する必要がありますので、試してみましょう。

ちょっと検索してみると、どうやらミラー氏のブログらしきものが見つかります。そして、この投稿にはさらに詳しい情報が記載されています。

http://blog.djm.net.au/2013/12/pgp-keys-rotated.html

次に、そのキー BLOB 全体をディスク上のファイルにコピーし、そのファイルに対して pgpdump ファイル名を実行します。

次のような出力が得られるはずです:

pgpdump keyblob | grep 0D30  | grep fin
Key fingerprint = 59C2 118E D206 D927 E667  EBE3 D3E5 F56B 6D92 0D30

興味がある場合は、コマンドの出力全体をテキストエディターにコピーし、ガイドの前半で説明したように「0xD3E5F56B6D920D30」を検索してください。すると、リリースキーがミラーの個人キーのサブキーであることがわかります。

さて、この時点では、openssh のダウンロードは正常であると想定しています。

openssh を解凍します:

tar xvzf openssh-8.1p1.tar.gz

必要なツールチェーンを決定する必要があります。https://originhelp.synology.com/developer-guide/compile_applications/download_dsm_tool_chain.html

私の場合は、次のコマンドで必要なものをダウンロードしました。

wget https://sourceforge.net/projects/dsgpl/files/DSM%206.2.2%20Tool%20Chains/Realtek%20RTD129x%20Linux%204.4.59/rtd1296-gcc494_glibc220_armv8-GPL.txz/download -O rtd1296-gcc494_glibc220_armv8-GPL.txz

私の知る限り、ダウンロードを確認する方法はありません。virustotal にアップロードしましたが、エンジンは見つかりませんでした。

ツールチェーンを抽出します。

sudo tar Jxvf rtd1296-gcc494_glibc220_armv8-GPL.txz -C /usr/local

さらに、zlib と openssl も必要です。

  wget https://zlib.net/zlib-1.2.11.tar.gz
  wget https://zlib.net/zlib-1.2.11.tar.gz.asc

(こちらも新しいバージョンを確認してください)

pgpdump zlib-1.2.11.tar.gz.asc | grep ID

キーID 0x783FCD8E58BCAFBA を指定します

取得してインポートします:

wget http://pgp.key-server.io/download/0x783FCD8E58BCAFBA
gpg2 --import 0x783FCD8E58BCAFBA

ダウンロードを確認します:

gpg2 --verify zlib-1.2.11.tar.gz.asc zlib-1.2.11.tar.gz

これはマーク・アドラーからのよい署名となるはずだ[メールアドレス]

この時点で、さらに検証が必要な場合は、指紋または DSA キーを使用して、Web 上の他の場所で参照を検索してみることができます。

Extract zlib: tar xvzf zlib-1.2.11.tar.gz

opensslも必要です:

  wget https://www.openssl.org/source/openssl-1.1.1d.tar.gz
  wget https://www.openssl.org/source/openssl-1.1.1d.tar.gz.sha256
  wget https://www.openssl.org/source/openssl-1.1.1d.tar.gz.asc

sha256sum openssl-1.1.1d.tar.gz gives 1e3a91bc1f9dfce01af26026f856e064eab4c8ee0a8f457b5ae30b40b8b711f2  
cat openssl-1.1.1d.tar.gz.sha256 gives 1e3a91bc1f9dfce01af26026f856e064eab4c8ee0a8f457b5ae30b40b8b711f2

これでファイルの整合性が検証されました。署名も確認してみましょう。

pgpdump openssl-1.1.1d.tar.gz.asc  | grep -E "Fin|ID"

結果：

 v4 -   Fingerprint - 86 57 ab b2 60 f0 56 b1 e5 19 08 39 d9 c4 d2 6d 0e 60 44 91 
Sub: issuer key ID(sub 16)(8 bytes)
    Key ID - 0xD9C4D26D0E604491

キーを取得してキーリングにインポートしましょう:

 wget http://pgp.key-server.io/download/0xD9C4D26D0E604491
 gpg2 --import 0xD9C4D26D0E604491

結果：

gpg: key D9C4D26D0E604491: public key "Matt Caswell <[email protected]>" imported

ダウンロードを確認します:

gpg2 --verify openssl-1.1.1d.tar.gz.asc openssl-1.1.1d.tar.gz

gpg: Signature made Tue Sep 10 15:13:14 2019 CEST
gpg:                using RSA key 8657ABB260F056B1E5190839D9C4D26D0E604491
gpg: Good signature from "Matt Caswell <[email protected]>" [unknown]
gpg:                 aka "Matt Caswell <[email protected]>" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: 8657 ABB2 60F0 56B1 E519  0839 D9C4 D26D 0E60 4491

指紋が一致し、同じ指紋への参照もここにあります:https://wiki.freebsd.org/OpenSSL/Base/Update111

この時点で、ダウンロードしたすべてのソフトウェアが検証され、問題がないと想定する必要があります。次に、ARM sshd バイナリをビルドします。

cd zlib-1.2.11

zlib を設定しましょう:

CC=/usr/local/aarch64-unknown-linux-gnueabi/bin/aarch64-unknown-linux-gnueabi-gcc LD=/usr/local/aarch64-unknown-linux-gnueabi/bin/aarch64-unknown-linux-gnueabi-ld CFLAGS+=-I/usr/local/aarch64-unknown-linux-gnueabi/aarch64-unknown-linux-gnueabi/sysroot/usr/include LDFLAGS+=-L/usr/local/aarch64-unknown-linux-gnueabi/aarch64-unknown-linux-gnueabi/lib ./configure

次に、次のようにします。

make

確認してみましょう:

ls -l libz*

次のように表示されるはずです:

-rw-rw-r-- 1 user user 155378 Oct 20 04:45 libz.a
lrwxrwxrwx 1 user user     14 Oct 20 04:45 libz.so -> libz.so.1.2.11
lrwxrwxrwx 1 user user     14 Oct 20 04:45 libz.so.1 -> libz.so.1.2.11
-rwxrwxr-x 1 user user 133664 Oct 20 04:45 libz.so.1.2.11

素晴らしい Synology ユーザーです! openssl をコンパイルしましょう!

それを解凍して作業ディレクトリに変更しましょう:

cd .. && tar xvzf openssl-1.1.1d.tar.gz && cd openssl-1.1.1d

次に設定を行います。

CFLAGS+=-I/usr/local/aarch64-unknown-linux-gnueabi/aarch64-unknown-linux-gnueabi/sysroot/usr/include LDFLAGS+=-L/usr/local/aarch64-unknown-linux-gnueabi/aarch64-unknown-linux-gnueabi/lib ./Configure  linux-generic64 shared  -DL_ENDIAN --prefix=/home/user0/opensslArm --openssldir=/home/user/opensslArm  CC=/usr/local/aarch64-unknown-linux-gnueabi/bin/aarch64-unknown-linux-gnueabi-gcc RANLIB=/usr/local/aarch64-unknown-linux-gnueabi/bin/aarch64-unknown-linux-gnueabi-ranlib AR=/usr/local/aarch64-unknown-linux-gnueabi/bin/aarch64-unknown-linux-gnueabi-ar LD=/usr/local/aarch64-unknown-linux-gnueabi/bin/aarch64-unknown-linux-gnueabi-ld MAKEDEPPROG=/usr/local/aarch64-unknown-linux-gnueabi/bin/aarch64-unknown-linux-gnueabi-gcc PROCESSOR=ARM

では、作ってみましょう:

make

これには少し時間がかかりますので、しばらくお待ちください。

確認してみましょう:

ls lib*so*

与えるべき

libcrypto.so  libcrypto.so.1.1  libssl.so  libssl.so.1.1

おめでとうございます。これが現実になることにどんどん近づいています!

opensshをコンパイルしてみましょう！

まず、設定する必要があります:

./configure --host=arm-linux --with-libs --with-zlib=/home/user/crosscompile/zlib-1.2.11 --with-ssl-dir=/home/user/crosscompile/openssl/openssl-1.1.1d --disable-etc-default-login CC=/usr/local/aarch64-unknown-linux-gnueabi/bin/aarch64-unknown-linux-gnueabi-gcc AR=/usr/local/aarch64-unknown-linux-gnueabi/bin/aarch64-unknown-linux-gnueabi-ar

では、作ってみましょう:

make

~/crosscompile/openssh-8.1p1 にいくつかの実行可能バイナリが作成されました。

作成した新しい sshd バイナリを使用して、通常のユーザーで ssh 経由で DS にログインできるかどうかを確認しましょう。これで、管理者グループに属する既存のユーザーで DS にパスワードなしでログインできるはずです。

新しい sshd と libcrypto を DS にコピーしましょう。

scp ~/crosscompile/openssh-8.1p1/sshd DS:~/newsshd
scp ~/crosscompile/openssl-1.1.1d/libcrypto.so.1.1 DS:~

次に、通常の方法で DS に ssh します。

ssh DS

次に、sshd_config のコピーを作成します。

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config_new

新しい設定ファイルを編集します。

vim /etc/ssh/sshd_config_new

「UsePAM yes」を「#UsePAM yes」に変更します

ホストキー /etc/ssh/ssh_host_ed25519_key のコメントを解除します。

保存して終了。

新しい sshd の所有権を変更します。

sudo chown root:root newsshd

ここで、いくつかのファイルに若干の編集を加える必要があります。まず、編集するファイルをバックアップします。

sudo cp /etc/passwd /etc/passwd.org && sudo cp /etc/group /etc/group.org

/etc/passwd の一番下に次の行を挿入します:

sshd:x:74:74:Privilege-separated SSH:/var/empty/sshd:/sbin/nologin

同様に、次の行を /etc/group の末尾に挿入します。

/etc/group:sshd:*:27:

上記の変更を行わないと、転送した sshd バイナリを実行するときに「特権分離ユーザー sshd が存在しません」というメッセージが表示されます。

それでは接続テストをしてみましょう！

DSの場合:

sudo LD_LIBRARY_PATH="/absolutepathtohomedir:$LD_LIBRARY_PATH" /absolutepathtohomedir/newsshd -p 444 -f /etc/ssh/sshd_config_new -h /etc/ssh/ssh_host_ed25519_key -d

これにより、新しい sshd バイナリがデバッグモードで起動します。

これで、Linuxインスタンスから通常通り接続できるようになりました。

ssh -p 444 user@DS

ついに、素晴らしい代替品ができました。

必ず、実行したことはすべてメモし、ファイルと一緒にどこかに保管してください。Synology Inc. は、アップデート時に編集内容やファイルを置き換えることがあることで知られています。このような場合は、DSM 経由で telnet を有効にし、ローカルネットワークで telnet 経由でログインして設定を復元する必要があります。システムを監視する cronjob を設定し、アップデートに伴う変更を自動的に元に戻すこともできます。設定によっては、すでに非常に安全でセグメント化されたネットワークを使用している場合は、DSM を頻繁に更新する必要がない場合があります。

ARM アーキテクチャ用にコンパイルした関連バイナリは、 ~/crosscompile/openssh-8.1p1 にあります。

./ssh-agent (認証エージェント)
./sftp-server (SFTP サーバーサブシステム)
./ssh (OpenSSH SSH クライアント (リモートログインプログラム))
./ssh-keyscan (ssh公開鍵を収集)
./ssh-keygen (認証キーの生成、管理、変換)
./sftp (セキュアファイル転送プログラム)
./ssh-keysign (デフォルトでは無効)
./ssh-add (認証エージェントに RSA または DSA ID を追加します)
./scp (セキュアコピー (リモートファイルコピープログラム))
./ssh-pkcs11-helper (ssh-agent (PKCS#11 サポートのヘルパープログラム)
./sshd (OpenSSH SSH デーモン)

これらのうちどれが必要かを判断する必要があります。sshd と scp のみを使用する場合は、これらのバイナリを置き換えるだけで十分かもしれません。

まず、元の /etc/ssh/sshd_config ファイルを編集し、「UsePAM yes」を「#UsePAM yes」にコメントし、「HostKey /etc/ssh/ssh_host_ed25519_key」のコメントを解除します。

実際には ed25519 キーのみを使用する必要があります。他のタイプのキーを使用する場合は、それに応じてコメントを解除してください。

openssl サポートが利用可能であることを確認しましょう。

私の DS では、何も上書きされませんが、状況はさまざまです。ターゲットがすでに存在するかどうかを確認します。この方法は、これを機能させる簡単な方法であるため、私はこの方法で実行しました。共有オブジェクトファイルをカスタムパスに配置し、共有オブジェクトファイルの検索パスに追加することもできます。

sudo mv ~/libcrypto.so.1.1 /usr/lib/

置き換えたいファイルの場所を見つけます。

which sshd ; which scp

結果：

/bin/sshd
/bin/scp

これら 2 つのファイルをバックアップします。

sudo cp /bin/sshd /bin/sshd.DS.orginal
sudo cp /bin/scp /bin/scp.DS.orginal

Linux インスタンスを終了し、新しく作成された scp ファイルをコピーします。

scp scp DS:~

DS に ssh し、scp ファイルを移動して正しい所有権を設定します。

sudo mv ~/scp /bin
sudo chown root:root /bin/scp

/bin/sshd はアクティブなので上書きできないため、これを強制終了する必要があります。ただし、その前に、DS への代替パスを確保するために、新しく作成した sshd を起動しておく必要があります。

Linux インスタンスで新しいターミナルを起動し、通常の方法で DS に ssh します。

ssh DS

次に、新しい sshd サーバーのインスタンスを生成します。

sudo /absolutepathtohomedir/newsshd -p 777 -f /etc/ssh/sshd_config_new -h /etc/ssh/ssh_host_ed25519_key

ssh セッションを終了し、新しく生成された ssh バイナリによって制御されるセッションにログインしてみます。

ssh -p 777 user@DS

ここで、ポート 22 の元の ssh サーバーを終了します。

sudo su

次にSSH設定を編集します

vim /etc/init/sshd.conf

respawn 行をコメントアウトして、次のようになります。

#respawn
#respawn limit 5 10

それから：

netstat -ap | grep ssh

右側のプロセスIDを見つけます

行は次のようになります。

tcp        0      0 0.0.0.0:ssh             0.0.0.0:*               LISTEN      9508/sshd

ssh-shellを停止する

synoservice --hard-stop ssh-shell

sshd プロセスを終了します。

kill -9 9508

プロセスがなくなり、ポート 22 で何もリッスンしていないかどうかを確認します。

netstat -tpa | grep 22

このガイドでさまざまなポートを試した場合は、sshd の他のインスタンスをシャットダウンする必要がある可能性があります。

すべてが失敗した場合は、DSM 経由で ssh を無効にすることができます。

ついに：

cp /fullhomepath/newsshd /bin/sshd && chown root:root /bin/sshd

先ほど行った respawn コメントを /etc/init/sshd.conf に逆順に記述します。

新しいsshdがローカルのsshd_configファイルが存在しないと報告するので、このシンボリックリンクを作成します。

ln -s /etc/ssh/sshd_config /usr/local/etc/sshd_config

sshd を再度有効にします:

synoservice --hard-enable ssh-shell

次に、コピーしたファイルがコンパイルされたファイルと一致することを確認します。

DSの場合:

sha256sum /bin/sshd /bin/scp

Linux インスタンスの場合:

sha256sum ~/crosscompile/openssh-8.1p1/sshd ~/crosscompile/openssh-8.1p1/scp

それぞれのバイナリのハッシュはシステム間で一致する必要があります。

新しいファイルと古いファイルのバージョンを確認することもできます。

 ash-4.3# /bin/sshd.DS.orginal --version ; /bin/scp.DS.orginal --version

 unknown option -- - OpenSSH_7.4p1, OpenSSL 1.0.2r-fips  26 Feb 2019 usage: sshd [-46DdeiqTt] [-C connection_spec] [-c
     host_cert_file]
                 [-E log_file] [-f config_file] [-g login_grace_time]
                 [-h host_key_file] [-o option] [-p port] [-u len] unknown 

option -- - usage: scp [-12346BCpqrv] [-c cipher] [-F ssh_config] [-i
         identity_file]
                    [-l limit] [-o ssh_option] [-P port] [-S program]
                    [[user@]host1:]file1 ... [[user@]host2:]file2

ash-4.3# /bin/sshd --version ; /bin/scp --version

unknown option -- -
OpenSSH_8.1p1, OpenSSL 1.1.1d  10 Sep 2019
usage: sshd [-46DdeiqTt] [-C connection_spec] [-c host_cert_file]
            [-E log_file] [-f config_file] [-g login_grace_time]
            [-h host_key_file] [-o option] [-p port] [-u len]
unknown option -- -
usage: scp [-346BCpqrTv] [-c cipher] [-F ssh_config] [-i identity_file]
            [-J destination] [-l limit] [-o ssh_option] [-P port]
            [-S program] source ... target

これで、Synology に再度通常通り接続してみることができます。

ssh DS

「警告: リモートホスト ID が変更されました!」のようなメッセージが表示されます。

これは予想通りです。/home/user/.ssh/known_hosts を編集して手動で修正してください。古いキーを削除して再接続し、新しいキーを受け入れるだけで十分なはずです。

最後に、再起動によって何かが変更されたかどうかを確認するには、必要に応じて DS を再起動します。

/etc/passwd および /etc/group 内のカスタム行が確実に保持されるようにするには、以下のスクリプトを使用して /usr/local/bin/pwdgroupfixer.sh に保存し、chmod +x で実行可能にすることを忘れないでください。

ルートの crontab にエントリを作成します。

*/5 *   *   *   *   root    /bin/sh /usr/local/bin/pwdgroupfixer.sh

Synology は crontab のフォーマットに細心の注意を払っていることに注意してください。スペースの代わりにタブを使用します。既存のエントリを使用して新しい行にコピーし、変更することは良いヒントです。

最後にcrontabサービスを再起動します。

sudo synoservice -restart crond

#!/bin/sh
#pwdgroupfixer.sh

#Entries to support sshd

PASSWORDFILE=/etc/passwd
USERLINE="sshd:x:74:74:Privilege-separated SSH:/var/empty/sshd:/sbin/nologin"

GROUPFILE=/etc/group
GROUPLINE="/etc/group:sshd:*:27:"


itemcheck(){
  FILE=$1
  ITEM=$2
DATE=`/bin/date +%Y-%m-%d`
TEMPFILE=/tmp/$DATE
/bin/echo '0' > $TEMPFILE

FOUND=0
/bin/sed '/^[ \t\r\n]*$/d' $FILE | while read LINE; do
    if [[ ${LINE:0:1} != "#" ]]; then
         if [ "$LINE" == "$ITEM" ];
         then
            let FOUND++
            /bin/echo $FOUND > $TEMPFILE
         fi
     fi
  done

FOUND=`/bin/cat $TEMPFILE`

if [ "$FOUND" -eq "0" ]; then
    /bin/cp $FILE $FILE.`/bin/date +%Y-%m-%d`
    /bin/echo $ITEM >> $FILE
fi

}

itemcheck $PASSWORDFILE "$USERLINE"
itemcheck $GROUPFILE $GROUPLINE

#end pwdgroupfixer.sh

Answer

これは、管理者グループのメンバーでなければ、SSH経由でSynology NASにログオンできないという問題の解決策です。これに関するいくつかのオンライン投稿を読むと、この問題はDSM 6.2.xに存在するようです。

ユーザーに ssh アクセス権限を与える正当な理由はたくさんあります。同時に、すべてのユーザーに管理者アクセス権限が必要なわけではないので、Synology Inc. がこのルールを強制するのは誤った判断だったようです。標準の sshd を使用してこの問題を解決する方法が見つからなかったため、独自の sshd をコンパイルしました。

このガイドによってコーヒーをこぼしたり、椅子でつまずいて猫の上に落ちたり、その他の損害を受けたりしても、私は一切責任を負いません。ただし、2019 年 10 月現在、私の研究室ではすべて動作することがテスト済みです。

はじめましょう。

テストに使用されたシステム:

 Synology DS418j with DSM 6.2.2-24922 Update 3, Linux hostname 4.4.59+ 
  #24922 aarch64 GNU/Linux synology_rtd1296_ds418j  
 Qubes release 4.0 (R4.0) with an App-VM running Fedora release 30 (Thirty)

前提条件:

管理者グループに属する既存のユーザーを使用して SSH 経由でアクセスできる Synology NAS。
Linux 環境であれば、仮想化できます。Mac ではシステムターミナルで十分でしょう。私の指示に忠実に従うなら、Fedora 30 をインストールしてください。Ubuntu を使用する場合は、少なくとも dnf ではなく apt-get を使用する必要があります。また、ディストリビューション固有の要素が他にもある可能性があります。

Linux ソフトウェアのインストール時に 'make install' を使用する習慣がある場合、警告です。このガイドに従うときは、自分が何をしているのかを理解していてガイドから逸脱しない限り、これを実行しないでください。そうすると、システムが壊れる可能性があります。さらに、コンパイルホストの観点から、このガイドの作業中は、一般ユーザー以外のユーザーである必要はありません。sudo が必要になるのは、ごくまれです。

さらに、何らかの理由で SSH デーモンが壊れてしまった場合は、いつでも DSM Web UI から Telnet を有効にし、Telnet 経由で Synology CLI に接続して、間違ったことを修正できます。また、実行しているすべてのことをメモし、実行する前に、置き換えているファイルと変更しているファイルをすべてバックアップしておくのが賢明です。このガイドを実行していて、リモート Synology サーバーで作業していて、何をしているのかよくわからない場合は、サーバーから締め出されてしまう危険性があります。少なくとも、アクセスを回復できる管理者の手など、出口があることを確認してください。

このガイドの残りの部分では、Synology と DS (Disk Station) は同じ意味で使用されます。

Synology Inc. はオリジナルの sshd バイナリを変更したと思われるため、このガイドでは、管理者グループ外のユーザーに Synology ボックスへの ssh アクセスを許可する sshd バイナリを追加する方法について説明します。

興味深いことに、クロスコンパイルと呼ばれるものを実行することが可能です。これは、あるプラットフォームでソフトウェアをコンパイルし、それを別のプラットフォームで実行できることを意味します。

openssh のソースコードとその依存関係は入手可能です。つまり、Linux システムでコンパイルし、ARM CPU を搭載した Synology で実行できるということです。

まず、Linux マシンにアクセスします。Linux がインストールされていない場合は、vmware や virtualbox などの仮想化ソフトウェアをダウンロードし、Linux 仮想マシンをインストールまたはロードします。Windows のサブシステムとして cygwin を使用しても機能する可能性があります。これについては、それぞれのドキュメントを参照してください。

このガイドの一部の要素は、お客様の固有の状況には適合しない可能性がありますので、それに応じてガイドの進め方を調整してください。このガイドは、私とまったく同じ設定でなくても、ssh の問題を解決するためのヒントをいくつか提供してくれるはずです。

まず、DS に搭載されているプロセッサを確認します。

特定の Synology モデルをここで見つけてください:https://www.synology.com/en-global/knowledgebase/DSM/tutorial/Compatibility_Peripherals/私の NAS の CPU の種類は何ですか?

また、Synology ターミナルで ssh セッションをチェックし、uname -a を実行するとヒントが得られるはずです。

私の場合、Synologyサポートセンターのリンクとuname -aの出力の両方で、Realtek RTD1293 CPUが搭載されていることがわかりました。これはARMプロセッサです。より興味深い情報については、以下をご覧ください。https://en.wikichip.org/wiki/arm/aarch64

したがって、ソースを取得して Linux ラップトップでクロスコンパイルし、バイナリを Synology に scp してログイン制限を回避する必要があります。

続行する前に、Synology に ssh できることを確認してください。ssh-fu が強力であれば、~/.ssh/config に次のようなエントリが設定されている可能性があります。

#My synology
Host DS
    Port 22
    Hostname 192.168.10.100
    User localuser
    IdentityFile /home/localuser/.ssh/id_ed25519

ローカルの状況に応じて変数を置き換えます。

少なくとも、sshのようなコマンドを実行してSynologyにログインできるはずです。[メールアドレス]デフォルト以外の ID ファイルまたはデフォルト以外のポートがある場合は、それらのパラメータを追加します。パスワードなしの SSH を構成する方法は、このガイドの範囲外です。Synology は、SSH ログインを許可する前に、ユーザーに属するすべてのファイルとディレクトリの権限についても厳しいことに注意してください。これについては、オンラインで多くの投稿があります。パスワードログインを使用して続行することもできますが、ローカルネットワーク上にいて、プライベートなエンドコンシューマーデバイスを使用している場合は、SSH へのログインに SSH キーを使用する方が便利です。秘密キーにパスフレーズを使用することもできます。また、既存のユーザーでログインしたときに、sudo whoami を実行できることも確認してください。これにより、ユーザーのパスワードを必要としないように sudo を構成していない限り、sudo パスワードの入力を求められます。Enter キーを押すと、「root」が表示されます。

さて、ここからが楽しい部分です!!

Linux (Fedora?) インスタンスにログインし、ターミナルを起動してプロジェクトディレクトリを作成し、そこに入ります。

mkdir ~/crosscompile ; cd ~/crosscompile

Linuxインスタンスでウェブブラウザを使用して、https://cdn.openbsd.org/pub/OpenBSD/OpenSSH/portable/、最新バージョンは下部にあります。2019 年 10 月リリース版は openssh-8.1p1 です。

Linux ターミナルに戻ってダウンロードしてください。私は 8.1p1 を使用しますが、新しいリリースが行われた際にこのガイドが表示された場合は、新しいバージョンを使用してください。

wget https://cdn.openbsd.org/pub/OpenBSD/OpenSSH/portable/openssh-8.1p1.tar.gz
wget https://cdn.openbsd.org/pub/OpenBSD/OpenSSH/portable/openssh-8.1p1.tar.gz.asc

2 行目はファイルの PGP 署名を取得します。

まだインストールされていない場合は、pgpdump をインストールします。

sudo dnf install pgpdump

を進めます

pgpdump openssh-8.1p1.tar.gz.asc

サンプル出力:

Old: Signature Packet(tag 2)(451 bytes)
    Ver 4 - new
    Sig type - Signature of a binary document(0x00).
    Pub alg - RSA Encrypt or Sign(pub 1)
    Hash alg - SHA512(hash 10)
    Hashed Sub: issuer fingerprint(sub 33)(21 bytes)
     v4 -   Fingerprint - 59 c2 11 8e d2 06 d9 27 e6 67 eb e3 d3 e5 f5 6b 6d 92 0d 30 
    Hashed Sub: signature creation time(sub 2)(4 bytes)
        Time - Wed Oct  9 02:39:36 CEST 2019
    Sub: issuer key ID(sub 16)(8 bytes)
        Key ID - 0xD3E5F56B6D920D30
    Hash left 2 bytes - 1c 52 
    RSA m^d mod n(3195 bits) - ...
        -> PKCS-1

キー ID 0xD3E5F56B6D920D30 をメモします (新しいバージョンでは異なる場合があります)。また、フィンガープリントもメモします。これについては後で説明します。

gpg2 がインストールされていない場合はインストールします。

sudo dnf install gpg2.

リリース元から PGP キーを取得します。

wget https://cdn.openbsd.org/pub/OpenBSD/OpenSSH/portable/DJM-GPG-KEY.asc

インポートします:

gpg2 --import DJM-GPG-KEY.asc

リリースキーを取得してインポートします。

wget https://cdn.openbsd.org/pub/OpenBSD/OpenSSH/RELEASE_KEY.asc
gpg2 --import RELEASE_KEY.asc

ダウンロードを確認します:

gpg2 --verify openssh-8.1p1.tar.gz.asc openssh-8.1p1.tar.gz

結果：

gpg: Signature made Wed Oct  9 02:39:36 2019 CEST
gpg:                using RSA key 59C2118ED206D927E667EBE3D3E5F56B6D920D30
gpg: Good signature from "Damien Miller <[email protected]>" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: 59C2 118E D206 D927 E667  EBE3 D3E5 F56B 6D92 0D30

フィンガープリントは、pgpdump が pgp 署名から教えてくれたものと一致していることに注意してください。すべて問題なさそうです。キーが署名によって信頼されていないのではないかと心配な場合は、キーの信頼を自分で編集するか、誰かに編集してもらう必要があります。非常に重要なインストールの場合は、Damien Miller に連絡してフィンガープリントを読んでもらうのも 1 つの方法です。おそらく、その分の報酬を支払うべきでしょう。

とにかく、ダウンロードが可能な限り安全であることを確認するには、いくつかのソースで検証する必要がありますので、試してみましょう。

ちょっと検索してみると、どうやらミラー氏のブログらしきものが見つかります。そして、この投稿にはさらに詳しい情報が記載されています。

http://blog.djm.net.au/2013/12/pgp-keys-rotated.html

次に、そのキー BLOB 全体をディスク上のファイルにコピーし、そのファイルに対して pgpdump ファイル名を実行します。

次のような出力が得られるはずです:

pgpdump keyblob | grep 0D30  | grep fin
Key fingerprint = 59C2 118E D206 D927 E667  EBE3 D3E5 F56B 6D92 0D30

興味がある場合は、コマンドの出力全体をテキストエディターにコピーし、ガイドの前半で説明したように「0xD3E5F56B6D920D30」を検索してください。すると、リリースキーがミラーの個人キーのサブキーであることがわかります。

さて、この時点では、openssh のダウンロードは正常であると想定しています。

openssh を解凍します:

tar xvzf openssh-8.1p1.tar.gz

必要なツールチェーンを決定する必要があります。https://originhelp.synology.com/developer-guide/compile_applications/download_dsm_tool_chain.html

私の場合は、次のコマンドで必要なものをダウンロードしました。

wget https://sourceforge.net/projects/dsgpl/files/DSM%206.2.2%20Tool%20Chains/Realtek%20RTD129x%20Linux%204.4.59/rtd1296-gcc494_glibc220_armv8-GPL.txz/download -O rtd1296-gcc494_glibc220_armv8-GPL.txz

私の知る限り、ダウンロードを確認する方法はありません。virustotal にアップロードしましたが、エンジンは見つかりませんでした。

ツールチェーンを抽出します。

sudo tar Jxvf rtd1296-gcc494_glibc220_armv8-GPL.txz -C /usr/local

さらに、zlib と openssl も必要です。

  wget https://zlib.net/zlib-1.2.11.tar.gz
  wget https://zlib.net/zlib-1.2.11.tar.gz.asc

(こちらも新しいバージョンを確認してください)

pgpdump zlib-1.2.11.tar.gz.asc | grep ID

キーID 0x783FCD8E58BCAFBA を指定します

取得してインポートします:

wget http://pgp.key-server.io/download/0x783FCD8E58BCAFBA
gpg2 --import 0x783FCD8E58BCAFBA

ダウンロードを確認します:

gpg2 --verify zlib-1.2.11.tar.gz.asc zlib-1.2.11.tar.gz

これはマーク・アドラーからのよい署名となるはずだ[メールアドレス]

この時点で、さらに検証が必要な場合は、指紋または DSA キーを使用して、Web 上の他の場所で参照を検索してみることができます。

Extract zlib: tar xvzf zlib-1.2.11.tar.gz

opensslも必要です:

  wget https://www.openssl.org/source/openssl-1.1.1d.tar.gz
  wget https://www.openssl.org/source/openssl-1.1.1d.tar.gz.sha256
  wget https://www.openssl.org/source/openssl-1.1.1d.tar.gz.asc

sha256sum openssl-1.1.1d.tar.gz gives 1e3a91bc1f9dfce01af26026f856e064eab4c8ee0a8f457b5ae30b40b8b711f2  
cat openssl-1.1.1d.tar.gz.sha256 gives 1e3a91bc1f9dfce01af26026f856e064eab4c8ee0a8f457b5ae30b40b8b711f2

これでファイルの整合性が検証されました。署名も確認してみましょう。

pgpdump openssl-1.1.1d.tar.gz.asc  | grep -E "Fin|ID"

結果：

 v4 -   Fingerprint - 86 57 ab b2 60 f0 56 b1 e5 19 08 39 d9 c4 d2 6d 0e 60 44 91 
Sub: issuer key ID(sub 16)(8 bytes)
    Key ID - 0xD9C4D26D0E604491

キーを取得してキーリングにインポートしましょう:

 wget http://pgp.key-server.io/download/0xD9C4D26D0E604491
 gpg2 --import 0xD9C4D26D0E604491

結果：

gpg: key D9C4D26D0E604491: public key "Matt Caswell <[email protected]>" imported

ダウンロードを確認します:

gpg2 --verify openssl-1.1.1d.tar.gz.asc openssl-1.1.1d.tar.gz

gpg: Signature made Tue Sep 10 15:13:14 2019 CEST
gpg:                using RSA key 8657ABB260F056B1E5190839D9C4D26D0E604491
gpg: Good signature from "Matt Caswell <[email protected]>" [unknown]
gpg:                 aka "Matt Caswell <[email protected]>" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: 8657 ABB2 60F0 56B1 E519  0839 D9C4 D26D 0E60 4491

指紋が一致し、同じ指紋への参照もここにあります:https://wiki.freebsd.org/OpenSSL/Base/Update111

この時点で、ダウンロードしたすべてのソフトウェアが検証され、問題がないと想定する必要があります。次に、ARM sshd バイナリをビルドします。

cd zlib-1.2.11

zlib を設定しましょう:

CC=/usr/local/aarch64-unknown-linux-gnueabi/bin/aarch64-unknown-linux-gnueabi-gcc LD=/usr/local/aarch64-unknown-linux-gnueabi/bin/aarch64-unknown-linux-gnueabi-ld CFLAGS+=-I/usr/local/aarch64-unknown-linux-gnueabi/aarch64-unknown-linux-gnueabi/sysroot/usr/include LDFLAGS+=-L/usr/local/aarch64-unknown-linux-gnueabi/aarch64-unknown-linux-gnueabi/lib ./configure

次に、次のようにします。

make

確認してみましょう:

ls -l libz*

次のように表示されるはずです:

-rw-rw-r-- 1 user user 155378 Oct 20 04:45 libz.a
lrwxrwxrwx 1 user user     14 Oct 20 04:45 libz.so -> libz.so.1.2.11
lrwxrwxrwx 1 user user     14 Oct 20 04:45 libz.so.1 -> libz.so.1.2.11
-rwxrwxr-x 1 user user 133664 Oct 20 04:45 libz.so.1.2.11

素晴らしい Synology ユーザーです! openssl をコンパイルしましょう!

それを解凍して作業ディレクトリに変更しましょう:

cd .. && tar xvzf openssl-1.1.1d.tar.gz && cd openssl-1.1.1d

次に設定を行います。

CFLAGS+=-I/usr/local/aarch64-unknown-linux-gnueabi/aarch64-unknown-linux-gnueabi/sysroot/usr/include LDFLAGS+=-L/usr/local/aarch64-unknown-linux-gnueabi/aarch64-unknown-linux-gnueabi/lib ./Configure  linux-generic64 shared  -DL_ENDIAN --prefix=/home/user0/opensslArm --openssldir=/home/user/opensslArm  CC=/usr/local/aarch64-unknown-linux-gnueabi/bin/aarch64-unknown-linux-gnueabi-gcc RANLIB=/usr/local/aarch64-unknown-linux-gnueabi/bin/aarch64-unknown-linux-gnueabi-ranlib AR=/usr/local/aarch64-unknown-linux-gnueabi/bin/aarch64-unknown-linux-gnueabi-ar LD=/usr/local/aarch64-unknown-linux-gnueabi/bin/aarch64-unknown-linux-gnueabi-ld MAKEDEPPROG=/usr/local/aarch64-unknown-linux-gnueabi/bin/aarch64-unknown-linux-gnueabi-gcc PROCESSOR=ARM

では、作ってみましょう:

make

これには少し時間がかかりますので、しばらくお待ちください。

確認してみましょう:

ls lib*so*

与えるべき

libcrypto.so  libcrypto.so.1.1  libssl.so  libssl.so.1.1

おめでとうございます。これが現実になることにどんどん近づいています!

opensshをコンパイルしてみましょう！

まず、設定する必要があります:

./configure --host=arm-linux --with-libs --with-zlib=/home/user/crosscompile/zlib-1.2.11 --with-ssl-dir=/home/user/crosscompile/openssl/openssl-1.1.1d --disable-etc-default-login CC=/usr/local/aarch64-unknown-linux-gnueabi/bin/aarch64-unknown-linux-gnueabi-gcc AR=/usr/local/aarch64-unknown-linux-gnueabi/bin/aarch64-unknown-linux-gnueabi-ar

では、作ってみましょう:

make

~/crosscompile/openssh-8.1p1 にいくつかの実行可能バイナリが作成されました。

作成した新しい sshd バイナリを使用して、通常のユーザーで ssh 経由で DS にログインできるかどうかを確認しましょう。これで、管理者グループに属する既存のユーザーで DS にパスワードなしでログインできるはずです。

新しい sshd と libcrypto を DS にコピーしましょう。

scp ~/crosscompile/openssh-8.1p1/sshd DS:~/newsshd
scp ~/crosscompile/openssl-1.1.1d/libcrypto.so.1.1 DS:~

次に、通常の方法で DS に ssh します。

ssh DS

次に、sshd_config のコピーを作成します。

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config_new

新しい設定ファイルを編集します。

vim /etc/ssh/sshd_config_new

「UsePAM yes」を「#UsePAM yes」に変更します

ホストキー /etc/ssh/ssh_host_ed25519_key のコメントを解除します。

保存して終了。

新しい sshd の所有権を変更します。

sudo chown root:root newsshd

ここで、いくつかのファイルに若干の編集を加える必要があります。まず、編集するファイルをバックアップします。

sudo cp /etc/passwd /etc/passwd.org && sudo cp /etc/group /etc/group.org

/etc/passwd の一番下に次の行を挿入します:

sshd:x:74:74:Privilege-separated SSH:/var/empty/sshd:/sbin/nologin

同様に、次の行を /etc/group の末尾に挿入します。

/etc/group:sshd:*:27:

上記の変更を行わないと、転送した sshd バイナリを実行するときに「特権分離ユーザー sshd が存在しません」というメッセージが表示されます。

それでは接続テストをしてみましょう！

DSの場合:

sudo LD_LIBRARY_PATH="/absolutepathtohomedir:$LD_LIBRARY_PATH" /absolutepathtohomedir/newsshd -p 444 -f /etc/ssh/sshd_config_new -h /etc/ssh/ssh_host_ed25519_key -d

これにより、新しい sshd バイナリがデバッグモードで起動します。

これで、Linuxインスタンスから通常通り接続できるようになりました。

ssh -p 444 user@DS

ついに、素晴らしい代替品ができました。

必ず、実行したことはすべてメモし、ファイルと一緒にどこかに保管してください。Synology Inc. は、アップデート時に編集内容やファイルを置き換えることがあることで知られています。このような場合は、DSM 経由で telnet を有効にし、ローカルネットワークで telnet 経由でログインして設定を復元する必要があります。システムを監視する cronjob を設定し、アップデートに伴う変更を自動的に元に戻すこともできます。設定によっては、すでに非常に安全でセグメント化されたネットワークを使用している場合は、DSM を頻繁に更新する必要がない場合があります。

ARM アーキテクチャ用にコンパイルした関連バイナリは、 ~/crosscompile/openssh-8.1p1 にあります。

./ssh-agent (認証エージェント)
./sftp-server (SFTP サーバーサブシステム)
./ssh (OpenSSH SSH クライアント (リモートログインプログラム))
./ssh-keyscan (ssh公開鍵を収集)
./ssh-keygen (認証キーの生成、管理、変換)
./sftp (セキュアファイル転送プログラム)
./ssh-keysign (デフォルトでは無効)
./ssh-add (認証エージェントに RSA または DSA ID を追加します)
./scp (セキュアコピー (リモートファイルコピープログラム))
./ssh-pkcs11-helper (ssh-agent (PKCS#11 サポートのヘルパープログラム)
./sshd (OpenSSH SSH デーモン)

これらのうちどれが必要かを判断する必要があります。sshd と scp のみを使用する場合は、これらのバイナリを置き換えるだけで十分かもしれません。

まず、元の /etc/ssh/sshd_config ファイルを編集し、「UsePAM yes」を「#UsePAM yes」にコメントし、「HostKey /etc/ssh/ssh_host_ed25519_key」のコメントを解除します。

実際には ed25519 キーのみを使用する必要があります。他のタイプのキーを使用する場合は、それに応じてコメントを解除してください。

openssl サポートが利用可能であることを確認しましょう。

私の DS では、何も上書きされませんが、状況はさまざまです。ターゲットがすでに存在するかどうかを確認します。この方法は、これを機能させる簡単な方法であるため、私はこの方法で実行しました。共有オブジェクトファイルをカスタムパスに配置し、共有オブジェクトファイルの検索パスに追加することもできます。

sudo mv ~/libcrypto.so.1.1 /usr/lib/

置き換えたいファイルの場所を見つけます。

which sshd ; which scp

結果：

/bin/sshd
/bin/scp

これら 2 つのファイルをバックアップします。

sudo cp /bin/sshd /bin/sshd.DS.orginal
sudo cp /bin/scp /bin/scp.DS.orginal

Linux インスタンスを終了し、新しく作成された scp ファイルをコピーします。

scp scp DS:~

DS に ssh し、scp ファイルを移動して正しい所有権を設定します。

sudo mv ~/scp /bin
sudo chown root:root /bin/scp

/bin/sshd はアクティブなので上書きできないため、これを強制終了する必要があります。ただし、その前に、DS への代替パスを確保するために、新しく作成した sshd を起動しておく必要があります。

Linux インスタンスで新しいターミナルを起動し、通常の方法で DS に ssh します。

ssh DS

次に、新しい sshd サーバーのインスタンスを生成します。

sudo /absolutepathtohomedir/newsshd -p 777 -f /etc/ssh/sshd_config_new -h /etc/ssh/ssh_host_ed25519_key

ssh セッションを終了し、新しく生成された ssh バイナリによって制御されるセッションにログインしてみます。

ssh -p 777 user@DS

ここで、ポート 22 の元の ssh サーバーを終了します。

sudo su

次にSSH設定を編集します

vim /etc/init/sshd.conf

respawn 行をコメントアウトして、次のようになります。

#respawn
#respawn limit 5 10

それから：

netstat -ap | grep ssh

右側のプロセスIDを見つけます

行は次のようになります。

tcp        0      0 0.0.0.0:ssh             0.0.0.0:*               LISTEN      9508/sshd

ssh-shellを停止する

synoservice --hard-stop ssh-shell

sshd プロセスを終了します。

kill -9 9508

プロセスがなくなり、ポート 22 で何もリッスンしていないかどうかを確認します。

netstat -tpa | grep 22

このガイドでさまざまなポートを試した場合は、sshd の他のインスタンスをシャットダウンする必要がある可能性があります。

すべてが失敗した場合は、DSM 経由で ssh を無効にすることができます。

ついに：

cp /fullhomepath/newsshd /bin/sshd && chown root:root /bin/sshd

先ほど行った respawn コメントを /etc/init/sshd.conf に逆順に記述します。

新しいsshdがローカルのsshd_configファイルが存在しないと報告するので、このシンボリックリンクを作成します。

ln -s /etc/ssh/sshd_config /usr/local/etc/sshd_config

sshd を再度有効にします:

synoservice --hard-enable ssh-shell

次に、コピーしたファイルがコンパイルされたファイルと一致することを確認します。

DSの場合:

sha256sum /bin/sshd /bin/scp

Linux インスタンスの場合:

sha256sum ~/crosscompile/openssh-8.1p1/sshd ~/crosscompile/openssh-8.1p1/scp

それぞれのバイナリのハッシュはシステム間で一致する必要があります。

新しいファイルと古いファイルのバージョンを確認することもできます。

 ash-4.3# /bin/sshd.DS.orginal --version ; /bin/scp.DS.orginal --version

 unknown option -- - OpenSSH_7.4p1, OpenSSL 1.0.2r-fips  26 Feb 2019 usage: sshd [-46DdeiqTt] [-C connection_spec] [-c
     host_cert_file]
                 [-E log_file] [-f config_file] [-g login_grace_time]
                 [-h host_key_file] [-o option] [-p port] [-u len] unknown 

option -- - usage: scp [-12346BCpqrv] [-c cipher] [-F ssh_config] [-i
         identity_file]
                    [-l limit] [-o ssh_option] [-P port] [-S program]
                    [[user@]host1:]file1 ... [[user@]host2:]file2

ash-4.3# /bin/sshd --version ; /bin/scp --version

unknown option -- -
OpenSSH_8.1p1, OpenSSL 1.1.1d  10 Sep 2019
usage: sshd [-46DdeiqTt] [-C connection_spec] [-c host_cert_file]
            [-E log_file] [-f config_file] [-g login_grace_time]
            [-h host_key_file] [-o option] [-p port] [-u len]
unknown option -- -
usage: scp [-346BCpqrTv] [-c cipher] [-F ssh_config] [-i identity_file]
            [-J destination] [-l limit] [-o ssh_option] [-P port]
            [-S program] source ... target

これで、Synology に再度通常通り接続してみることができます。

ssh DS

「警告: リモートホスト ID が変更されました!」のようなメッセージが表示されます。

これは予想通りです。/home/user/.ssh/known_hosts を編集して手動で修正してください。古いキーを削除して再接続し、新しいキーを受け入れるだけで十分なはずです。

最後に、再起動によって何かが変更されたかどうかを確認するには、必要に応じて DS を再起動します。

/etc/passwd および /etc/group 内のカスタム行が確実に保持されるようにするには、以下のスクリプトを使用して /usr/local/bin/pwdgroupfixer.sh に保存し、chmod +x で実行可能にすることを忘れないでください。

ルートの crontab にエントリを作成します。

*/5 *   *   *   *   root    /bin/sh /usr/local/bin/pwdgroupfixer.sh

Synology は crontab のフォーマットに細心の注意を払っていることに注意してください。スペースの代わりにタブを使用します。既存のエントリを使用して新しい行にコピーし、変更することは良いヒントです。

最後にcrontabサービスを再起動します。

sudo synoservice -restart crond

#!/bin/sh
#pwdgroupfixer.sh

#Entries to support sshd

PASSWORDFILE=/etc/passwd
USERLINE="sshd:x:74:74:Privilege-separated SSH:/var/empty/sshd:/sbin/nologin"

GROUPFILE=/etc/group
GROUPLINE="/etc/group:sshd:*:27:"


itemcheck(){
  FILE=$1
  ITEM=$2
DATE=`/bin/date +%Y-%m-%d`
TEMPFILE=/tmp/$DATE
/bin/echo '0' > $TEMPFILE

FOUND=0
/bin/sed '/^[ \t\r\n]*$/d' $FILE | while read LINE; do
    if [[ ${LINE:0:1} != "#" ]]; then
         if [ "$LINE" == "$ITEM" ];
         then
            let FOUND++
            /bin/echo $FOUND > $TEMPFILE
         fi
     fi
  done

FOUND=`/bin/cat $TEMPFILE`

if [ "$FOUND" -eq "0" ]; then
    /bin/cp $FILE $FILE.`/bin/date +%Y-%m-%d`
    /bin/echo $ITEM >> $FILE
fi

}

itemcheck $PASSWORDFILE "$USERLINE"
itemcheck $GROUPFILE $GROUPLINE

#end pwdgroupfixer.sh

Question 3

私は、追加のソフトウェアをインストールしたり、権限を付与すべきでないユーザーに権限を付与したりしない、次のアプローチを試しました。ただし、この解決策が実際に機能するかどうかはまだ確認していません。手順の最後に NAS をもう一度再起動する必要があるのではないかと思います。詳細がわかり次第、ここで更新します。2 回目の再起動まで試した方は、ぜひコメントを残してください。

Synology のゲームに参加して、「管理者」ユーザーグループを SSH 権限を付与するグループだけに縮小できることに気付きました。

2 番目のグループを作成し、デフォルトの「administrators」グループと同じ権限をすべて付与しました。このグループに「realadmin」という名前を付けます。実際に管理者権限を持つべきすべてのユーザーは、このグループに追加する必要があります (念のため、元の「administrators」にも残しておきます)。このグループを作成し、管理者権限を持つべきすべてのユーザーを追加したら、管理者アカウントとで NAS に ssh しますsudo vi /etc/sudoers。をに置き換え(正しく入力してください。確実にするために、DSM 管理パネルからコピーアンドペーストするとよいかもしれません)、と入力して保存して閉じます%administrators。この変更を有効にするには、NAS を再起動します (NAS を再起動するまで sudo アクセスは失われます)。最後に、rsync など、SSH で使用する可能性のあるものを除き、「administrators」グループからすべての権限を削除します。説明を更新して、「administrators」が基本的に SSH ユーザーグループになったことを反映します。SSH アクセスを許可するすべてのユーザーを追加します。これで、「administrators」であることによる管理者権限は付与されなくなります。これらの各ユーザーのシェルをに設定し直し、認証に使用する公開キーを含むファイルをホームディレクトリに作成してください。%realadminwq!/bin/sh/etc/passwd.ssh/authorized_keys

上記の手順を実行してから、「administrators」グループに追加した非 real-admin アカウントで NAS に SSH 接続しようとしました。それでも、を取得できましたpermission denied (publickey)。この時点で何が欠けているかはわかりません。ユーザーを「administrators」に追加したことを有効にするには、NAS を再起動する必要があるかもしれません。同じユーザーを「realadmin」にも簡単に追加してみましたが、少なくとも NAS を再起動しない限り、ユーザーは SSH を使用できませんでした。あまり頻繁に中断したくないプロセスが実行中であるため、また、今のところ私の特定の問題を解決する別の手っ取り早い回避策を見つけたため、NAS をまだ 2 度目に再起動していません。

私はもともと、この（理論的な）解決策を Synology コミュニティフォーラムで説明し、このページでいくつかの追加の議論を加えました。https://community.synology.com/enu/forum/1/post/125859?page=2(16 番目の返信、執筆時点で最新のもの)。

Answer

私は、追加のソフトウェアをインストールしたり、権限を付与すべきでないユーザーに権限を付与したりしない、次のアプローチを試しました。ただし、この解決策が実際に機能するかどうかはまだ確認していません。手順の最後に NAS をもう一度再起動する必要があるのではないかと思います。詳細がわかり次第、ここで更新します。2 回目の再起動まで試した方は、ぜひコメントを残してください。

Synology のゲームに参加して、「管理者」ユーザーグループを SSH 権限を付与するグループだけに縮小できることに気付きました。

2 番目のグループを作成し、デフォルトの「administrators」グループと同じ権限をすべて付与しました。このグループに「realadmin」という名前を付けます。実際に管理者権限を持つべきすべてのユーザーは、このグループに追加する必要があります (念のため、元の「administrators」にも残しておきます)。このグループを作成し、管理者権限を持つべきすべてのユーザーを追加したら、管理者アカウントとで NAS に ssh しますsudo vi /etc/sudoers。をに置き換え(正しく入力してください。確実にするために、DSM 管理パネルからコピーアンドペーストするとよいかもしれません)、と入力して保存して閉じます%administrators。この変更を有効にするには、NAS を再起動します (NAS を再起動するまで sudo アクセスは失われます)。最後に、rsync など、SSH で使用する可能性のあるものを除き、「administrators」グループからすべての権限を削除します。説明を更新して、「administrators」が基本的に SSH ユーザーグループになったことを反映します。SSH アクセスを許可するすべてのユーザーを追加します。これで、「administrators」であることによる管理者権限は付与されなくなります。これらの各ユーザーのシェルをに設定し直し、認証に使用する公開キーを含むファイルをホームディレクトリに作成してください。%realadminwq!/bin/sh/etc/passwd.ssh/authorized_keys

上記の手順を実行してから、「administrators」グループに追加した非 real-admin アカウントで NAS に SSH 接続しようとしました。それでも、を取得できましたpermission denied (publickey)。この時点で何が欠けているかはわかりません。ユーザーを「administrators」に追加したことを有効にするには、NAS を再起動する必要があるかもしれません。同じユーザーを「realadmin」にも簡単に追加してみましたが、少なくとも NAS を再起動しない限り、ユーザーは SSH を使用できませんでした。あまり頻繁に中断したくないプロセスが実行中であるため、また、今のところ私の特定の問題を解決する別の手っ取り早い回避策を見つけたため、NAS をまだ 2 度目に再起動していません。

私はもともと、この（理論的な）解決策を Synology コミュニティフォーラムで説明し、このページでいくつかの追加の議論を加えました。https://community.synology.com/enu/forum/1/post/125859?page=2(16 番目の返信、執筆時点で最新のもの)。

Question 4

私は決して NAS の専門家ではありませんが、ユーザーのアクセスを有効にすると、git_reposシェルがオン/etc/passwdに設定されます(したがって、カテゴリに該当します)。これをに変更すると、SSH アクセスが許可されます。/var/packages/Git/target/bin/git-shellDSM 6.2.4-25556 Update 5DSM 6.2.x/bin/sh

Answer

私は決して NAS の専門家ではありませんが、ユーザーのアクセスを有効にすると、git_reposシェルがオン/etc/passwdに設定されます(したがって、カテゴリに該当します)。これをに変更すると、SSH アクセスが許可されます。/var/packages/Git/target/bin/git-shellDSM 6.2.4-25556 Update 5DSM 6.2.x/bin/sh

Synology DSM 6.2.x: 管理者以外のユーザーとして SSH を実行する方法

答え1

答え2

答え3

答え4

関連情報