Aller au contenu

SSH connexion close depuis un serveur externe, tout de suite après un login success


Messages recommandés

GUI : DSM 6

Je suis sous DSM 6 mais avec la v5 c'était pareil, je tente en vain de me connecter en ssh depuis un de mes serveurs externes :

ssh monuser@mondomain.com -p monPort

Tout se passe bien, on me demande mon password, je suis loggué mais juste après je me fait kicker.
Je précise que tout se passe bien en local.

Est-ce une restriction dû au fait que je sois en externe ? 
J'ai lu pas mal de choses pour configurer ma conf ssh, mais rien n'y, est-ce que quelqu'un aurait une idée ?

Authenticated to mondomain.com ([xx.xxx.xxx.xxx]:monPort).
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0
debug1: Remote: Ignored authorized keys: bad ownership or modes for directory /volume1/homes/monUser
debug1: SSH2_MSG_KEXINIT received
debug1: SSH2_MSG_KEXINIT sent
debug2: kex_parse_kexinit: curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ssh-dss-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-dss-cert-v00@openssh.com,ssh-ed25519,ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1,hmac-md5-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1,hmac-md5-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: first_kex_follows 0 
debug2: kex_parse_kexinit: reserved 0 
debug2: kex_parse_kexinit: curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256,ssh-ed25519
debug2: kex_parse_kexinit: aes128-ctr,aes128-gcm@openssh.com,aes192-ctr,aes256-ctr,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com
debug2: kex_parse_kexinit: aes128-ctr,aes128-gcm@openssh.com,aes192-ctr,aes256-ctr,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com
debug2: kex_parse_kexinit: 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
debug2: kex_parse_kexinit: 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
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: first_kex_follows 0 
debug2: kex_parse_kexinit: reserved 0 
debug2: mac_setup: setup umac-128-etm@openssh.com
debug1: kex: server->client aes128-ctr umac-128-etm@openssh.com none
debug2: mac_setup: setup umac-128-etm@openssh.com
debug1: kex: client->server aes128-ctr umac-128-etm@openssh.com none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx
debug1: verify_host_key: server host key matches cached key
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: set_newkeys: rekeying
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: set_newkeys: rekeying
debug1: SSH2_MSG_NEWKEYS received
debug2: callback start
debug2: fd 3 setting TCP_NODELAY
debug3: packet_set_tos: set IP_TOS 0x10
debug2: client_session2_setup: id 0
debug2: channel 0: request pty-req confirm 1
debug1: Sending environment.
debug3: Ignored env SHELL
debug3: Ignored env TERM
debug3: Ignored env USER
debug3: Ignored env LS_COLORS
debug3: Ignored env SUDO_USER
debug3: Ignored env SUDO_UID
debug3: Ignored env USERNAME
debug3: Ignored env MAIL
debug3: Ignored env PATH
debug3: Ignored env PWD
debug1: Sending env LANG = fr_FR.UTF-8
debug2: channel 0: request env confirm 0
debug3: Ignored env SHLVL
debug3: Ignored env SUDO_COMMAND
debug3: Ignored env HOME
debug3: Ignored env LOGNAME
debug3: Ignored env SUDO_GID
debug3: Ignored env _
debug2: channel 0: request shell confirm 1
debug2: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug2: channel_input_status_confirm: type 99 id 0
debug2: PTY allocation request accepted on channel 0
debug2: channel 0: rcvd adjust 87380
debug2: channel_input_status_confirm: type 99 id 0
debug2: shell request accepted on channel 0
Permission denied, please try again.
debug2: channel 0: rcvd eof
debug2: channel 0: output open -> drain
debug2: channel 0: obuf empty
debug2: channel 0: close_write
debug2: channel 0: output drain -> closed
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: client_input_channel_req: channel 0 rtype eow@openssh.com reply 0
debug2: channel 0: rcvd eow
debug2: channel 0: close_read
debug2: channel 0: input open -> closed
debug2: channel 0: rcvd close
debug3: channel 0: will not send data after close
debug2: channel 0: almost dead
debug2: channel 0: gc: notify user
debug2: channel 0: gc: user detached
debug2: channel 0: send close
debug2: channel 0: is dead
debug2: channel 0: garbage collecting
debug1: channel 0: free: client-session, nchannels 1
debug3: channel 0: status: The following connections are open:
  #0 client-session (t4 r0 i3/0 o3/0 fd -1/-1 cc -1)

Connection to mondomain.com closed.
Transferred: sent 5224, received 3432 bytes, in 0.5 seconds
Bytes per second: sent 10507.5, received 6903.1
debug1: Exit status 1

 

Modifié par frizzou
Lien vers le commentaire
Partager sur d’autres sites

Il y a 2 heures, Fenrir a dit :

Essaye avec un compte du groupe administrateur (créés un nouveau compte)

Le compte avec lequel j'essaye de me connecter est dans le groupe admin.
Comme je le mentionne dans mon premier post, je me connecte sans souci en local, mais pas depuis mon serveur qui est en externe.

Lien vers le commentaire
Partager sur d’autres sites

Il peut s'agir d'un soucis au niveau du chiffrement, trop ou pas assez fort (ou avec une méthode non supportée).

On peut faire quelques ajustement dans DSM pour ça (dans les paramètres).

Tu peux aussi le régler coté client ssh sur ton serveur.

Il y a 8 heures, frizzou a dit :

Est-ce une restriction dû au fait que je sois en externe ? 

chez moi (enfin depuis internet vers mon nas en DSM 6.0) ça fonctionne sans soucis (je viens de tester)

Lien vers le commentaire
Partager sur d’autres sites

à l’instant, frizzou a dit :

Ok je vais regarder, tu penses donc que la solution se trouve dans ma config ssh client / ou / serveur ? 

l'un, l'autre, les 2

Si c'est bien un soucis de chiffrement (c'est une hypothèse), il faut simplement que les 2 (client et serveur) s'entendent sur une méthode commune

Autre possibilité, un soucis de firewall et/ou de nat et/ou d'ip => dans ce cas c'est difficile de t'aider, il faudrait passer en revu tous les éléments de la chaine :

  • as tu un autre NAT vers ton nas qui fonctionne depuis ton serveur ?
    • si oui, vérifie que les 2 règles (ssh et l'autre) sont identiques (sauf le port bien sur)
    • si non, essaye de créer une règle pour un autre protocole en TCP (http c'est le plus simple) et test de puis ton serveur avec un wget/curl/telnet

Tu peux aussi tester depuis une autre adresse internet (un autre serveur, un ami, un voisin, un smartphone ...) avec un autre client ssh

Lien vers le commentaire
Partager sur d’autres sites

Rejoindre la conversation

Vous pouvez publier maintenant et vous inscrire plus tard. Si vous avez un compte, connectez-vous maintenant pour publier avec votre compte.

Invité
Répondre à ce sujet…

×   Collé en tant que texte enrichi.   Coller en tant que texte brut à la place

  Seulement 75 émoticônes maximum sont autorisées.

×   Votre lien a été automatiquement intégré.   Afficher plutôt comme un lien

×   Votre contenu précédent a été rétabli.   Vider l’éditeur

×   Vous ne pouvez pas directement coller des images. Envoyez-les depuis votre ordinateur ou insérez-les depuis une URL.

×
×
  • Créer...

Information importante

Nous avons placé des cookies sur votre appareil pour aider à améliorer ce site. Vous pouvez choisir d’ajuster vos paramètres de cookie, sinon nous supposerons que vous êtes d’accord pour continuer.