frizzou
-
Compteur de contenus
8 -
Inscription
-
Dernière visite
Messages posté(e)s par frizzou
-
-
Ok je vais regarder, tu penses donc que la solution se trouve dans ma config ssh client / ou / serveur ?
0 -
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.0 -
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 10 -
Bon j'ai re-crée le dossier root du coup...
Tout semble fonctionner pour le moment, mes scripts s'éxecutent bien, reste à voir si tout fonctionne correctement...0 -
Bonjour à tous,
Je pense être le boulet du week-end... le titre dit tout, j'ai bel et bien supprimé mon folder root.
Pas la peine de me demander pourquoi, je m'en veux déjà assez...Bon la bonne nouvelle c'est qu'après reboot du NAS, j'ai toujours accès au GUI, en ssh via mon compte, mais évidemment plus le root... (D'ailleurs j'ai dû mal à comprendre pourquoi tout semble fonctionner)
Ma question est simple, y a t-il un moyen de le restaurer sans passer par un reset de mon syno ?
Merci...
0 -
Merci ! C'était bien ça... Du coup j'ai l'air un peu bête là
0 -
Bonjour à toute la communauté, ceci est mon premier message mais je viens souvent ici pour consulter les nombreux sujets d'aide que l'on peut trouver.
Cependant, pour une fois je n'ai pas trouvé mon bonheur...Je vous explique ma situation :
Je souhaite sauvegarder les données de mon syno vers un raspberry distant.
J'ai d'abord souhaité le faire via l'outil de sauvegarde classique mais je n'ai jamais pu me connecter à mon adresse distante, pourtant tout me semblait bien configuré...J'ai donc décidé de faire un rsync directement depuis le terminal (sur lequel je ping et me connecte sans problème à mon raspberry en ssh), mais malgré avoir bien activé la sauvegarde réseau, dès que je lance la commande j'ai une erreur 43, que voici :
sending incremental file list rsync error: rsync service is no running (code 43) at io.c(687) [sender=3.0.9]
Auriez-vous une idée de ce qu'il peut se passer ? Ou de ce que je peux mal faire...Pour info voici aussi ma commande :
/usr/syno/bin/rsync -avR -e "ssh -p xx" /volume1/{path}/ {user}@{raspberry-domain}:{backup-path}
Merci !
Oups, désolé je pensais avoir mis dans la bonne catégorie mon message mais à priori non, désolé...
0
SSH connexion close depuis un serveur externe, tout de suite après un login success
dans Terminal Telnet et SSH
Posté(e)
J'ai testé depuis plusieurs adresses, même chose...
Mais tu as raison, je vais regarder aussi du côté des NAT/PAT, j'ai configuré des ports externes.
Merci pour l'aiguillage, je vais regarder tout ça, je previens quand j'y m'en sors enfin :)