Desde o DSM 6.2.2, temos problemas para conectar-se a um Synology NAS como usuário não administrador via ssh. Antes isso era possível simplesmente alterando o shell de login /etc/passwdde /sbin/nologinpara /bin/sh. Isso parece não funcionar mais.
Além disso, tentei editar /etc/ssh/sshd_confexplicitamente, AllowUsersmas sem sucesso. Parece que o cliente faz uma autenticação bem-sucedida, mas algum módulo PAM (?) desliga a conexão novamente.
Alguém ssh trabalha como não administrador na versão mais recente do DSM?
Esta é a saída do log:
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
Responder1
Em DiskStations que possuem Docker, achei mais fácil usar um contêiner OpenSSH. Eu fui para linuxserver/openssh-server. Dessa forma, posso montar apenas os dados relevantes no contêiner e não preciso mexer nas configurações do Synology.
Responder2
Esta é uma solução para o problema de não conseguir fazer logon no Synology NAS via ssh, a menos que você seja membro do grupo Administradores. Ao ler vários posts sobre isso online, esse problema está presente no DSM 6.2.x
Existem muitos motivos válidos para um usuário receber acesso ssh. Ao mesmo tempo, nem todo usuário precisa de acesso de administrador, então parece que a Synology Inc. tomou uma decisão errada ao forçar esta regra. Não encontrei uma maneira de consertar isso usando o sshd padrão, então compilei meu próprio sshd.
Não assumo nenhuma responsabilidade se você derramar seu café, tropeçar na cadeira e cair sobre seu gato ou sofrer danos causados por este guia. Mas a partir de outubro de 2019, tudo foi testado para funcionar em meu laboratório.
Vamos começar.
Sistema em que foi testado:
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)
Pré-requisitos:
- Um Synology NAS que você pode acessar via ssh com um usuário existente que esteja no grupo de administradores.
- Um ambiente Linux, isso pode ser virtualizado. No Mac, um terminal de sistema deve ser suficiente. Para seguir meu exemplo literalmente, instale o Fedora 30. Se você usa o Ubuntu, pelo menos você precisa usar o apt-get em vez do dnf, também pode haver outros elementos específicos da distribuição.
Aviso, se você costuma usar 'make install' ao instalar software Linux. Não faça isso ao seguir este guia, a menos que você saiba o que está fazendo e se desvie do guia. Se você fizer isso, poderá quebrar seu sistema. Além disso, não há necessidade de ser nada além de um usuário comum enquanto trabalha neste guia, da perspectiva do host de compilação. Apenas ocasionalmente o sudo é necessário.
Além disso, se por algum motivo você conseguir interromper seu daemon ssh, você sempre poderá ativar o telnet por meio da interface da web do DSM e conectar-se ao synology cli via telnet para corrigir o que fez de errado. Além disso, é aconselhável anotar tudo o que você está fazendo e fazer backup de todos os arquivos que você está substituindo e de todos os arquivos que você está alterando antes de fazer isso. Observe que se você estiver seguindo este guia, trabalhando com um servidor de sinologia remoto, e não tiver certeza do que está fazendo, há um perigo plausível de você ficar fora do servidor. Pelo menos, certifique-se de ter uma saída, como um administrador no local que possa recuperar o acesso para você.
Synology e DS (Disk Station) serão usados de forma intercambiável no restante do guia.
Como a Synology Inc. aparentemente alterou o binário sshd original, adicionar um binário sshd que dará acesso ssh à caixa de sinologia para usuários fora do grupo de administradores é o que este guia ensinará você a fazer.
Curiosamente, é possível fazer algo chamado compilação cruzada, o que significa que você pode compilar software em uma plataforma que pode ser executado em outra plataforma.
O código-fonte do openssh está disponível, assim como suas dependências. Isso significa que podemos compilá-lo em um sistema Linux e executá-lo em sinologia com uma CPU ARM.
Primeiro, obtenha acesso a uma máquina Linux. Se você não possui o Linux instalado, baixe um software de virtualização como VMware ou VirtualBox e instale ou carregue uma máquina virtual Linux. Também pode funcionar usando o cygwin como subsistema no Windows. Consulte a respectiva documentação para isso.
Observe que certos elementos deste guia podem não se adequar às suas circunstâncias específicas. Ajuste sua jornada através deste guia de acordo. Este guia deve fornecer algumas dicas para corrigir o problema do ssh, mesmo se você não tiver exatamente a mesma configuração que eu.
Primeiro, descubra qual processador seu DS possui.
Encontre seu modelo de sinologia específico aqui:https://www.synology.com/en-global/knowledgebase/DSM/tutorial/Compatibility_Peripherals/What_kind_of_CPU_does_my_NAS_have
Verifique também uma sessão ssh em seu terminal de sinologia, uname -a deve lhe dar algumas dicas.
No meu caso, tanto o link do Synology Support Center quanto a saída de uname -a mostram que tenho uma CPU Realtek RTD1293, é um processador ARM, para informações mais interessantes, confirahttps://en.wikichip.org/wiki/arm/aarch64
Portanto, precisamos obter os fontes e compilá-los no laptop Linux, para que possamos copiar o binário para a sinologia e contornar a restrição de login.
Antes de prosseguir, verifique se você pode fazer ssh em sua sinologia. Se seu ssh-fu for forte, você pode ter configurado uma entrada em seu ~/.ssh/config parecida com esta:
#My synology
Host DS
Port 22
Hostname 192.168.10.100
User localuser
IdentityFile /home/localuser/.ssh/id_ed25519
Substitua variáveis por tudo o que a sua situação local exigir.
No mínimo, você poderá fazer login em sua sinologia executando um comando como ssh[e-mail protegido]. Se você tiver um arquivo de identidade não padrão ou uma porta não padrão, adicione esses parâmetros. Como configurar o ssh sem senha está fora do escopo deste guia. Observe que a sinologia também é exigente quanto às permissões em todos os arquivos e diretórios pertencentes a um usuário, antes de permitir o login ssh. Existem muitas postagens online sobre isso. Você pode continuar usando o login com senha, mas se estiver em uma rede local e usando dispositivos privados do consumidor final, é mais conveniente usar chaves ssh para fazer login no ssh. Você também pode usar senhas em suas chaves privadas. Verifique também se, quando estiver logado com seu usuário existente, você pode fazer sudo whoami. Isso deve solicitar sua senha do sudo, a menos que você tenha configurado o sudo para não precisar de uma senha para o seu usuário, e você verá 'root' após pressionar a tecla Enter.
Agora a parte divertida!!
Na sua instância Linux (Fedora?), Faça login, inicie um terminal e crie um diretório de projeto e entre nele.
mkdir ~/crosscompile ; cd ~/crosscompile
Use um navegador da web em sua instância Linux e vá parahttps://cdn.openbsd.org/pub/OpenBSD/OpenSSH/portable/, encontre a versão mais recente na parte inferior. Pr. Outubro de 2019, este é openssh-8.1p1.
Volte para o terminal Linux e faça o download, estarei usando 8.1p1, mas use a versão mais recente, se você vir este guia quando uma nova versão for feita.
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
A segunda linha obtém a assinatura PGP do arquivo.
Agora, se ainda não estiver instalado, instale o pgpdump:
sudo dnf install pgpdump
Proceder com
pgpdump openssh-8.1p1.tar.gz.asc
Exemplo de saída:
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
Observe o ID da chave, 0xD3E5F56B6D920D30 (pode ser diferente para uma versão mais recente.) Anote também a impressão digital, voltaremos a isso.
Agora instale o gpg2 se não estiver instalado;
sudo dnf install gpg2.
Obtenha a chave pgp do liberador:
wget https://cdn.openbsd.org/pub/OpenBSD/OpenSSH/portable/DJM-GPG-KEY.asc
Importe-o:
gpg2 --import DJM-GPG-KEY.asc
Obtenha a chave de lançamento e importe-a:
wget https://cdn.openbsd.org/pub/OpenBSD/OpenSSH/RELEASE_KEY.asc
gpg2 --import RELEASE_KEY.asc
Agora verifique o download:
gpg2 --verify openssh-8.1p1.tar.gz.asc openssh-8.1p1.tar.gz
Resultado:
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
Observe que a impressão digital corresponde ao que o pgpdump nos informou na assinatura do pgp. Tudo parece bem. Se você está preocupado com o fato de a chave não ser confiável para uma assinatura, você precisará editar a confiança da chave você mesmo ou contratar alguém para fazer isso. Se você tiver uma instalação muito crítica, entrar em contato com Damien Miller e pedir que ele leia a impressão digital é uma opção. Você provavelmente deveria compensá-lo por isso!
De qualquer forma, para garantir que o download seja o mais seguro possível, você deve verificar em diversas fontes, então vamos tentar.
Uma pesquisa rápida revela o que aparentemente é o blog de Miller. E este post dá mais alguns detalhes:
http://blog.djm.net.au/2013/12/pgp-keys-rotated.html
Agora copie todo o blob de chave para um arquivo no disco e, em seguida, faça um nome de arquivo pgpdump nele.
Isso deve fornecer uma saída como esta:
pgpdump keyblob | grep 0D30 | grep fin
Key fingerprint = 59C2 118E D206 D927 E667 EBE3 D3E5 F56B 6D92 0D30
Se você estiver curioso, copie toda a saída do comando para um editor de texto e pesquise '0xD3E5F56B6D920D30' conforme mencionado anteriormente no guia. Você verá então que a chave de liberação é uma subchave da chave pessoal de Miller.
Ok, neste ponto, presumimos que o download do openssh está correto.
Descompacte o openssh:
tar xvzf openssh-8.1p1.tar.gz
Você deve determinar qual cadeia de ferramentas você precisa:https://originhelp.synology.com/developer-guide/compile_applications/download_dsm_tool_chain.html
No meu caso, baixei o que precisava com este comando:
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, não há como verificar o download. Enviei-o para o VirusTotal e nenhum mecanismo foi encontrado.
Extraia a cadeia de ferramentas:
sudo tar Jxvf rtd1296-gcc494_glibc220_armv8-GPL.txz -C /usr/local
Além disso, precisamos do zlib e do openssl.
wget https://zlib.net/zlib-1.2.11.tar.gz
wget https://zlib.net/zlib-1.2.11.tar.gz.asc
(Também aqui, verifique a versão mais recente)
pgpdump zlib-1.2.11.tar.gz.asc | grep ID
fornece ID da chave - 0x783FCD8E58BCAFBA
Busque e importe:
wget http://pgp.key-server.io/download/0x783FCD8E58BCAFBA
gpg2 --import 0x783FCD8E58BCAFBA
Verifique o download:
gpg2 --verify zlib-1.2.11.tar.gz.asc zlib-1.2.11.tar.gz
Isso deve dar uma boa assinatura de Mark Adler[e-mail protegido]
Neste ponto, você pode usar a impressão digital ou chave DSA, para tentar encontrar referências em outros lugares na web, caso precise de verificação adicional.
Extract zlib: tar xvzf zlib-1.2.11.tar.gz
Precisamos também do 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
Agora verificamos a integridade do arquivo. Vamos verificar a assinatura também.
pgpdump openssl-1.1.1d.tar.gz.asc | grep -E "Fin|ID"
Resultados:
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
Vamos pegar a chave e importá-la para o chaveiro:
wget http://pgp.key-server.io/download/0xD9C4D26D0E604491
gpg2 --import 0xD9C4D26D0E604491
Resultado:
gpg: key D9C4D26D0E604491: public key "Matt Caswell <[email protected]>" imported
Agora verificamos o download:
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
Correspondência de impressão digital e uma referência também podem ser encontradas aqui para a mesma impressão digital:https://wiki.freebsd.org/OpenSSL/Base/Update111
Devemos assumir neste ponto que todo sw que baixamos foi verificado e ok, agora vamos construir o binário sshd do ARM!
cd zlib-1.2.11
Vamos configurar o 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
Então faça:
make
Vamos verificar:
ls -l libz*
agora deve mostrar algo assim:
-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
Ótimo usuário Synology! Vamos compilar o openssl!
Vamos extraí-lo e mudar para o diretório de trabalho:
cd .. && tar xvzf openssl-1.1.1d.tar.gz && cd openssl-1.1.1d
Então nós configuramos:
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
Agora vamos fazer isso:
make
Isso demora um pouco, então seja paciente.
Vamos verificar:
ls lib*so*
Deveria dar
libcrypto.so libcrypto.so.1.1 libssl.so libssl.so.1.1
Parabéns, você está cada vez mais perto de fazer isso acontecer de verdade!
Vamos compilar o openssh!
Primeiro devemos configurá-lo:
./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
Agora, faça:
make
Vários binários executáveis agora são criados em ~/crosscompile/openssh-8.1p1
Vamos ver se conseguimos fazer login com um usuário comum via ssh para DS, usando o novo binário sshd que criamos. Agora você deve ter um login sem senha no DS com um usuário existente pertencente ao grupo de administradores.
Vamos copiar o novo sshd e libcrypto para o DS:
scp ~/crosscompile/openssh-8.1p1/sshd DS:~/newsshd
scp ~/crosscompile/openssl-1.1.1d/libcrypto.so.1.1 DS:~
Então vamos fazer ssh para DS de maneira normal:
ssh DS
Então vamos fazer uma cópia do sshd_config:
sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config_new
Edite o novo arquivo de configuração:
vim /etc/ssh/sshd_config_new
Altere 'UsePAM sim' para '#UsePAM sim'
Remova o comentário HostKey /etc/ssh/ssh_host_ed25519_key
Salvar e sair.
Altere a propriedade do novo sshd:
sudo chown root:root newsshd
Agora precisamos fazer uma pequena edição em alguns arquivos. Primeiro faça backup dos arquivos que iremos editar:
sudo cp /etc/passwd /etc/passwd.org && sudo cp /etc/group /etc/group.org
Insira esta linha na parte inferior de /etc/passwd :
sshd:x:74:74:Privilege-separated SSH:/var/empty/sshd:/sbin/nologin
Da mesma forma, insira esta linha na parte inferior de /etc/group :
/etc/group:sshd:*:27:
Se você não fizer as alterações acima, receberá 'Separação de privilégios de usuário sshd não existe' ao executar o binário sshd que acabou de transferir.
Agora, vamos fazer um teste de conexão!
No 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
Isto iniciará o novo binário sshd no modo de depuração.
Agora você pode se conectar a isso normalmente a partir de sua instância do Linux com
ssh -p 444 user@DS
FINALMENTE - A GRANDE SUBSTITUIÇÃO.
Certifique-se de anotar tudo o que você faz e mantenha uma anotação em algum lugar, junto com os arquivos que você possui. A Synology Inc. é conhecida por às vezes substituir edições e arquivos ao fazer atualizações. Se isso acontecer, você precisará ativar o telnet via DSM e fazer login via telnet na rede local para restaurar as configurações. Possivelmente, você poderia configurar um cronjob para monitorar o sistema e reverter automaticamente quaisquer alterações que venham junto com uma atualização. Dependendo da sua configuração, talvez você não precise atualizar o DSM com muita frequência, se já estiver em uma rede muito segura e segmentada.
Os binários relevantes que compilamos para a arquitetura ARM residente em ~/crosscompile/openssh-8.1p1 :
- ./ssh-agent (agente de autenticação)
- ./sftp-server (subsistema do servidor SFTP)
- ./ssh (cliente OpenSSH SSH (programa de login remoto))
- ./ssh-keyscan (reunir chaves públicas ssh)
- ./ssh-keygen (geração, gerenciamento e conversão de chave de autenticação)
- ./sftp (programa de transferência segura de arquivos)
- ./ssh-keysign (desativado por padrão)
- ./ssh-add (adiciona identidades RSA ou DSA ao agente de autenticação)
- ./scp (cópia segura (programa de cópia remota de arquivos))
- ./ssh-pkcs11-helper (ssh-agent (programa auxiliar para suporte PKCS#11)
- ./sshd (daemon SSH OpenSSH)
Você deve decidir qual deles você precisa. Se você usar apenas sshd e scp, talvez seja suficiente substituir esses binários.
Primeiro, edite o arquivo /etc/ssh/sshd_config original, comente 'UsePAM yes' para '#UsePAM yes' e remova o comentário de 'HostKey /etc/ssh/ssh_host_ed25519_key'.
Você realmente deve usar apenas as chaves ed25519; se usar outros tipos de chaves, remova o comentário de acordo.
Vamos garantir que o suporte ao openssl esteja disponível.
No meu DS, isso não substitui nada, sua milhagem pode variar. Verifique se o alvo já existe. Eu fiz dessa maneira, pois é um método simples para fazer isso funcionar. Possivelmente, o arquivo de objeto compartilhado poderia ser colocado em um caminho personalizado e adicionado ao caminho de pesquisa para arquivos de objeto compartilhados.
sudo mv ~/libcrypto.so.1.1 /usr/lib/
Encontre o local dos arquivos que deseja substituir:
which sshd ; which scp
Resultado:
/bin/sshd
/bin/scp
Faça backup desses dois arquivos.
sudo cp /bin/sshd /bin/sshd.DS.orginal
sudo cp /bin/scp /bin/scp.DS.orginal
Saia para a instância do Linux e copie o arquivo scp recém-criado:
scp scp DS:~
Ssh para DS, mova o arquivo scp e defina a propriedade correta:
sudo mv ~/scp /bin
sudo chown root:root /bin/scp
Como /bin/sshd está ativo, ele não pode ser sobrescrito, então precisamos eliminá-lo. Mas antes disso precisamos lançar nosso sshd recém-criado para termos um caminho alternativo para o DS.
Inicie um novo terminal em sua instância Linux e faça ssh para DS da maneira normal:
ssh DS
Em seguida, gere uma instância do seu novo servidor sshd:
sudo /absolutepathtohomedir/newsshd -p 777 -f /etc/ssh/sshd_config_new -h /etc/ssh/ssh_host_ed25519_key
Saia da sessão ssh e tente fazer login em uma sessão controlada pelo binário ssh recém-gerado:
ssh -p 777 user@DS
Agora, mate o servidor ssh original na porta 22.
sudo su
então edite a configuração do ssh
vim /etc/init/sshd.conf
Comente as linhas de respawn, para que fiquem como abaixo:
#respawn
#respawn limit 5 10
Então:
netstat -ap | grep ssh
Encontre o ID do processo à direita
A linha deve ficar assim:
tcp 0 0 0.0.0.0:ssh 0.0.0.0:* LISTEN 9508/sshd
Pare o ssh-shell
synoservice --hard-stop ssh-shell
Mate o processo sshd.
kill -9 9508
Verifique se o processo desapareceu e nada está escutando na porta 22:
netstat -tpa | grep 22
Possivelmente você precisará desligar outras instâncias do sshd, se tiver experimentado várias portas durante este guia.
Se tudo falhar, você poderá desabilitar o ssh via DSM.
Finalmente:
cp /fullhomepath/newsshd /bin/sshd && chown root:root /bin/sshd
Reverta os comentários de respawn feitos anteriormente para /etc/init/sshd.conf
Crie este link simbólico enquanto o novo sshd reclama que o arquivo sshd_config local não existe
ln -s /etc/ssh/sshd_config /usr/local/etc/sshd_config
Reative o sshd:
synoservice --hard-enable ssh-shell
Agora, verifique se os arquivos copiados correspondem aos compilados:
No DS:
sha256sum /bin/sshd /bin/scp
Na instância do Linux:
sha256sum ~/crosscompile/openssh-8.1p1/sshd ~/crosscompile/openssh-8.1p1/scp
Os hashes dos respectivos binários devem corresponder entre os sistemas.
Também podemos verificar a versão dos arquivos novos e antigos:
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
Agora você pode tentar conectar-se normalmente ao Synology novamente:
ssh DS
Agora você será saudado com algo como "AVISO: A IDENTIFICAÇÃO DO HOST REMOTO MUDOU!"
Isto é esperado. Rectifique-o manualmente editando /home/user/.ssh/known_hosts, deve ser suficiente remover as chaves antigas e reconectar e, em seguida, aceitar a nova chave.
Finalmente, para verificar se algo foi alterado pela reinicialização, opcionalmente, reinicie o DS.
Para garantir que as linhas personalizadas em /etc/passwd e /etc/group permaneçam, use o script abaixo, salve-o em /usr/local/bin/pwdgroupfixer.sh, lembre-se de torná-lo executável por chmod +x.
Faça uma entrada no root crontab:
*/5 * * * * root /bin/sh /usr/local/bin/pwdgroupfixer.sh
Observe que a sinologia é específica quanto à formatação de seu crontab. Use tabulações em vez de espaços, é uma boa dica usar uma entrada existente e copiá-la para uma nova linha e modificá-la.
Finalmente reinicie o serviço 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
Responder3
Eu tentei a seguinte abordagem, que não envolve a instalação de software adicional nem a concessão de privilégios elevados a usuários que não deveriam obtê-los. No entanto, ainda não confirmei se esta solução realmente funciona; Suspeito que talvez seja necessário reiniciar o NAS uma segunda vez no final do procedimento. Vou atualizar aqui à medida que aprendo mais. Se alguém tentar até a segunda reinicialização, deixe um comentário!
Percebi que poderia jogar o jogo da Synology e reduzir o grupo de usuários "administradores" a apenas um grupo que lhe dá privilégios SSH.
Criei um segundo grupo e dei a ele os mesmos privilégios do grupo padrão de "administradores". Digamos que você nomeie este grupo como "realadmin". Todos os usuários que deveriam ter direitos de administrador devem ser adicionados a este grupo (só por segurança, mantenha-os também nos "administradores" originais). Depois de criar este grupo e adicionar todos os usuários que devem ter direitos de administrador, faça ssh no NAS com uma conta de administrador e sudo vi /etc/sudoers. Substitua %administratorspor %realadmin(certifique-se de digitar corretamente, talvez copie e cole do painel de administração do DSM para ter certeza) e salve e feche digitando wq!. Reinicie o NAS para que esta alteração tenha efeito (você perderá o acesso sudo até reiniciar o NAS). Por fim, remova todas as permissões do grupo “administradores”, exceto aquelas que você provavelmente usará com SSH, como rsync. Atualize a descrição para refletir que "administradores" agora é basicamente o grupo de usuários SSH. Adicione todos os usuários aos quais deseja conceder acesso SSH; eles agora não devem ganhar direitos administrativos por serem "administradores". Certifique-se de definir o shell de volta /bin/shpara cada um desses usuários /etc/passwde criar um .ssh/authorized_keysarquivo em seus diretórios pessoais com as chaves públicas com as quais eles devem ser capazes de autenticar.
Segui as etapas acima e tentei fazer o SSH no NAS com uma conta de administrador não real que adicionei ao grupo "administradores". Ainda assim, eu consegui permission denied (publickey). Não tenho certeza do que está faltando neste momento. Talvez eu precise reiniciar o NAS novamente para que a adição do usuário aos "administradores" tenha efeito. Tentei brevemente adicionar o mesmo usuário ao "realadmin" também, mas o usuário ainda não conseguiu usar o SSH, pelo menos não sem reiniciar o NAS. Ainda não reiniciei o NAS pela segunda vez, porque tenho processos em execução que não quero interromper com muita frequência e porque descobri uma solução diferente, rápida e suja, que resolve meu problema específico por enquanto.
Descrevi originalmente esta solução (teórica) no fórum da comunidade Synology, com algumas discussões adicionais, nesta página:https://community.synology.com/enu/forum/1/post/125859?page=2(16ª resposta, mais recente no momento da redação).
Responder4
Não sou de forma alguma um especialista em NAS, mas permito o acesso do usuário aos conjuntos git_reposde shell ( para que se encaixe na categoria). Mudar isso para concede acesso SSH./etc/passwd/var/packages/Git/target/bin/git-shellDSM 6.2.4-25556 Update 5DSM 6.2.x/bin/sh