Het is mogelijk om met het Admin account een SSH verbinding te maken met een Synology NAS.
Dit is echter erg onveilig en daarom is dit standaard op geen enkele linux/Unix omgeving mogelijk.
Om dit een stuk veiliger te maken kun je er voor kiezen om dit alleen mogelijk te maken als je gebruik maakt van een persoonlijke digitale sleutel.
Hieronder kun je lezen hoe je dit in een paar eenvoudige stappen kunt realiseren.


Maak een verbinding met je DSM via een SSH client (bijvoorbeeld Putty) en log in met gebruikersnaam root en gebruik het wachtwoord van je admin account.
Ga naar directory /root/ en maak daar een folder aan genaamd .ssh en ga vervolgens naar deze directory.
cd ~ [ENTER]
mkdir .ssh [ENTER]
cd .ssh [ENTER]

Maak een SSH sleutel aan met onderstaand commando of gebruik het daaronder staande script.
ssh-keygen -t rsa -b 2048 -f ~/gebruikersnaam2_key
(voor een DSA key kun je het volgende commando gebruiken maar wordt hieronder verder niet gebruikt of beschreven: ssh-keygen -t dsa -b 1024 -f ~/gebruikersnaam_key)

Ik heb voor de lol een scriptje geschreven voor als je een key aan wil maken.

zet onderstaande code in een bestand met een door_jezelf_te_verzinnen_naam en eindig dit bestand met de extentie .sh.
vi door_jezelf_te_verzinnen_naam.sh

Zorg dat je kunt schrijven in dit vi scherm.
ESC i [ENTER]

Copy paste onderstaande code.
#!/opt/bin/bash
clear
echo "Dit script maakt twee bestanden aan in je homefolder (een Private key en een public key)"
echo "Plaats de inhoud van het public (.pub) bestand in het authorized_keys betand in de .ssh folder"
echo "en gebruik het private betand in bijvoorbeeld putty om gebruik te maken van deze key"
echo ""
echo "Druk op ENTER om door te gaan"
read CONTINUE

clear

echo "voor welke gebruiker moet er een key worden aangemaakt? (geef voor het gemak je eigen naam op)"
read USER

clear

ssh-keygen -t rsa -b 2048 -f ~/$USER


Sla het bestand op met het commando
ESC :wq [ENTER]

Geef dit script het de juiste rechten zodat het script uitgevoerd kan worden.
chmod 755 door_jezelf_te_verzinnen_naam.sh [ENTER]

Voer het script uit met:
./door_jezelf_te_verzinnen_naam.sh


Er zijn nu twee bestanden aangemaakt in de folder waar je het script/commando hebt uitgevoerd.
Een prive en een publieke sleutel.
De prive sleutel is bedoeld voor jou persoonlijk en de publieke sleutel dien je op je NAS te plaatsen.

De bestanden hebben de volgende naam:
Prive key: door_jou_opgegeven_gebruikersnaam_key
Public kay: door_jou_opgegeven_gebruikersnaam_key.pub

LET OP!
Als je gebruik maakt van Putty:
Putty weet niet hoe hij om moet gaan met deze sleutels.

Om ervoor te zorgen dat je, je prive sleutel kan gebruiken met Putty dien je de sleutels te converteren.
Dit doe je alsvolgt:
Open het prive bestand.
cat door_jou_opgegeven_gebruikersnaam_key
selecteer/kopieer de tekst van het bestand en sla deze op, op je computer.
(bijvoorbeeld door notepad te openen en de tekst daar in te plakken)
 

Download De Putty key generator.
Open de Putty key generator en klik op "File" en vervolgens op "Load private key"
Volg de volgende stappen
Stap 1) vul bij Key comment je naam neer (root@NAS_NAAM)
Stap 2) vul je wachtwoord in en bevestig deze
Stap 3) Zorg dat SSH-2 RSA is geselecteerd
Stap 4) Zorg dat het aantal bits op 2048 staat
Stap 5) Klik op "Save private key" en sla deze op.
Stap 6) Kopieer de complete tekst uit het tekstveld

Foto 1.jpg[/attachment:1t576k86]

Maak in de /root/.ssh/ folder een bestand aan met de naam authorized_keys.
Plak de inhoud van het tekstveld in het authorized_keys betand in de .ssh folder

Gebruik het prive betand in bijvoorbeeld putty om gebruik te maken van deze key.
OpenPutty en geef de volgende gegevens op:

Foto 2.jpg[/attachment:1t576k86]

Vouw vervolgens aan de linkerkant SSH uit en klik op Auth.
Zet vinkjes neer zoals hier onder aangegeven en Browse vervolgens naar je Private key.

Foto 3.jpg[/attachment:1t576k86]

Klik nu aan de linker kant boven in op "Session" en sla dit profiel op.
Stap 1) Geef een naam op bij "Saved Sessions" (De naam van je NAS is voldoende)
Stap 2) Klik op "Save"
Stap 3) Klik op "Open" om verbinding te maken met je NAS.

[ Gespecificeerde bijlage is niet beschikbaar ]Foto 4.jpg[/attachment:1t576k86]

Er wordt nu gevraagd om je wachtwoord op te geven dat je hebt opgegeven voor je Private key.
Using username "root".
Authenticating with public key "jouw_prive_key_file"
Passphrase for key "jouw_gebruikersnaam":

Vul je wachtwoord in, druk op [ENTER] en je bent verbonden met je NAS via SSH met een KEY!
Alle commando's die je nu uitvoerd zullen versleuteld naar je NAS gaan.
Inloggen vanaf het internet via SSH is hierdoor een stuk veiliger geworden.


Maar we zijn er nog niet!
Het is op dit moment ook nog mogelijk om in te loggen op je NAS _ZONDER_ dat daar een key voor nodig is.

Om ervoor te zorgen dat het alleen mogelijk is om in te loggen op je nas met het root account en je een key moet gebruiken dien je dit op te geven in je ssh configuratie bestand. (/etc/ssh/sshd_config)

Mijn /etc/ssh/sshd_config ziet er als volgt uit:
# $OpenBSD: sshd_config,v 1.82 2010/09/06 17:10:19 naddy Exp $

# This is the sshd server system-wide configuration file.  See
# sshd_config(5) for more information.

# This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin

# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented.  Uncommented options change a
# default value.

#Port 22
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::

# The default requires explicit activation of protocol 1
#Protocol 2

# HostKey for protocol version 1
#HostKey /etc/ssh/ssh_host_key
# HostKeys for protocol version 2
#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_dsa_key
#HostKey /etc/ssh/ssh_host_ecdsa_key

# Lifetime and size of ephemeral version 1 server key
#KeyRegenerationInterval 1h
#ServerKeyBits 1024

# Logging
# obsoletes QuietMode and FascistLogging
SyslogFacility AUTH
LogLevel INFO
#LogLevel VERBOSE

# Authentication:

LoginGraceTime 1m
#PermitRootLogin yes
#StrictModes yes
MaxAuthTries 6
#MaxSessions 10

#RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys

# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
#RhostsRSAAuthentication no
# similar for protocol version 2
#HostbasedAuthentication no
# Change to yes if you don't trust ~/.ssh/known_hosts for
# RhostsRSAAuthentication and HostbasedAuthentication
#IgnoreUserKnownHosts no
# Don't read the user's ~/.rhosts and ~/.shosts files
#IgnoreRhosts yes

# To disable tunneled clear text passwords, change to no here!
PasswordAuthentication no
PermitEmptyPasswords no

# Change to no to disable s/key passwords
#ChallengeResponseAuthentication yes
ChallengeResponseAuthentication no

# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#KerberosGetAFSToken no

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes

# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication.  Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
UsePAM yes
#UsePAM no

#AllowAgentForwarding yes
#AllowTcpForwarding yes
#GatewayPorts no
#X11Forwarding no
#X11DisplayOffset 10
#X11UseLocalhost yes
#PrintMotd yes
#PrintLastLog yes
#TCPKeepAlive yes
#UseLogin no
#UsePrivilegeSeparation yes
#PermitUserEnvironment no
#Compression delayed
#ClientAliveInterval 0
#ClientAliveCountMax 3
#UseDNS yes
#PidFile /var/run/sshd.pid
#MaxStartups 10
#PermitTunnel no
ChrootDirectory none
#ChrootDirectory /var/services/homes/%u
#DenyUsers admin

# no default banner path
#Banner none

# override default of no subsystems
#Subsystem sftp /usr/libexec/sftp-server
#Subsystem       sftp    internal-sftp -f DAEMON -l VERBOSE
#Subsystem       sftp    /usr/syno/sbin/sftp-server -l DEBUG3
Subsystem       sftp    internal-sftp

# the following are HPN related configuration options
# tcp receive buffer polling. disable in non autotuning kernels
#TcpRcvBufPoll yes
 
# allow the use of the none cipher
#NoneEnabled no

# disable hpn performance boosts.
#HPNDisabled no

# buffer size for hpn to non-hpn connections
#HPNBufferSize 2048


# Example of overriding settings on a per-user basis
#Match User anoncvs
# X11Forwarding no
# AllowTcpForwarding no
# ForceCommand cvs server

Dit zorgt er voor dat je alleen nog maar als root in kan loggen als je gebruik maakt van een key.
(Veel veiliger!)

Ik weet helaas niet hoe hoe bestand er voor mijn aanpassingen uitzag dus je moet zelf de opties even nalopen of je hele config overschrijven met de mijne.


Dit was alles.
Succes en veel plezier!

bedankt voor je compliment en je toevoeging

Heel stom van mij.... Bij het vullen van de authorized_keys is er een letter komen te vervallen.
Nu goed gevuld, en alles werkt naar behoren.

Thx

Iemand een idee hoe ik ervoor kan zorgen dat je alleen als root kan inloggen met een dergelijk certificaat? Ik vind het een beetje eng om afhankelijk te zijn van 1 bestandje.

Wil dus eigenlijk:
- root login doormiddel van certificaat
- ander account inloggen doormiddel van password

Op het forum had ik al een handleiding gevonden hoe ik een ander account toegang kan geven dan alleen het root account.

Je kunt alleen root laten inloggen via het boven aangemaakte certificaat (RSA key) door de volgende configuratie aan te geven in je SSH config bestand:

PermitRootLogin without-password
Root kan nu alleen met het certificaat inloggen, dus niet meer met het admin wachtwoord.

Door de volgende (default) configuratie te laten staan:

PasswordAuthentication yes
Kunnen de overige gebruikers nog gewoon inloggen via hun bekende wachtwoord.

Heb alle stappen gedaan zo ver ik weet maar blijf "Server refused our key" krijgen en het begind me aardig te frustreren. Wie weet raad

Allereerst bedankt voor je reactie, kun je me vertellen wat de exacte locatie moet zijn voor alle bestanden?

Ik gebruik DSM 4.3 en werkt prima.
Paar opmerkingen over de handleiding/stappenplan:
-de foto's staan een beetje door elkaar
-

Maak in de /root/.ssh/ folder een bestand aan met de naam authorized_keys.
Plak de inhoud van het tekstveld in het authorized_keys betand in de .ssh folder

Dit is fout. Copieer of plak de inhoud van je publickey zoals in de eerste stap is gemaakt door ssh-keygen in authorized_keys. Zorg dat ie in de juiste map staat: /root/.ssh
-voor de laatste stap te laten werken moet je inderdaad zoals een andere poster zei, je systeem herstarten
-Als je WinSCP gebruikt om een verbinding te maken moet je SCP als protocol kiezen anders kan je niet als Root inloggen.

Een vergelijkbare handleiding vind je hier: http://www.mauchle.name/blog/?p=239

synoservicectl --restart sshd

Volgens mij werkt dat ook niet meer in DSM6 dus, reboot eens.