Aller au contenu

Acc


Lechatmatou

Messages recommandés

Bonsoir,

Débutant sur synology j'ai besoin d'accéder à un serveur distant pour effectuer quelques changements.

J'ai lu que l'accès via telnet n'était pas sécurisant et que SSH était préférable. Outil utilisé : PuTTY.

Première question Telnet :

Pour des interventions ponctuelles l'ouverture permanente du port 23 conjuguée avec l'activation ponctuelle du service dans l'interface WEB est-elle une première méthode acceptable ? Quels risques encourus ?

Deuxième question SSH :

Le fait de se connecter la première fois sur le serveur pour utilisation console, provoque un message d'acceptation de reconnaissance, un code est édité, comment le retrouver et à quoi sert-il ?

lors des connexions suivantes on en est à quel niveau de sécurité par rapport à Telnet ?

Existe-t-il un tuto ou une doc permettant de comprendre la mise en oeuvre des différents niveaux :

- accès console

- transferts de fichiers

- ....

Que signifie le transfert de fichiers sous SSH par rapport à rsync ? Ce dernier nécessitant l'ouverture du port 873....

Merci

Lien vers le commentaire
Partager sur d’autres sites

Bonsoir,

Débutant sur synology j'ai besoin d'accéder à un serveur distant pour effectuer quelques changements.

J'ai lu que l'accès via telnet n'était pas sécurisant et que SSH était préférable. Outil utilisé : PuTTY.

Première question Telnet :

Pour des interventions ponctuelles l'ouverture permanente du port 23 conjuguée avec l'activation ponctuelle du service dans l'interface WEB est-elle une première méthode acceptable ? Quels risques encourus ?

En fait, le principal problème avec telnet est que le mot de passe est transmis en clair et peut donc être sniffé au passage. Le transfert des données est également en clair mais c'est un peu moins problématique.

Puisque ton synon supporte le ssh, il ne faut en aucun cas utiliser telnet depuis l'extérieur, même avec une activation ponctuelle.

Deuxième question SSH :

Le fait de se connecter la première fois sur le serveur pour utilisation console, provoque un message d'acceptation de reconnaissance, un code est édité, comment le retrouver et à quoi sert-il ?

Le code dont tu parles est l'empreinte du serveur ssh, ça permet de le reconnaitre, elle est enregistrée quelque part. Sur un système linux, c'est dans un fichier sité dans ~/.ssh et qui s'appelle known_hosts. Dans putty je ne sais pas, mais tu n'auras pas trop de mal à trouver. Si l'empreinte a changé, la connexion est refusée, car cela veut dire que le serveur a pu être compromis.

lors des connexions suivantes on en est à quel niveau de sécurité par rapport à Telnet ?

Ssh encrypte toute la communication, y compris les mots de passe lors de la connexion, il crée un tunnel totalement sécurisé. Donc la sécurité est optimale du point de vue de la confidentialité du transfert. Ssh comprend des mécanismes d'authenfication par clés que ne possède pas telnet.

Mais le service ssh étant exposé côté internet, il faut aussi qu'il soit solide (pas de faille exploitable), comme n'importe quel service. Ce qui est certain, c'est que ssh étant conçu pour être sûr sera vraisemblablement plus "surveillé" au niveau de failles éventuelles que telnet (qui ne doit être utilisé que dans un environnement sûr).

Fais un test avec wireshark pour comprendre !

Existe-t-il un tuto ou une doc permettant de comprendre la mise en oeuvre des différents niveaux :

- accès console

- transferts de fichiers

- ....

Ta question n'est pas claire, tu auras du mal à trouver des réponses...

Des tutos il y en a plein sur internet. Mais pour les trouver, il faut poser les bonnes questions ;)

Que signifie le transfert de fichiers sous SSH par rapport à rsync ? Ce dernier nécessitant l'ouverture du port 873....

rsync est un outil de transfert de fichier qui peut fonctionner en service (port 873) ou utiliser le transport ssh (tunnel ssh sur port 22).

service rsync : port 873

transfert rsync via ssh : port 22.

L'intérêt principal du service rsync est le mode anonyme (transfert sans authentification), ce qui permet de la réplication du même type qu'un ftp, mais avec la puissance de rsync.

Pour un transfert sécurisé, mieux vaux rsync sur ssh (on crée un tunnel ssh dans lequel rsync va faire passer les données)

Lien vers le commentaire
Partager sur d’autres sites

cricx : Merci beaucoup pour tes éclaircissements ! une bible pour débutant ....

Telnet : proscrit en extérieur ....

Empreinte du serveur sous Windows : base de registre clé :

HKEY_CURRENT_USER\Software\SimonTatham\PuTTY" rsa2@22:nom_du_serveur"="

une clé par serveur accédé par l'utilisateur

Test avec Wireshark :

La conversation est bien cryptée.

Tutos selon les utilisations (plutôt que les niveaux) :

- Accès console j'ai vu !

Rsync et SSH :

Les fichiers que je dois transférer entre deux synos aujourd'hui sont des photos, a priori pas besoin de sécuriser.

Toutefois autant prendre le pli de la sécurité, à moins que je ne me trompe il n'y aurait alors que le port 22 à ouvir sur le syno serveur ...

Ou voit-on sur les synos que le rsync va utiliser SSH et pas faire du transfert ordinaire ? Y-a-t-il un moyen de positionner cette option par défaut ?

Le mieux serait-il de rajouter le paramètre --rsh=ssh dans l'ordre de transfert ?

(je débute en rsync)

Merci.

JP

Lien vers le commentaire
Partager sur d’autres sites

cricx : Merci beaucoup pour tes éclaircissements ! une bible pour débutant ....

Telnet : proscrit en extérieur ....

Empreinte du serveur sous Windows : base de registre clé :

HKEY_CURRENT_USER\Software\SimonTatham\PuTTY" rsa2@22:nom_du_serveur"="

une clé par serveur accédé par l'utilisateur

Test avec Wireshark :

La conversation est bien cryptée.

Tutos selon les utilisations (plutôt que les niveaux) :

- Accès console j'ai vu !

Rsync et SSH :

Les fichiers que je dois transférer entre deux synos aujourd'hui sont des photos, a priori pas besoin de sécuriser.

Toutefois autant prendre le pli de la sécurité, à moins que je ne me trompe il n'y aurait alors que le port 22 à ouvir sur le syno serveur ...

Ou voit-on sur les synos que le rsync va utiliser SSH et pas faire du transfert ordinaire ? Y-a-t-il un moyen de positionner cette option par défaut ?

Le mieux serait-il de rajouter le paramètre --rsh=ssh dans l'ordre de transfert ?

(je débute en rsync)

Merci.

JP

la syntaxe est différente pour un rsync sur un service rsync ou via un transport :

rsync user@hostedistant::nomdupartage cheminlocal

pour un service rsync distant (le nom du partage est défini dans le fichiers rsyncd.conf

rsync user@hostdistant:/chemin/vers/les/fichiers cheminlocal

le paramètre --rsh=ssh dit que le transport doit être fait par ssh plutôt que rsh. C'est normalement l'option par défaut.

Lien vers le commentaire
Partager sur d’autres sites

Parfait, je crois que nous ne devrions revenir sur ce topic que si l'aspect sécurité est à compléter, qu'en penses-tu ?

En effet j'avais ouvert un premier topic objet de ma demande initiale :

"Transfert de Fichiers entre deux Synos"

Une des deux solutions apportées m'apparait maintenant utilisable seulement en local...

Cordialement.

JP

Lien vers le commentaire
Partager sur d’autres sites

Parfait, je crois que nous ne devrions revenir sur ce topic que si l'aspect sécurité est à compléter, qu'en penses-tu ?

En effet j'avais ouvert un premier topic objet de ma demande initiale :

"Transfert de Fichiers entre deux Synos"

Une des deux solutions apportées m'apparait maintenant utilisable seulement en local...

Cordialement.

JP

Oui, ce fil parlait de sécurité et dérive sur transfert de fichiers.

Pour les transferts locaux, nfs est utilisable, mais...

je me rends compte, pour n'avoir que des machines linux, dont le syno, qu'il est beaucoup plus simple de n'avoir qu'un seul type de connectivité. J'ai choisi ssh, pour son universalité (du moins en environnement linux, même si winscp et putty sont d'excellents produits pour windows) :

- copie simple avec scp

- transferts intelligents, sauvegarde, mirroir avec rsync sur ssh

- montage d'un système de fichier distant sur ssh (avec fuse)

- conservation des droits

- utilisable en local et à distance

- un seul port à ouvrir

- sûr

Donc ce fil pourrait être clos sur la conclusion suivante : en transfert distant, utiliser ssh ou rsync sur ssh, ou un vpn (mais c'est une autre histoire, quelqu'un devrait faire un tuto, catimini par exemple, ça devrait plaire à + d'un)

Lien vers le commentaire
Partager sur d’autres sites

Bonjour

2 questions :

Comment activer SSH pour RSYNC (port 22 au lieu de 487) ?

Est ce que ça se fait simplement ?

Pourquoi dans les forums et notament celui ci on parle d'ajout de paquet RSYNC et/ou SSH sur le syno alors qu'il supporte déjà ce service ?

Est ce juste pour SSH ?

En gros comment activer SSH pour avoir une sauvegarde sécurisé via RSYNC ?

PS : Ma config : 1 syno en local + 1 syno en distant; le tout avec sauvegardes croisées.

Merci pour votre aide

Lien vers le commentaire
Partager sur d’autres sites

Bonjour

2 questions :

Comment activer SSH pour RSYNC (port 22 au lieu de 487) ?

Est ce que ça se fait simplement ?

Pourquoi dans les forums et notament celui ci on parle d'ajout de paquet RSYNC et/ou SSH sur le syno alors qu'il supporte déjà ce service ?

Est ce juste pour SSH ?

En gros comment activer SSH pour avoir une sauvegarde sécurisé via RSYNC ?

PS : Ma config : 1 syno en local + 1 syno en distant; le tout avec sauvegardes croisées.

Merci pour votre aide

déjà activé... la syntaxe est juste différente.

exemple de rsync entre syno et eeepc :

 rsync -avz syno:/volume1/web/test .

root@syno's password: 

receiving file list ... done

test


sent 42 bytes  received 7409 bytes  709.62 bytes/sec

total size is 54291  speedup is 7.29

tu peux aussi si tu veux forcer ssh (-e ssh) mais c'est déjà activé par défaut. dans l'autre sens (syno vers eeepc) :
 rsync -avz 192.168.1.175:/home/user/temp/* test/

ssh: connect to host 192.168.1.175 port 22: Connection refused

rsync: connection unexpectedly closed (0 bytes received so far) [receiver]

rsync error: rsync service is no running (code 43) at io.c(633) [receiver=3.0.4]

Et oui, ça ne fonctionne pas car sshd ni rsyncd ne tournent sur eeepc. Mais ça fonctionne sur n'importe quel linux avec sshd actif.

Lien vers le commentaire
Partager sur d’autres sites

  • 1 mois après...

Une observation dans le fichier /root/.ssh/known_hosts du syno distant :

Lorque je m'étais connecté initialement avec une adresse IP le serveur distant m'avait enregistré comme tel.

Depuis j'ai mis en place un Dyndns et je suis enregistré aussi avec ce nom suivi de IP courante différente bien entendu de la précédente...

La connection sous adresse IP variable me semble etre une pollution car ajout sans fin dans la liste des serveurs...

Alors comment purger cette pollution ?

Quel risque sécuritaire de laisser en l'état.

JP

Lien vers le commentaire
Partager sur d’autres sites

Une observation dans le fichier /root/.ssh/known_hosts du syno distant :

Lorque je m'étais connecté initialement avec une adresse IP le serveur distant m'avait enregistré comme tel.

Depuis j'ai mis en place un Dyndns et je suis enregistré aussi avec ce nom suivi de IP courante différente bien entendu de la précédente...

La connection sous adresse IP variable me semble etre une pollution car ajout sans fin dans la liste des serveurs...

en français, on écrit connexion

Alors comment purger cette pollution ?

supprimer les entrées correspondantes dans le fichier (au besoin automatiser la suppression des lignes (avec sed, en utilisant comme motif une partie de la clé) ou du fichier, ou encore en remplaçant au début de la ligne l'ancienne ip par la nouvelle (encore avec sed))

Quel risque sécuritaire de laisser en l'état.

pas trop de risque dans la pratique ! ce n'est pas le fichier des clés autorisées !

Lien vers le commentaire
Partager sur d’autres sites

Archivé

Ce sujet est désormais archivé et ne peut plus recevoir de nouvelles réponses.

×
×
  • 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.