Connexion SSH en Public Key / Priv. Key avec DS216Play sous DSM6.0. et Kimsufi

[ppx32]

Bonjour,

J'ai acheté recement un NAS DS216Play (Syno) sous DSM6.0 . Mon but est de le relier (sans mot de passe) à un serveur dédié (Kimsufi) sous Ubuntu 14.

Je pense avoir fait la plupart des tutoriaux (et bien compris le principe) pour la connexion avec la clé publique à copier, mais cela ne passe toujours, j'ai toujours le mot de passe qui m'est demandé à la connexion....D'ailleurs, j'ai cru comprendre par contre que le compte "root" n'est plus accessible en direct SSH mais par compte un utilisateur admin suivi du "sudo -i" .

En résumé si j'ai bien compris cela consiste à depuis mon serveur linux kimsufi à générer les clés publiques & privées avec SSHKeygen -t rsa

Ensuite sur mon NAS Synology, je copie la clé publique sur le serveur , création du dossier ~/.ssh ( de l'utilisateur admin) suivi de "cat cle_pub.rsa >  ~/.ssh/autorized_keys" . Je pense à faire le chmod 700 sur le ~/.ssh suivi du chmod 664 ~/.ssh/autorized_keys . (donc l'emplacement est /var/services/homes/dupont/.ssh/autorized_keys)

Enfin voici le contenu de mon sshd_config du NAS  d'ailleurs si pouvez me dire si j'ai  des erreurs :

Citation

#   $OpenBSD: sshd_config,v 1.94 2015/02/02 01:57:44 deraadt 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 override the
# 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
#HostKey /etc/ssh/ssh_host_ed25519_key

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

# Ciphers and keying
#RekeyLimit default none

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

# Authentication:

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

#RSAAuthentication yes
PubkeyAuthentication yes

# The default is to check both .ssh/authorized_keys and .ssh/authorized_keys2
# but this is overridden so installations will only check .ssh/authorized_keys
AuthorizedKeysFile  .ssh/authorized_keys

#AuthorizedPrincipalsFile none

#AuthorizedKeysCommand none
#AuthorizedKeysCommandUser nobody

# 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 yes
#PermitEmptyPasswords no

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

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

# 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

#AllowAgentForwarding yes
AllowTcpForwarding no
#GatewayPorts no
#X11Forwarding no
#X11DisplayOffset 10
#X11UseLocalhost yes
#PermitTTY yes
#PrintMotd yes
#PrintLastLog yes
#TCPKeepAlive yes
#UseLogin no
UsePrivilegeSeparation sandbox      # Default for new installations.
#PermitUserEnvironment no
#Compression delayed
#ClientAliveInterval 0
#ClientAliveCountMax 3
#UseDNS no
#PidFile /var/run/sshd.pid
#MaxStartups 10:30:100
#PermitTunnel no
ChrootDirectory none
#VersionAddendum none

# no default banner path
#Banner none
# override default of no subsystems
#Subsystem  sftp    /usr/libexec/sftp-server
Subsystem       sftp    internal-sftp -f DAEMON -u 000

# the following are HPN related configuration options
# tcp receive buffer polling. disable in non autotuning kernels
#TcpRcvBufPoll yes

# disable hpn performance boosts
#HPNDisabled no

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

# allow the use of the none cipher
#NoneEnabled no

# Example of overriding settings on a per-user basis
#Match User anoncvs
#   X11Forwarding no
#   AllowTcpForwarding no
#   PermitTTY no
#   ForceCommand cvs server
Match User root
    AllowTcpForwarding yes
Match User admin
    AllowTcpForwarding yes
Match User anonymous
    AllowTcpForwarding no
    GatewayPorts no

Si vous pouvez m'aider svp, car je n'arrive pas à trouver où se trovue mon erreur.

Aussi, j'ai même copier le autorized_keys dans /root/.ssh etc...

 

merci d'avance

 

Modifié le 9 avril 2016 par ppx32
correction titre

[Fenrir]

Difficile de t'aider, tu as décris ce que tu as fait, mais pas ce qui ne marche pas

Avec ce que tu as fait, c'est ton serveur ovh qui doit va se connecter à ton nas, donc il faut autoriser le flux ssh depuis ovh vers ton nas

il y a 22 minutes, ppx32 a dit :

D'ailleurs, j'ai cru comprendre par contre que le compte "root" n'est plus accessible en direct SSH mais par compte un utilisateur admin suivi du "sudo -i" .

Tu peux parfaitement te connecter en root directement ... avec une clef ssh justement (j'ai du le faire 50 fois aujourd'hui pour aider sur un autre post)

[ppx32]

Cela me demande à chaque fois le mot de passe....mais là à force de le faire...je commence à perdre la logique du sens...de connectivité...

Je fais générer les clés depuis le Linux Kimsufi pour intégrer la clé publque au NAS .

Mais au final du coup c'est le kimsufi qui se connecte ou le NAS lol tellement passé de temps que je ne sais plus. De même avec cette histoire de Root/pas Root, le fichier autorized_keys dans celui de l'utilisateur admin ou le root ?

 

merci beaucoup

Modifié le 9 avril 2016 par ppx32

[Fenrir]

Il n'y a qu'une chose à retenir : la clef privée permet de se connecter au compte@server qui a autorisé la clef public

Donc :

• login@nas# ssh root@ovh  //on va utiliser la clef privée de "login sur nas" pour se connecter à "root sur ovh"
• login@ovh# ssh root@nas //on va utiliser la clef privée de "login sur ovh" pour se connecter à "root sur nas"
• login@nas# ssh root@nas //on va utiliser la clef privée de "login sur nas" pour se connecter à "root sur nas"

Modifié le 9 avril 2016 par Fenrir

[ppx32]

meme avec DSM6 donc ?

si je mets Root (DSM 6.0) je mets les clés donc dans le .SSH de /root et non de l'utuilsiateur admin ?

[Fenrir]

il y a 3 minutes, ppx32 a dit :

meme avec DSM6 donc ?

si je mets Root (DSM 6.0) je mets les clés donc dans le .SSH de /root et non de l'utuilsiateur admin ?

oui

root@nas:~# cat /root/.ssh/authorized_keys
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQCctyi+2cWMMfZoyw2HQLK51sLRJNRogU9x1k9hR4cFenn8TObRoXtp6VNqJXK1zl0TXPj2NOD/CvaJZlEb2WFxKN6TknRc2pmrteN+ZkdRiYknW+71ALBrysq7PtyAOLGK12uahC9O8XUR2wYSfl5NA09/e7uo8n+ukZcKuop6okZ2O0TnL92V7OMhtYGIMy07ddEPQbwiJ5HRSYvyNR1YfBJnSqRK7p5y6w83xMJ2SZbcO/PKvsmd1XW7qv7qOn1PIft2VE4fcJ2aBkBS84thOmIDlley4Vh+hzUN/+UDBnQEEX78haKaP/e7TbLzefz/Plkm83/cy+Jc/nrFzTsUk+hogYryxNgdMqWe0mtvqjbbBXEZ6VLmkXfbvXsvzBf8uYo04SfpOuBUqbrX8hVuZ3BspyXKu1KH+ejuaI9J68oppzEdiIrwNV2AQtNdc2senCn4fkCGte4m/lOiCj2sUPA18gfg0JQOztxFG2wB/nv2YgWPiKE5DjRbBp6bEFxMQzCdV7P8Dh5JIx980vv08sf03gd1P0WT1nVigFZvRgTCovy62ndsIHkmgCnG1I3hQGZMTl1nFvu3d8qvipGPCjkHAyyuIkvz/mDhBm3ZIws739zNa3w3oKtsrTC+AxqOQ57+YD6zi26lPyegZcjmX05Lqn4PrIfqMfnMkJLBwQ== fenrir@xxxxxxxx

[ppx32]

Déja un gros merci pour ton suivi

Voici le contenu de chaque coté NAS & Serveur :

Citation

root@NAS > cat /root/.ssh/autorized_keys
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC3xDPvkpzfaX9Ygx+ZW7aFqBCKgeLyIBrZ8IDQrx5o6Vm5s/udCFGfhA0/2x2Z/4VLJptxuIuA1TJzB6+aQgokwa0wal2CCxkqmRi6EKpJOjGQr/Es8CuVMUmheyoHepCRFtuLvbqJ20DQmnkzsaCvJINmel7qbBo6wZY0y/f9LrUKD+2wGxJSDZ+Azt5wW59JwEkgkGrhgoMiJJN9xOQDkcCgYTRgHG67gwfUUj5BUSCuOG5F20vCn9xCmXbs9Tajct255I7xcCeQilolCBUK9cWkGwkQDHPMC5eLhNJzQDpFoJ+Ny2XmpikQfq08irel1I6UwzjvMWYNmAxQFZPT root@YYYYY

root@YYYYY > cat /root/.ssh/id_rsa.pub
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC3xDPvkpzfaX9Ygx+ZW7aFqBCKgeLyIBrZ8IDQrx5o6Vm5s/udCFGfhA0/2x2Z/4VLJptxuIuA1TJzB6+aQgokwa0wal2CCxkqmRi6EKpJOjGQr/Es8CuVMUmheyoHepCRFtuLvbqJ20DQmnkzsaCvJINmel7qbBo6wZY0y/f9LrUKD+2wGxJSDZ+Azt5wW59JwEkgkGrhgoMiJJN9xOQDkcCgYTRgHG67gwfUUj5BUSCuOG5F20vCn9xCmXbs9Tajct255I7xcCeQilolCBUK9cWkGwkQDHPMC5eLhNJzQDpFoJ+Ny2XmpikQfq08irel1I6UwzjvMWYNmAxQFZPT root@YYYYY

 

Modifié le 9 avril 2016 par ppx32

[Fenrir]

Regarde dans les logs : cat /var/log/auth.log

[ppx32]

j'ai le doute aussi du coup sur ma config du sshd_config décrite plus haut ? tout est valide ? nottament le RSAAuthentification...j'ai vu des tuto indiqué de retirer le # pour l'activer tandis que d'autres de le laisser ...

[Fenrir]

à l’instant, ppx32 a dit :

j'ai le doute aussi du coup sur ma config du sshd_config décrite plus haut ? tout est valide ? nottament le RSAAuthentification...j'ai vu des tuto indiqué de retirer le # pour l'activer tandis que d'autres de le laisser ...

La conf par défaut de DSM 6.0 fonctionne très bien, vérifie les logs

[ppx32]

est ce possible svp d'avoir un sshd_config par défaut?..à force d'avoir modifier je ne sais plus quels était le param par défaut ?

 

merci

je precise aussi que dans le panneau de configuration DSM le compte "admin" est désactivé

[Fenrir]

##/etc/ssh/sshd_config
Ciphers aes128-ctr,aes128-gcm@openssh.com,aes192-ctr,aes256-ctr,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com
KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256
MACs hmac-sha2-256,hmac-sha2-256-etm@openssh.com,hmac-sha2-512,hmac-sha2-512-etm@openssh.com,umac-128-etm@openssh.com,umac-128@openssh.com
#       $OpenBSD: sshd_config,v 1.93 2014/01/10 05:59:19 djm 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 override the
# 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
#HostKey /etc/ssh/ssh_host_ed25519_key

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

# Ciphers and keying
#RekeyLimit default none

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

# Authentication:

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

#RSAAuthentication yes
#PubkeyAuthentication yes

# The default is to check both .ssh/authorized_keys and .ssh/authorized_keys2
# but this is overridden so installations will only check .ssh/authorized_keys
#AuthorizedKeysFile     .ssh/authorized_keys

#AuthorizedPrincipalsFile none

#AuthorizedKeysCommand none
#AuthorizedKeysCommandUser nobody

# 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 yes
#PermitEmptyPasswords no

# Change to no to disable s/key passwords
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

#AllowAgentForwarding yes
AllowTcpForwarding no
#GatewayPorts no
#X11Forwarding no
#X11DisplayOffset 10
#X11UseLocalhost yes
#PermitTTY yes
#PrintMotd yes
#PrintLastLog yes
#TCPKeepAlive yes
#UseLogin no
UsePrivilegeSeparation sandbox          # Default for new installations.
#PermitUserEnvironment no
#Compression delayed
#ClientAliveInterval 0
#ClientAliveCountMax 3
UseDNS no
#PidFile /var/run/sshd.pid
#MaxStartups 10:30:100
#PermitTunnel no
ChrootDirectory none
#VersionAddendum none

# no default banner path
#Banner none

# override default of no subsystems
#Subsystem      sftp    /usr/libexec/sftp-server
Subsystem       sftp    internal-sftp -f DAEMON -u 000

# the following are HPN related configuration options
# tcp receive buffer polling. disable in non autotuning kernels
#TcpRcvBufPoll yes

# disable hpn performance boosts
#HPNDisabled no

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


# allow the use of the none cipher
#NoneEnabled no

# Example of overriding settings on a per-user basis
#Match User anoncvs
#       X11Forwarding no
#       AllowTcpForwarding no
#       PermitTTY no
#       ForceCommand cvs server
Match User root
        AllowTcpForwarding yes
Match User admin
        AllowTcpForwarding yes
Match User anonymous
        AllowTcpForwarding no
        GatewayPorts no

Il n'est pas tout à fait par défaut, mais il fonctionne

 

[ppx32]

au niveau des logs je supose que c'est /var/log/auth.log ?

[Fenrir]

il y a 25 minutes, Fenrir a dit :

Regarde dans les logs : cat /var/log/auth.log

 

il y a 8 minutes, ppx32 a dit :

au niveau des logs je supose que c'est /var/log/auth.log ?

 

[ppx32]

Il me demande toujours le mot de passe que ce soit avec l'utilisateur admin (ex:dupont) ou root : 

 

Apr  9 23:25:26 NAS sshd[1652]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=adresse_ip_serveur  user=root
Apr  9 23:25:31 NAS sshd[1763]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=adresse_ip_serveur  user=dupont
 

c'est comme si cela ne prenait pas en compte...

[Fenrir]

Installe ma clef public et donne moi les infos de connexion en mp (adresse et login)

edit : si tu préfère, on peut faire un teamviewer

Modifié le 9 avril 2016 par Fenrir

[Kervinou]

Hello, je racole un peu, nous échangeons sur un sujet similaire par ici.... Si les visiteurs de ce sujet peuvent venir jeter un œil svp !

Merci

[erbou]

Bonjour,

J'ai un problème similaire.

Au terme d'une longue recherche du moyen d'exécuter sudo dans une ligne de script sans rester à la console pour saisir le mot de passe, j'ai fini par trouver mais je me suis "mélangé les pinceaux" et maintenant je suis comme enfermé dehors de mon NAS.

Voici comment je me suis retrouvé dans cette situation.

J'ai commencé par saisir sur mon client Xubuntu :

ssh root@192.168.1.28

Au lieu de copier tout de suite la clé publique ainsi générée sur mon NAS sous DSM 6.1, j'ai procédé dans l'ordre inverse en adaptant le fichier sshd_config du même serveur à l'aide des spécifications suivantes :

Port 22

Protocol 2

LoginGraceTime 2m

RSAAuthentication yes

PubkeyAuthentication yes

AuthorizedKeysFile .ssh/authorized_keys

PasswordAuthentication no

UsePAM no

Et ce n'est qu'ensuite, que j'ai saisi cette commande sur le serveur :

ssh-copy-id -i /home/tt/.ssh/id_rsa.pub root@192.168.1.28

Et c'est comme cela que, lorsque je veux utiliser ssh, je me trouve bloqué :

ssh root@192.168.1.28

Permission denied (publickey).

En effet, de la façon dont j'ai configuré le serveur, il exige inflexiblement une clé et refuse tout mot de passe quel que soit l'utilisateur qui se présente.

J'ai déjà redémarré le NAS et rebouté le PC en Xubuntu Live, ça ne change rien et je ne veux pas non plus devoir faire une RAZ complète du serveur.

Il y aurait peut-être une piste à explorer en tentant une connexion PuTTY qui passerait certains paramètres au serveur de façon à "overrider" les paramètres bloquant du fichier sshd_config, mais, pour cela, j'aurais besoin de vos lumières.

 

[ngoisao]

il m'est arrivé quelque chose de semblable il y a qques jours.. je ne parvenais plus à me connecter en ssh quel que soit le compte utilisateur ou root.

La solution à consister à activer le protocole TELNET depuis l'interface DSM , puis se connecter via telnet  en ligne de commande...

Attention,  recommander ensuite de désactiver ce protocole car pas tres secure…    et (pour une securité maximale)   modifier le mot de passe du compte utilisé,    car transite en clair et pourrait avoir été intercepté...