[kAzama<Off>]

Salut vous tous,

J'ai besoin de vos lumières sur mes tentatives de béothien.
J'ai un synology (DS213) sous la main sur lequel j'aimerais bien installer un serveur SVN et y accéder à distance en SSH.

J'ai créé un repo qui fonctionne bien en réseau local entre ma tour et mon nas (avec l'outil svn server directement accessible sur synology).
J'ai activé les autorisations SSH du NAS et débloquer le port 22 sur le parefeu du NAS.
J'ai fait une redirection sur mon routeur du port 22 vers mon NAS. (j'ai un castlenet de chez Numéricable)

Et là le drame.
J'essaie de me connecter à distance avec conerstone en ciblant username@ipdemabox:22 Et çà veux pas.
Je dois raté un épisode... donc je prends tout aide et conseils

[Adau]

Quand tu veux y accéder à distance, c'est bien en dehors de ton réseau local ?

[kAzama<Off>]

Ouaip je confirme je suis en dehors de mon réseau local lorsque je souhaite y accéder à distance (le repo fonctionne parfaitement en local)

Edit : je crois bien avoir trouvé, j'ai bien l'impression d'avoir foiré en attribuant une ip fixe au nas de la mauvaise façon :d
Edit 2 : Ah bah non je suis stuck complétement là.

[Drachen]

Essaye de virer le port dans ton adresse de connexion.

[kAzama<Off>]

Putain çà a pas trainer à l'ouverture SSH, c'est moi ou je subis une attaque bruteforce là ?
Ah oui le mec est sous proxy. Zuper.
Bon j'ai coupé en attendant de trouver une soluce, merci les mots de passes à 20 caractères que je change régulièrement. :<

[Adau]

Ca c'est normal

Mon serveur perso chez OVH se fait agresser quotidiennement par des tentatives de connexion en SSH. Le mieux est de blacklister l'IP pendant 30 minutes après 5 mauvaises tentatives de connexion.

Sinon, pour le sujet principal, je vois où est le problème

[kAzama<Off>]

Ahah je découvre, veux pas faire de bétises surtout :d
Tu aurais une idée pour faire ce blacklistage auto ?

(trouvé merci pour le truc dormirais mieux )

Pou mon histoire de connexion, je vais réésseayer là. Je vous dis :<

[kAzama<Off>]

Bon sa progresse,
J'arrive à me connecter puisque je vois que le NAS bloque ma tentative de connexion lorsque j'essaie de me connecter de l'extérieur sans stipuler de port dans Cornerstone :>
"failed to login via SSH due to authorization failure"
Par contre savoir pourquoi... Je sais pas...

[kAzama<Off>]

Bon je vais essayer de récapituler parce que je vois pas ou est le bug là.

Donc en allant étape par étape j'ai :

Citation :

étape 1 :
- 1 - télécharger le paquet svn sur mon syno et crée un repo affilié à mon ddns.
- 2 - créer un utilisateur pour ce repo.
- 3 4 - créer un DDNS pour pouvoir pointer sur mon nas même quand l'ip changera.
étape 2 :
- Ouvert le port 22 au niveau du NAS.
étape 3 :
- Autoriser les échanges et connexion SSH au niveau du NAS.
étape 4 :
- j'ai fait un redirection du port 22 vers l'ip fixe de mon NAS (fixé au niveau du nas voir étape 6)
étape 5 :
- j'ai fait un déclenchement e port sur le 22 (parait que sa pouvait être bloquant)

Et je me retrouve avec la même fenêtre en première page : [user] failed to login via SSH due to authorization failure

[kAzama<Off>]

Ah grande question là. Je viens d'arriver à accéder à mon repo de l'extérieur à partir de cornerstone en ne me connectant pas en SSH.
Cela implique quoi purée ?

Ah oui, puis j'ai fait des résas DHCP un peu plus propre pour l'ip fixe de mon NAS, ainsi qu'un forward du port 3690 comme dis ici : http://forum.synology.com/enu/viewto...=73045#p279876

Bon je crois que j'ai compris. Faut que je génère mes clés pairs pour me connecter en ssh. didiou çà s'annonce rigolol.

[Mixo`]

Une manière de débugger serait de se connecter à ton NAS en mode console, activer les logs ssh en mode debug et regarder les logs. Google dit que c'est possible à priori. Tu peux en tout cas tenter de te connecter en ssh avec la commande ssh -v username@IPdetabox, ça rend les choses un peu explicites. Et ou tenter un petit telnet <ipdetabox> 22 d'un poste distant, voir si c'est ssh qui déconne ou plutôt ta configuration réseau.

As-tu déjà simplement testé de te connecter au serveur ssh en étant dans ton réseau local ?

A part ça, je vois deux soucis possibles :
- Mauvaise configuration vis à vis de la box : normalement il suffit de faire ce qu'il faut dans "transfert de ports", en mettant en Port de départ : 22 / Port de fin : 22 / Protocole : TCP / IP locale : IP de ton NAS.
- Le serveur ssh synologie qui n'accepterait pas de connexion externe autre que ton réseau local.

Je te conseille de changer le port ssh de 22 à autre chose (9922 ou whatever !) pour éviter le genre d'attaque basique que tu as eu, sinon.

Citation :

Publié par kAzama<Off>

Bon je crois que j'ai compris. Faut que je génère mes clés pairs pour me connecter en ssh. didiou çà s'annonce rigolol.

Ca m'étonnerait qu'on ne puisse pas se connecter avec une authentification basique (via username / password).

[kAzama<Off>]

et bien je patauge pas mal, je découvre que j'avais pas vraiment compris ce qu'était le ssh là.

Non j'ai pas trop toucher à quoique ce soit niveau débug, c'est un peu obscur pour moi là...

[kAzama<Off>]

Ahem...

Citation :

NAS> ssh -v [USER]@192.168.0.1
OpenSSH_5.8p1-hpn13v11, OpenSSL 1.0.1e-fips 11 Feb 2013
debug1: Connecting to 192.168.0.1 [192.168.0.1] port 22.
debug1: connect to address 192.168.0.1 port 22: Connection timed out
ssh: connect to host 192.168.0.1 port 22: Connection timed out
NAS> ssh -v [USER]@192.168.0.3
OpenSSH_5.8p1-hpn13v11, OpenSSL 1.0.1e-fips 11 Feb 2013
debug1: Connecting to 192.168.0.3 [192.168.0.3] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: identity file /root/.ssh/id_rsa type -1
debug1: identity file /root/.ssh/id_rsa-cert type -1
debug1: identity file /root/.ssh/id_dsa type -1
debug1: identity file /root/.ssh/id_dsa-cert type -1
debug1: identity file /root/.ssh/id_ecdsa type -1
debug1: identity file /root/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.8p1-hpn13 v11
debug1: match: OpenSSH_5.8p1-hpn13v11 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.8p1-hpn13v11
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: AUTH STATE IS 0
debug1: REQUESTED ENC.NAME is 'aes128-ctr'
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: REQUESTED ENC.NAME is 'aes128-ctr'
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA ff:2f:7e:68:58:e5:e4:fc:bla:bla:bla:11:74:76:26:ae
The authenticity of host '192.168.0.3 (192.168.0.3)' can't be established.
ECDSA key fingerprint is ff:2f:7e:68:bla:bla:bla:fc:ee:5c:83:11:74:76:26:ae.

Warning: Permanently added '192.168.0.3' (ECDSA) to the list of known hosts.
debug1: ssh_ecdsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: /root/.ssh/id_rsa
debug1: Trying private key: /root/.ssh/id_dsa
debug1: Trying private key: /root/.ssh/id_ecdsa
debug1: Next authentication method: password
USER@192.168.0.3's password:
debug1: Authentication succeeded (password).
Authenticated to 192.168.0.3 ([192.168.0.3]:22).
debug1: Final hpn_buffer_size = 131072
debug1: HPN Disabled: 0, HPN Buffer Size: 131072
debug1: channel 0: new [client-session]
debug1: Enabled Dynamic Window Scaling

debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
Permission denied, please try again.
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
debug1: channel 0: free: client-session, nchannels 1
Connection to 192.168.0.3 closed.
Transferred: sent 1976, received 1552 bytes, in 0.0 seconds
Bytes per second: sent 64453.0, received 50623.0
debug1: Exit status 1

Afficher la suite

[Mixo`]

T'as oublié de cacher ton login à un moment.

Alors euuuh, à priori là de ce que je lis :

Citation :

NAS> ssh -v [USER]@192.168.0.1

Tu essayes de ssh ta box (IP 192.168.0.1) à partir du NAS : forcément tu te fais jeter, la box n'a pas de serveur ssh. Bref ça n'a pas beaucoup d'intérêt.

Citation :

NAS> ssh -v [USER]@192.168.0.3

J'imagine que 192.168.0.3 est l'ip de ton NAS ? Donc tu te connectes en ssh de ton NAS vers lui même là. On peut ça ne pose pas de souci, mais le test à faire aurait plutôt été de te connecter de ton PC vers le NAS, donc sur le PC faire un ssh -v user@192.168.0.3. Si t'es sous Windows, tu peux utiliser Putty pour le faire.

Mais bon les informations que tu donnes me font penser que le souci est là :
debug1: Entering interactive session.
Permission denied, please try again.

Après une rapide recherche, tu n'as pas le droit de ssh ton NAS avec autre chose que les users admin / root. Pour changer ça, suivre cette doc : http://forum.synology.com/enu/viewto...p?f=90&t=39385

Et donc faire ça : edit /etc/passwd and replace /sbin/nologin with /bin/bash for users you want allow to SSH into your box. A noter qu'il manque surement un 'b' dans le post du mec pour faire /bin/bash, je l'ai rajouté.

Si tu veux comprendre un peu comment ça marche : ton NAS utilise un système linux, /etc/passwd gère les utilisateurs, et ton utilisateur ne peut pas se loger si il est en mode "/sbin/nologin". Du coup si tu remplaces par "/bin/bash", il a un shell, donc ssh ne râle plus, donc ça marche.