Contenu | Rechercher | Menus

Annonce

Si vous avez des soucis pour rester connecté, déconnectez-vous puis reconnectez-vous depuis ce lien en cochant la case
Me connecter automatiquement lors de mes prochaines visites.

À propos de l'équipe du forum.

#1 Le 13/12/2016, à 22:36

Jack le Castor

[RESOLU] connexion ssh NAS Synology impossible via clé publique/privée

Bonjour,

nous avons au boulot un NAS Synology accessible à distance grâce à une IP fixe et une redirection pour le port SSH.

Actuellement, on s'y connecte sans souci en entrant un mot de passe.
Mais je souhaiterais automatiser une synchronisation régulière de certains dossiers du NAS avec notre ordinateur portable, pour ensuite pouvoir par exemple bosser sur le portable même quand on est hors connexion (par ex dans le train).
Je souhaiterais donc que le portable puisse se connecter automatiquement, sans entrer de mot de passe, au NAS via SSH, que ce soit lorsqu'il est connecté au réseau local, ou lorsqu'il est à distance connecté à internet...

Problème : en utilisant la reconnaissance par clé publique / clé privée, le NAS se déconnecte immédiatement.

Voici ce que me renvoie la commande ssh -v [mon _NAS] une fois que j'ai fait l'enregistrement des clés :

jacky@LOCAL-PC:~$ ssh -v nas
OpenSSH_7.2p2 Ubuntu-4ubuntu2.1, OpenSSL 1.0.2g  1 Mar 2016
debug1: Reading configuration data /home/jacky/.ssh/config
debug1: /home/jacky/.ssh/config line 1: Applying options for nas
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to nas [xx.xx.xx.xx] port 22.
debug1: Connection established.
debug1: identity file /home/jacky/.ssh/id_rsa type 1
debug1: key_load_public: No such file or directory
debug1: identity file /home/jacky/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/jacky/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/jacky/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/jacky/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/jacky/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/jacky/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/jacky/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.2p2 Ubuntu-4ubuntu2.1
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.8p1-hpn14v6
debug1: match: OpenSSH_6.8p1-hpn14v6 pat OpenSSH* compat 0x04000000
debug1: Authenticating to nas:22 as 'Admin'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256@libssh.org
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:UPBk8Vhe3OZggr1etHctb6thIMaUyVTRcvCRxJb11zs
debug1: Host 'nas' is known and matches the ECDSA host key.
debug1: Found key in /home/jacky/.ssh/known_hosts:2
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/jacky/.ssh/id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 279
debug1: Authentication succeeded (publickey).
Authenticated to nas ([xx.xx.xx.xx]:22).
debug1: Local connections to LOCALHOST:8080 forwarded to remote address 192.168.0.1:80
debug1: Local forwarding listening on ::1 port 8080.
debug1: channel 0: new [port listener]
debug1: Local forwarding listening on 127.0.0.1 port 8080.
debug1: channel 1: new [port listener]
debug1: Local connections to LOCALHOST:3306 forwarded to remote address 192.168.0.13:55000
debug1: Local forwarding listening on ::1 port 3306.
debug1: channel 2: new [port listener]
debug1: Local forwarding listening on 127.0.0.1 port 3306.
debug1: channel 3: new [port listener]
debug1: Local connections to LOCALHOST:55000 forwarded to remote address 192.168.0.13:55000
debug1: Local forwarding listening on ::1 port 55000.
debug1: channel 4: new [port listener]
debug1: Local forwarding listening on 127.0.0.1 port 55000.
debug1: channel 5: new [port listener]
debug1: channel 6: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: pledge: network
debug1: channel 0: free: port listener, nchannels 7
debug1: channel 1: free: port listener, nchannels 6
debug1: channel 2: free: port listener, nchannels 5
debug1: channel 3: free: port listener, nchannels 4
debug1: channel 4: free: port listener, nchannels 3
debug1: channel 5: free: port listener, nchannels 2
debug1: channel 6: free: client-session, nchannels 1
Connection to nas closed by remote host.
Connection to nas closed.
Transferred: sent 2572, received 1604 bytes, in 0.0 seconds
Bytes per second: sent 19332885.1, received 12056744.8
debug1: Exit status -1
jacky@LOCAL-PC:~$

Si je comprends bien la ligne n°49 : "debug1: Authentication succeeded (publickey)."
cela signifie bien qu'il a réussi à se connecter ?

Pourtant on a la suite immédiate sans que je fasse rien, et déconnexion immédiatement !!!!


D'où grosse frayeur de ma part : je ne vais même plus pouvoir accéder à mon NAS à distance, aïe aïe aïe !
Ça dépasse donc mes compétences, et je vais avoir besoin d'aide (et pas uniquement d'essayer de comprendre la doc et les forums par moi-même) pour être certain de pas faire de conneries...


Heureusement, j'ai trouvé une parade (temporaire) :
En enlevant les fichiers id_rsa et id_rsa.pub du dossier ~/.ssh de "LOCAL-PC" (et en les mettant ailleurs pour sauvegarde), j'arrive de nouveau à me connecter au NAS ... mais en entrant obligatoirement le mot de passe !

Voici le résultat de la commande ssh -v [mon _NAS] après avoir retiré les fichiers id_rsa et id_rsa.pub du dossier ~/.ssh :

jacky@LOCAL-PC:~$ ssh -v nas
OpenSSH_7.2p2 Ubuntu-4ubuntu2.1, OpenSSL 1.0.2g  1 Mar 2016
debug1: Reading configuration data /home/jacky/.ssh/config
debug1: /home/jacky/.ssh/config line 1: Applying options for nas
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to nas [xx.xx.xx.xx] port 22.
debug1: Connection established.
debug1: key_load_public: No such file or directory
debug1: identity file /home/jacky/.ssh/id_rsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/jacky/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/jacky/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/jacky/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/jacky/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/jacky/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/jacky/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/jacky/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.2p2 Ubuntu-4ubuntu2.1
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.8p1-hpn14v6
debug1: match: OpenSSH_6.8p1-hpn14v6 pat OpenSSH* compat 0x04000000
debug1: Authenticating to nas:22 as 'Admin'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256@libssh.org
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:UPBk8Vhe3OZggr1etHctb6thIMaUyVTRcvCRxJb11zs
debug1: Host 'nas' is known and matches the ECDSA host key.
debug1: Found key in /home/jacky/.ssh/known_hosts:2
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: /home/jacky/.ssh/id_rsa
debug1: Trying private key: /home/jacky/.ssh/id_dsa
debug1: Trying private key: /home/jacky/.ssh/id_ecdsa
debug1: Trying private key: /home/jacky/.ssh/id_ed25519
debug1: Next authentication method: password
Admin@nas's password: 
debug1: Authentication succeeded (password).
Authenticated to nas ([xx.xx.xx.xx]:22).
debug1: Local connections to LOCALHOST:8080 forwarded to remote address 192.168.0.1:80
debug1: Local forwarding listening on ::1 port 8080.
debug1: channel 0: new [port listener]
debug1: Local forwarding listening on 127.0.0.1 port 8080.
debug1: channel 1: new [port listener]
debug1: Local connections to LOCALHOST:3306 forwarded to remote address 192.168.0.13:55000
debug1: Local forwarding listening on ::1 port 3306.
debug1: channel 2: new [port listener]
debug1: Local forwarding listening on 127.0.0.1 port 3306.
debug1: channel 3: new [port listener]
debug1: Local connections to LOCALHOST:55000 forwarded to remote address 192.168.0.13:55000
debug1: Local forwarding listening on ::1 port 55000.
debug1: channel 4: new [port listener]
debug1: Local forwarding listening on 127.0.0.1 port 55000.
debug1: channel 5: new [port listener]
debug1: channel 6: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: pledge: network
debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0
debug1: Sending environment.
debug1: Sending env LANG = fr_FR.UTF-8
admin@NAS:~$


Du coup, qu'est-ce qui cloche et empêche de maintenir la connexion via clé publique / clé privée ????



Pour info, voici le contenu du fichier /etc/ssh/sshd_config du NAS
(j'avoue que pour moi, tout ça est du chinois, même après avoir lu la doc sur ssh sur d'Ubuntu-fr, et que j'ai pas envie de tout planter en ayant changé une variable qu'il fallait pas changer) :

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,diffie-hellman-group14-sha1,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521
MACs hmac-sha1,hmac-sha1-etm@openssh.com,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,umac-64-etm@openssh.com,umac-64@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

Merci d'avance aux bonnes âmes wink

Jack le Castor

Dernière modification par Jack le Castor (Le 15/12/2016, à 23:25)

Hors ligne

#2 Le 15/12/2016, à 23:30

Jack le Castor

Re : [RESOLU] connexion ssh NAS Synology impossible via clé publique/privée

Bon en fait, la solution était toute conne :
dans le fichier .ssh/config de mon ordi, j'avais précisé le compte Admin (avec une majuscule) pour se connecter.

Ben écrit comme ça (Admin avec une majuscule), ça fonctionne pour se connecter avec mot de passe, mais pas avec clé publique.

J'ai trouvé la solution en tapant

ssh -p 22 admin@nas

sans majuscule, et là, ça fonctionne !!!

Restait plus qu'à corriger mon fichier .ssh/config en précisant admin sans majuscule. re-test : ça roule !!!!! smile


Il ne me reste plus qu'à paramétrer correctement rsync... smile

Hors ligne