Synology DSM 6.2.x: как использовать SSH как пользователь без прав администратора

Я искал где-то в Интернете, чтобы опубликовать это, поскольку я только что решил эту проблему, и думал, что решение будет полезно для других!

(Пожалуйста, удалите черточки из URL, когда они очевидны.., у меня нет репутации, чтобы публиковать много ссылок)

Это решение проблемы невозможности входа в Synology NAS через ssh, если вы не являетесь членом группы администраторов. После прочтения нескольких сообщений об этом в Интернете эта проблема присутствует в DSM 6.2.x

Существует множество веских причин, по которым пользователю может быть предоставлен ssh-доступ. В то же время не каждому пользователю необходим доступ администратора, поэтому кажется, что Synology Inc. приняла плохое решение для применения этого правила. Я не нашел способа исправить это с помощью стандартного sshd, поэтому я скомпилировал свой собственный sshd.

Я не несу ответственности за то, что вы пролили свой кофе, споткнулись в кресле и упали на свою кошку или иным образом понесли ущерб от этого руководства. Но по состоянию на октябрь 2019 года все проверено на работу в моей лаборатории.

Давайте начнем.

Система это была проверена на:

 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)

Предпосылки:

• NAS-устройство Synology, к которому вы можете получить доступ через ssh с существующим пользователем, входящим в группу администраторов.
• В среде Linux это может быть виртуализировано. На Mac системного терминала должно хватить. Следуя моему дословному указанию, перейдите к установке Fedora 30. Если вы используете Ubuntu, по крайней мере, вам нужно использовать apt-get вместо dnf, могут быть и другие специфические для дистрибутива элементы.

Предупреждение, если вы привыкли использовать 'make install' при установке программного обеспечения linux. Не делайте этого, следуя этому руководству, если вы не знаете, что делаете и отклоняетесь от руководства. Если вы сделаете это, вы можете сломать вашу систему. Кроме того, для работы над этим руководством не нужно быть кем-то, кроме обычного пользователя, с точки зрения хоста компиляции. Иногда требуется только sudo.

Кроме того, если по какой-либо причине вам удастся скрыть свой демон ssh, вы всегда можете включить telnet через веб-интерфейс DSM и подключиться к synology cli через telnet, чтобы исправить то, что вы сделали неправильно. Кроме того, имеет смысл записывать все, что вы делаете, и создавать резервные копии всех файлов, которые вы заменяете, и всех файлов, которые вы изменяете, до этого. Обратите внимание, что если вы делаете это руководство, работаете с удаленным сервером Synology и не совсем уверены в том, что делаете, существует реальная опасность того, что вы заблокируете себя на сервере. По крайней мере, убедитесь, что у вас есть выход, например администратор сайта, который может восстановить доступ для вас.

Synology и DS (Disk Station) будут использоваться взаимозаменяемо в остальной части руководства.

Поскольку Synology Inc., по-видимому, изменила исходный двоичный файл sshd, добавление двоичного файла sshd, который предоставит ssh доступ к блоку Synology для пользователей за пределами группы администраторов, - это то, чему вас научит это руководство.

Интересно, что можно сделать нечто, называемое кросс-компиляцией, это означает, что вы можете компилировать программное обеспечение на одной платформе, которая может работать на другой платформе.

Доступен исходный код для openssh, как и его зависимости. Это означает, что мы можем скомпилировать его в системе linux и запустить его в синологии с процессором ARM.

Прежде всего, получите доступ к Linux-машине. Если у вас не установлен linux, загрузите программное обеспечение для виртуализации, например vmware или virtualbox, и установите или загрузите виртуальную машину linux. Он также может работать с использованием Cygwin в качестве подсистемы в Windows. Обратитесь к соответствующей документации для этого.

Пожалуйста, обратите внимание, что некоторые элементы этого руководства могут не соответствовать вашим уникальным обстоятельствам. Пожалуйста, измените ваш путь в этом руководстве соответствующим образом. Это руководство должно дать вам несколько советов, чтобы исправить проблему с ssh, даже если у вас нет точно такой же настройки, как у меня.

Прежде всего, выясните, какой процессор у вашего DS.

Найдите свою конкретную модель синологии здесь: https://www.synology.com/en-global/knowledgebase/DSM/tutorial/Compatibility_Peripherals/What_kind_of_CPU_does_my_NAS_have

Также проверьте ssh-сессию на терминале Synology, uname -a должна дать вам несколько советов.

В моем случае и ссылка Центра поддержки Synology, и выходные данные uname -a показывают, что у меня есть процессор Realtek RTD1293, это процессор ARM, для получения более интересной информации посетите https://en.wikichip.org/wiki/arm/aarch64

Итак, нам нужно получить исходные коды и кросс-компилировать их на ноутбуке с linux, чтобы мы могли использовать двоичный код для синхронизации и обойти ограничение входа в систему.

Прежде чем продолжить, убедитесь, что вы можете использовать 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 localuser@192.168.10.100. Если у вас есть файл идентификации не по умолчанию или порт по умолчанию, добавьте эти параметры. Как настроить ssh без пароля выходит за рамки этого руководства. Обратите внимание, что synology также требователен к разрешениям для всех файлов и каталогов, принадлежащих пользователю, перед тем как разрешить вход по ssh. Есть много сообщений в Интернете об этом. Однако вы можете продолжить, используя пароль для входа, но если вы находитесь в локальной сети и используете устройства конечного пользователя, которые являются частными, более удобно использовать ssh-ключи для входа в систему через ssh. Вы также можете использовать парольные фразы в своих закрытых ключах. Также убедитесь, что при входе в систему с вашим существующим пользователем вы можете сделать sudo whoami. Это должно запросить у вас пароль sudo, если вы не настроили sudo, чтобы пароль вашего пользователя не требовался, и после нажатия клавиши ввода вы увидите "root".

Теперь самое интересное!

В вашем linux (fedora?) Войдите в систему, запустите терминал, создайте каталог проекта и введите его.

mkdir ~/crosscompile ; cd ~/crosscompile

Используйте веб-браузер в вашем экземпляре Linux и перейдите по https://cdn.openbsd.org/pub/OpenBSD/OpenSSH/portable/, найдите последнюю версию внизу. Пара Октябрь 2019 это 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

Вторая строка получает подпись 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

Обратите внимание на идентификатор ключа, 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 <djm@mindrot.org>" [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. Все выглядит хорошо. Если вас беспокоит, что ключу не доверяет ключ, вам нужно либо отредактировать доверие к ключу самостоятельно, либо попросить кого-нибудь сделать это. Если у вас очень важная установка, вам следует обратиться к Дэмиену Миллеру и попросить его прочитать отпечаток пальца. Вы, вероятно, должны компенсировать его за это!

В любом случае, чтобы убедиться, что загрузка максимально безопасна, вы должны проверить с несколькими источниками, поэтому давайте попробуем.

Быстрый поиск показывает, что, по-видимому, блог Миллера. И этот пост дает еще несколько деталей:

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, чтобы попытаться найти ссылки в других местах в Интернете, если вам потребуется дополнительная проверка.

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 <matt@openssl.org>" 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 <matt@openssl.org>" [unknown]
gpg:                 aka "Matt Caswell <frodo@baggins.org>" [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

На данный момент мы должны предположить, что все скачанные нами sw проверены и все в порядке, теперь давайте создадим двоичный файл 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

Давайте посмотрим, сможем ли мы войти с обычным пользователем через ssh в DS, используя новый двоичный файл sshd, который мы создали. К настоящему времени у вас должен быть пароль без пароля для входа в 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 DS

Тогда давайте сделаем копию sshd_config:

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

Отредактируйте новый файл конфигурации:

vim /etc/ssh/sshd_config_new

Измените "UsePAM yes" на "#UsePAM yes"

Раскомментируйте HostKey /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. известна тем, что иногда заменяет правки и файлы при выполнении обновлений. Если это произойдет, вам нужно включить telnet через DSM и войти через 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 в агент аутентификации)
• ./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

Сделайте резервную копию этих двух файлов.

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

Выйдите в экземпляр Linux и скопируйте только что созданный файл scp:

scp scp DS:~

Ssh в DS, переместите файл scp и установите правильное владение:

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

Поскольку /bin/sshd активен, его нельзя перезаписать, поэтому нам нужно его убить. Но перед этим нам нужно запустить наш вновь созданный sshd, чтобы у нас был альтернативный путь к DS.

Запустите новый терминал на вашем экземпляре Linux и выполните ssh для DS обычным способом:

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

Теперь убейте оригинальный ssh-сервер на порту 22.

sudo su

затем отредактируйте конфигурацию ssh

vim /etc/init/sshd.conf

Закомментируйте линии респауна, чтобы они выглядели так:

#respawn
#respawn limit 5 10

Затем:

netstat -ap | grep ssh

Найдите идентификатор процесса справа

Линия должна выглядеть так:

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, если вы экспериментировали с различными портами в этом руководстве.

Если все не удается, вы можете отключить SSH через DSM.

В заключение:

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

Отмените ранее созданные комментарии к /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

Теперь вы увидите что-то вроде "ПРЕДУПРЕЖДЕНИЕ: ДИСТАНЦИОННАЯ ИДЕНТИФИКАЦИЯ ХОЗЯИНА ИЗМЕНИЛАСЬ!"

Это ожидается. Исправьте это вручную, отредактировав /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

Обратите внимание, что синология имеет особое значение для форматирования его 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

Я попробовал следующий подход, который не предполагает ни установки дополнительного программного обеспечения, ни предоставления повышенных привилегий пользователям, которые не должны их получать. Однако я еще не подтвердил, что это решение действительно работает; Я подозреваю, что мне, возможно, придется перезапустить NAS второй раз в конце процедуры. Я буду обновлять здесь, когда узнаю больше. Если кто-то попробует это до второго перезапуска, пожалуйста, оставьте комментарий!

Я понял, что могу сыграть в игру Synology и сократить группу пользователей «Администраторы» до группы, которая дает вам привилегии SSH.

Я создал вторую группу и предоставил ей все те же привилегии, что и группе «Администраторы» по умолчанию. Допустим, вы назовете эту группу «realadmin». Все пользователи, которые на самом деле должны иметь права администратора, должны быть добавлены в эту группу (на всякий случай оставьте их также в исходных «администраторах»). После создания этой группы и добавления всех пользователей, которые должны иметь права администратора, подключитесь к NAS с учетной записью администратора иsudo vi /etc/sudoers. Заменять%administratorsк%realadmin(убедитесь, что вы вводите это правильно, возможно, для уверенности скопируйте и вставьте из панели администратора DSM), сохраните и закройте, набравwq!. Перезапустите NAS, чтобы это изменение вступило в силу (вы потеряете доступ к sudo до тех пор, пока не перезапустите NAS). Наконец, удалите все разрешения из группы «Администраторы», за исключением тех, которые вы, скорее всего, будете использовать с SSH, например rsync. Обновите описание, чтобы отразить, что «администраторы» теперь по сути являются группой пользователей SSH. Добавьте всех пользователей, которым вы хотите предоставить доступ по SSH; теперь они не должны получать никаких административных прав, будучи «администраторами». Обязательно установите оболочку обратно в/bin/shдля каждого из этих пользователей в/etc/passwdи создать.ssh/authorized_keysфайл в своих домашних каталогах с открытыми ключами, с помощью которых они смогут пройти аутентификацию.

Я выполнил описанные выше шаги, а затем попробовал подключиться к NAS по SSH с учетной записью, не являющейся настоящим администратором, которую я добавил в группу «Администраторы». Тем не менее, я получилpermission denied (publickey). Я не уверен, чего не хватает на данный момент. Возможно, мне нужно еще раз перезагрузить NAS, чтобы добавление пользователя в список «администраторов» вступило в силу. Я также кратко попытался добавить того же пользователя в «realadmin», но он все равно не мог использовать SSH, по крайней мере, без перезапуска NAS. Я еще не перезагружал NAS во второй раз, потому что у меня запущены процессы, которые я не хочу прерывать слишком часто, и потому что я нашел другой, быстрый и грязный обходной путь, который на данный момент решает мою конкретную проблему.

Первоначально я описал это (теоретическое) решение на форуме сообщества Synology с дополнительным обсуждением на этой странице: https://community.synology.com/enu/forum/1/post/125859?page=2 (16-й ответ, самое последнее на момент написания).

На DiskStation с Docker мне было проще всего использовать OpenSSH-контейнер. Я пошел за linuxserver/openssh-server. Таким образом, я могу монтировать в контейнер только соответствующие данные, и мне не нужно возиться с конфигурациями Synology.

Начиная с версии 6.2.0 Synology DSM доступ по ssh разрешен только членам группы администраторов.

Чтобы обойти это ограничение, мы установим закрепленный ssh ​​внутри Synology NAS.

Шаги:

• Измените Synology SSH на порт, отличный от 22 (например, 2222):Control Panel > Terminal & SNMP

• Установите Докер изPackages Center

• Включите домашние папки пользователей:Control Panel > Users > Advanced

• Создать подделкуsshduser и отключите его (он понадобится докеру):Control Panel > Users

Затем мы должны подключиться к Synology NAS по SSH от имени администратора и создать несколько сценариев от имени пользователя root.

Создайте скрипт cronjob:

      mkdir -p /etc/docker-ssh
cat <<EOF > /etc/docker-ssh/cronjob
#!/bin/sh
set -e
# fix passwd entries to add /bin/bash as shell and only keep /homes/
awk -F ':' < /etc/passwd '
  /^root/ {print}
  /homes/ {print \$1 ":" \$2 ":" \$3 ":" \$4 ":" \$5 ":" \$6 ":/bin/bash"}
' > /etc/docker-ssh/passwd
chmod 644 /etc/docker-ssh/passwd
# fix homes root permissions
chmod 755 /var/services/homes
find /var/services/homes/ -mindepth 1 -maxdepth 1 -type d \
  | xargs --no-run-if-empty chmod 700
EOF

chmod +x /etc/docker-ssh/cronjob

Зарегистрируйте скрипт cronjob для запуска каждый час:

      echo "@hourly root [ -x /etc/docker-ssh/cronjob ] && /etc/docker-ssh/cronjob" > /etc/cron.d/docker-ssh

Создайте поддельный sshd_config, используемый докеризованным ssh.

      cat <<EOF > /etc/docker-ssh/sshd_config
Port 22
Protocol 2
HostKey /etc/ssh/ssh_host_rsa_key
SyslogFacility AUTH
LogLevel VERBOSE
LoginGraceTime 120
PermitRootLogin no
StrictModes yes
PubkeyAuthentication yes
AuthorizedKeysFile %h/.ssh/authorized_keys
IgnoreRhosts yes
HostbasedAuthentication no
PermitEmptyPasswords no
ChallengeResponseAuthentication no
PasswordAuthentication no
PrintMotd no
TCPKeepAlive yes
AcceptEnv LANG LC_*
Subsystem sftp /usr/lib/openssh/sftp-server
EOF

Наконец, создайте основной скрипт для запуска докеризованного sshd-контейнера:

      cat <<EOF > /etc/docker-ssh/run.sh
#!/bin/sh
set -eu

# Find openssh-server images here: https://hub.docker.com/r/linuxserver/openssh-server/tags
SSHD_DOCKER_IMAGE=ghcr.io/linuxserver/openssh-server:version-8.4_p1-r3
SSHD_OPTIONS=(-D -e) # run in foreground + log to stdout

# initialize the dummy etc/passwd file (it should be refreshed by cronjob after container boot)
for file in /etc/ssh/ssh_host_rsa_key /etc/ssh/sshd_config /etc/group; do
  ln -sf \${file} /etc/docker-ssh/\${file##*/}
done
# run the cronjob manually once to be sure that all our files exist.
/etc/docker-ssh/cronjob

# stop container if already running
docker rm -f ssh-server >/dev/null 2>&1 || :

# run the container again
exec docker run \
  --detach \
  --restart=unless-stopped \
  --name=ssh-server \
  --hostname=$(hostname) \
  --volume /etc/docker-ssh/ssh_host_rsa_key:/etc/ssh/ssh_host_rsa_key:ro \
  --volume /etc/docker-ssh/sshd_config:/etc/ssh/sshd_config:ro \
  --volume /etc/docker-ssh/passwd:/etc/passwd:ro \
  --volume /etc/docker-ssh/group:/etc/group:ro \
  --volume /var/services/homes:/var/services/homes \
  --publish 0.0.0.0:22:22 \
  --entrypoint=/usr/sbin/sshd \
  "\${SSHD_DOCKER_IMAGE}" "\${SSHD_OPTIONS[@]}"
EOF

chmod +x /etc/docker-ssh/run.sh

Наконец, запустите скрипт:

      /etc/docker-ssh/run.sh

После запуска sshd-контейнера пользователи смогут подключаться к своим домам по ssh, как и раньше.

Поскольку интерактивная аутентификация отключена, пользователям следует заранее создать файл .ssh/authorized_keys со следующими разрешениями:

      chmod u+rwx,g-rwx,o-rwx $HOME/.ssh folder
chmod u+r-wx,g-rwx,o-rwx $HOME/.ssh/authorized_keys

Чтобы удалить, просто:

      docker rm -f openssh-server
rm -rf /etc/docker-ssh /etc/cron.d/docker-ssh

Я никоим образом не являюсь экспертом по NAS, но предоставляю пользователю доступ кgit_reposустанавливает оболочку/etc/passwdк/var/packages/Git/target/bin/git-shellнаDSM 6.2.4-25556 Update 5(так что это вписывается вDSM 6.2.xкатегория). Изменение этого на/bin/shпредоставляет доступ по SSH.

Ты должен отредактировать /etc/passwd обычным способом, затем перейдите к редактированию /etc/ssh/sshd_config, изменив значение

ChallengeResponseAutentication

форма от нет до да

Затем перезапустите демон ssh: killall -1 sshd