Начиная с DSM 6.2.2 у нас возникли проблемы с подключением к Synology NAS как неадминистративного пользователя через ssh. Раньше это было возможно путем простого изменения оболочки входа /etc/passwdс /sbin/nologinна /bin/sh. Похоже, это больше не работает.
Я дополнительно пробовал редактировать /etc/ssh/sshd_confявно, AllowUsersно безрезультатно. Кажется, клиент успешно проходит аутентификацию, но затем какой-то PAM-модуль(?) снова закрывает соединение.
Кто-нибудь работал по ssh без прав администратора в последней версии DSM?
Вот вывод журнала:
2019-05-23T21:55:36+02:00 hostname sshd[13551]: pam_unix(sshd:session): session opened for user test by (uid=0)
2019-05-23T21:55:36+02:00 hostname sshd[13551]: pam_unix(sshd:session): session closed for user test
решение1
На DiskStations с Docker я обнаружил, что проще всего использовать OpenSSH-контейнер. Я выбрал linuxserver/openssh-server. Таким образом я могу монтировать только нужные данные в контейнер и мне не придется возиться с конфигурациями Synology.
решение2
Это решение проблемы невозможности входа в 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 и запустить на Synology с процессором ARM.
Для начала получите доступ к машине Linux. Если у вас не установлен Linux, загрузите программное обеспечение для виртуализации, например vmware или virtualbox, и установите или загрузите виртуальную машину Linux. Это также может работать с использованием cygwin в качестве подсистемы в Windows. Обратитесь к соответствующей документации для этого.
Обратите внимание, что некоторые элементы этого руководства могут не соответствовать вашим уникальным обстоятельствам, пожалуйста, скорректируйте свое путешествие по этому руководству соответствующим образом. Это руководство должно дать вам некоторые указания по исправлению проблемы с ssh, даже если у вас не та же самая настройка, что и у меня.
Для начала выясните, какой процессор установлен в вашей DS.
Найдите конкретную модель Synology здесь:https://www.synology.com/en-global/knowledgebase/DSM/tutorial/Compatibility_Peripherals/Какой_тип_ЦП_есть_в_моем_NAS-устройстве
Также проверьте сеанс ssh на вашем терминале synology, uname -a должна дать вам некоторые подсказки.
В моем случае и ссылка на Центр поддержки Synology, и вывод uname -a показывают, что у меня процессор Realtek RTD1293, это процессор ARM. Для получения более интересной информации посетитеhttps://en.wikichip.org/wiki/arm/aarch64
Итак, нам нужно получить исходники и выполнить кросс-компиляцию на ноутбуке с Linux, чтобы мы могли скопировать двоичный файл в Synology и обойти ограничение на вход в систему.
Прежде чем продолжить, убедитесь, что вы можете подключиться по протоколу SSH к вашему Synology. Если ваш SSH-FU надежный, возможно, вы создали запись в файле ~/.ssh/config, выглядящую примерно так:
#My synology
Host DS
Port 22
Hostname 192.168.10.100
User localuser
IdentityFile /home/localuser/.ssh/id_ed25519
Замените переменные на те, которые диктует ваша местная ситуация.
По крайней мере, вы сможете войти в систему Synology, выполнив команду вроде ssh[email protected]. Если у вас есть файл идентификации не по умолчанию или порт не по умолчанию, добавьте эти параметры. Как настроить 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/, найдите последнюю версию внизу. Pr. Oct 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-key от релизера:
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. Все выглядит хорошо. Если вы беспокоитесь о том, что ключ не является доверенным по подписи, вам нужно будет либо отредактировать доверие ключа самостоятельно, либо попросить кого-то сделать это. Если у вас очень критическая установка, свяжитесь с Дэмиеном Миллером и попросите его прочитать отпечаток. Вам, вероятно, следует вознаградить его за это!
В любом случае, чтобы убедиться в максимальной безопасности загрузки, вам следует проверить ее в нескольких источниках, поэтому давайте попробуем.
Быстрый поиск показывает, что, по-видимому, это блог Миллера. А этот пост дает некоторые дополнительные подробности:
http://blog.djm.net.au/2013/12/pgp-keys-rotated.html
Теперь скопируйте весь этот ключевой блок в файл на диске, а затем выполните для него команду pgpdump filename.
Это должно дать вам примерно такой вывод:
pgpdump keyblob | grep 0D30 | grep fin
Key fingerprint = 59C2 118E D206 D927 E667 EBE3 D3E5 F56B 6D92 0D30
Если вам интересно, скопируйте весь вывод команды в текстовый редактор и найдите '0xD3E5F56B6D920D30', как упоминалось ранее в руководстве. Затем вы увидите, что release-key является подключом личного ключа Миллера.
Хорошо, на этом этапе мы предполагаем, что загрузка 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
дает идентификатор ключа - 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
Это должно дать хорошую подпись от Марка Адлера.[email protected]
На этом этапе вы можете использовать отпечаток пальца или ключ 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 <[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
Давайте посмотрим, сможем ли мы войти в DS через ssh под обычным пользователем, используя новый бинарный файл 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 обычным способом:
ssh DS
Затем сделаем копию sshd_config:
sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config_new
Отредактируйте новый файл конфигурации:
vim /etc/ssh/sshd_config_new
Измените «UsePAM да» на «#UsePAM да»
Раскомментируйте 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 не существует».
Теперь давайте проведем проверку соединения!
На ДС:
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:~
Подключитесь к DS по SSH, переместите файл 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
Отменить комментарии 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
Теперь проверьте, что скопированные файлы соответствуют скомпилированным:
На ДС:
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.
Сделайте запись в root 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
решение3
Я попробовал следующий подход, который не подразумевает установку дополнительного программного обеспечения и предоставление повышенных привилегий пользователям, которые не должны их получать. Однако я еще не подтвердил, что это решение действительно работает; я подозреваю, что мне может потребоваться перезапустить NAS во второй раз в конце процедуры. Я обновлю здесь, как только узнаю больше. Если кто-то попробует все это вплоть до второго перезапуска, пожалуйста, оставьте комментарий!
Я понял, что могу сыграть в игру Synology и сократить группу пользователей «администраторы» до группы, которая предоставляет вам привилегии SSH.
Я создал вторую группу и дал ей те же привилегии, что и группе по умолчанию «администраторы». Допустим, вы назвали эту группу «realadmin». Все пользователи, которые на самом деле должны иметь права администратора, должны быть добавлены в эту группу (на всякий случай оставьте их в исходной группе «администраторы»). После создания этой группы и добавления всех пользователей, которые должны иметь права администратора, подключитесь по ssh к 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-й ответ, самый последний на момент написания статьи).
решение4
Я ни в коем случае не эксперт по NAS, но включение доступа пользователя к git_reposустанавливает shell в /etc/passwdположение /var/packages/Git/target/bin/git-shellon DSM 6.2.4-25556 Update 5(так что это попадает в DSM 6.2.xкатегорию). Изменение этого значения на /bin/shпредоставляет доступ по SSH.