Synology DSM 6.2.x: 관리자가 아닌 사용자로 SSH를 수행하는 방법

Synology DSM 6.2.x: 관리자가 아닌 사용자로 SSH를 수행하는 방법

DSM 6.2.2부터 SSH를 통해 관리자가 아닌 사용자로 Synology NAS에 연결하는 데 문제가 있습니다. 이전에는 로그인 셸을 에서 로 간단히 변경하면 가능 /etc/passwd했습니다 . 이것은 더 이상 작동하지 않는 것 같습니다./sbin/nologin/bin/sh

/etc/ssh/sshd_conf또한 명시적으로 편집을 시도했지만 AllowUsers소용이 없었습니다. 클라이언트가 인증에 성공한 것 같지만 일부 PAM 모듈(?)이 연결을 다시 종료합니다.

최신 버전의 DSM에서 관리자가 아닌 사용자로 SSH 작업을 수행하는 사람이 있습니까?

로그 출력은 다음과 같습니다.

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

Docker가 포함된 DiskStation에서는 OpenSSH 컨테이너를 사용하는 것이 가장 쉽다는 것을 알았습니다. 나는 갔다 linuxserver/openssh-server. 그렇게 하면 관련 데이터만 컨테이너에 마운트할 수 있고 Synology의 구성을 망칠 필요가 없습니다.

답변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 웹 UI를 통해 텔넷을 활성화하고 텔넷을 통해 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/What_kind_of_CPU_does_my_NAS_have

또한 Synology 터미널에서 ssh-session을 체크인하면 uname -a가 몇 가지 힌트를 제공합니다.

제 경우에는 Synology 지원 센터 링크와 uname -a의 출력 모두 제가 Realtek RTD1293 CPU, 즉 ARM 프로세서를 사용하고 있음을 보여줍니다. 더 흥미로운 정보를 보려면 다음을 확인하세요.https://en.wikichip.org/wiki/arm/aarch64

따라서 우리는 소스를 가져와서 Linux 노트북에서 크로스컴파일해야 합니다. 그러면 바이너리를 Synology로 scp하고 로그인 제한을 피할 수 있습니다.

계속하기 전에 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

지역 상황에 따라 변수를 대체하십시오.

최소한 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/, 하단에서 최신 버전을 찾으세요. Pr. 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

두 번째 줄은 파일의 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에게 연락하여 지문을 읽어 보도록 요청하는 것이 좋습니다. 당신은 아마도 그에게 보상을 해야 할 것입니다!

어쨌든, 다운로드가 최대한 안전한지 확인하려면 여러 소스를 통해 확인해야 하므로 시도해 보겠습니다.

빠른 검색을 통해 Miller의 블로그가 무엇인지 알 수 있습니다. 이 게시물에서는 더 자세한 내용을 제공합니다.

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'을 검색하세요. 그러면 릴리스 키가 Miller의 개인 키의 하위 키임을 알 수 있습니다.

좋아, 이 시점에서는 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

Afaik, 다운로드를 확인할 방법이 없습니다. 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

이것은 Mark Adler의 좋은 서명을 제공해야 합니다.[이메일 보호됨]

이 시점에서 추가 확인이 필요한 경우 지문이나 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

이 시점에서 우리가 다운로드한 모든 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에 여러 실행 가능한 바이너리가 생성됩니다.

우리가 만든 새 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'로 변경하세요.

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.는 업데이트를 수행할 때 편집 내용과 파일을 바꾸는 경우가 있는 것으로 알려져 있습니다. 이 경우 DSM을 통해 텔넷을 활성화하고 로컬 네트워크에서 텔넷을 통해 로그인하여 설정을 복원해야 합니다. 아마도 cronjob을 설정하여 시스템을 모니터링하고 업데이트와 함께 제공되는 모든 변경 사항을 자동으로 되돌릴 수 있습니다. 설정에 따라 이미 매우 안전하고 분할된 네트워크에 있는 경우 DSM을 자주 업데이트할 필요가 없을 수도 있습니다.

~/crosscompile/openssh-8.1p1 에 있는 ARM 아키텍처용으로 컴파일한 관련 바이너리:

  • ./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

이 두 파일을 백업하세요.

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 인스턴스에서 새 터미널을 시작하고 일반적인 방법으로 DS에 SSH를 통해 연결합니다.

ssh DS

그런 다음 새 SSHD 서버의 인스턴스를 생성합니다.

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

ssh-session을 종료하고 새로 생성된 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 쉘 중지

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

이전에 /etc/init/sshd.conf에 수행한 respawn 주석을 되돌립니다.

새 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

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"으로 지정한다고 가정해 보겠습니다. 실제로 관리자 권한이 있어야 하는 모든 사용자는 이 그룹에 추가되어야 합니다(안전을 위해 원래 "관리자"에도 그대로 유지하세요). 이 그룹을 생성하고 관리자 권한이 있어야 하는 모든 사용자를 추가한 후 관리자 계정과 sudo vi /etc/sudoers. 다음 %administrators으로 대체하고 %realadmin(이 항목을 올바르게 입력했는지 확인하십시오. 확실히 하려면 DSM 관리 패널에서 복사하여 붙여넣으십시오) 를 입력하여 저장하고 닫습니다 wq!. 이 변경 사항을 적용하려면 NAS를 다시 시작하십시오(NAS를 다시 시작할 때까지 sudo 액세스 권한을 잃게 됩니다). 마지막으로 rsync와 같이 SSH와 함께 사용할 가능성이 있는 권한을 제외하고 "관리자" 그룹에서 모든 권한을 제거합니다. 이제 "관리자"가 기본적으로 SSH 사용자 그룹임을 반영하도록 설명을 업데이트합니다. SSH 액세스 권한을 부여하려는 모든 사용자를 추가하십시오. 이제 "관리자"가 되어도 관리 권한을 얻을 수 없습니다. /bin/sh이러한 각 사용자에 대해 셸을 다시 설정하고 인증할 수 있는 공개 키를 사용하여 홈 디렉터리에 파일을 /etc/passwd생성해야 합니다 ..ssh/authorized_keys

위의 단계를 수행한 다음 "관리자" 그룹에 추가한 실제 관리자가 아닌 계정을 사용하여 NAS에 SSH 연결을 시도했습니다. 그래도 나는 permission denied (publickey). 이 시점에서 무엇이 빠졌는지 잘 모르겠습니다. "관리자"에 사용자를 추가하려면 NAS를 다시 시작해야 할 수도 있습니다. "realadmin"에도 동일한 사용자를 간단히 추가하려고 시도했지만 적어도 NAS를 다시 시작하지 않으면 사용자는 여전히 SSH를 사용할 수 없었습니다. 너무 자주 중단하고 싶지 않은 프로세스가 실행 중이고 현재 특정 문제를 해결하는 다른 빠르고 더러운 해결 방법을 찾았기 때문에 아직 NAS를 두 번째로 다시 시작하지 않았습니다.

저는 원래 이 페이지에서 몇 가지 추가 논의와 함께 Synology 커뮤니티 포럼에서 이 (이론적) 솔루션을 설명했습니다.https://community.synology.com/enu/forum/1/post/125859?page=2(16번째 답변, 글을 쓰는 시점에서 가장 최근 답변)

답변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

관련 정보