Bonjour les gens,
J'utilise un petit utilitaire appelé ftp-upload qui permet depuis la
ligne de commande d'uploader un fichier sur un serveur ftp.
Ça marche très bien, pas de souci.
Je cherche à utiliser ftps à la place de ftp pour le même besoin et de
la même manière (dans un script et avec un un serveur ftp avec TLS). Une
idée de l'outil qui permettrait de faire ça, svp ?
Bonjour les gens,
J'utilise un petit utilitaire appelé ftp-upload qui permet depuis la
ligne de commande d'uploader un fichier sur un serveur ftp.
Ça marche très bien, pas de souci.
Je cherche à utiliser ftps à la place de ftp pour le même besoin et de
la même manière (dans un script et avec un un serveur ftp avec TLS). Une
idée de l'outil qui permettrait de faire ça, svp ?
Bonjour les gens,
J'utilise un petit utilitaire appelé ftp-upload qui permet depuis la
ligne de commande d'uploader un fichier sur un serveur ftp.
Ça marche très bien, pas de souci.
Je cherche à utiliser ftps à la place de ftp pour le même besoin et de
la même manière (dans un script et avec un un serveur ftp avec TLS). Une
idée de l'outil qui permettrait de faire ça, svp ?
Bonjour les gens,
J'utilise un petit utilitaire appelé ftp-upload qui permet depuis la
ligne de commande d'uploader un fichier sur un serveur ftp.
Ça marche très bien, pas de souci.
Je cherche à utiliser ftps à la place de ftp pour le même besoin et de
la même manière (dans un script et avec un un serveur ftp avec TLS). Une
idée de l'outil qui permettrait de faire ça, svp ?
Bonjour les gens,
J'utilise un petit utilitaire appelé ftp-upload qui permet depuis la
ligne de commande d'uploader un fichier sur un serveur ftp.
Ça marche très bien, pas de souci.
Je cherche à utiliser ftps à la place de ftp pour le même besoin et de
la même manière (dans un script et avec un un serveur ftp avec TLS). Une
idée de l'outil qui permettrait de faire ça, svp ?
Bonjour les gens,
J'utilise un petit utilitaire appelé ftp-upload qui permet depuis la
ligne de commande d'uploader un fichier sur un serveur ftp.
Ça marche très bien, pas de souci.
Je cherche à utiliser ftps à la place de ftp pour le même besoin et de
la même manière (dans un script et avec un un serveur ftp avec TLS). Une
idée de l'outil qui permettrait de faire ça, svp ?
curl supporte à peu près tous les protocoles
curl supporte à peu près tous les protocoles
curl supporte à peu près tous les protocoles
Effectivement. J'étais un peu réticent, mais ça le fait très bien :
$ /usr/bin/curl --silent --ssl --upload-file file_to_upload.txt
ftp://user:
sftp, par contre, utilise le serveur ssh, pas le serveur ftp. Ça marche,
mais c'est une autre config que la mienne (cf. la réponse de Jean-Paul).
A moins que j'ai loupé un truc.
Effectivement. J'étais un peu réticent, mais ça le fait très bien :
$ /usr/bin/curl --silent --ssl --upload-file file_to_upload.txt
ftp://user:pass@host
sftp, par contre, utilise le serveur ssh, pas le serveur ftp. Ça marche,
mais c'est une autre config que la mienne (cf. la réponse de Jean-Paul).
A moins que j'ai loupé un truc.
Effectivement. J'étais un peu réticent, mais ça le fait très bien :
$ /usr/bin/curl --silent --ssl --upload-file file_to_upload.txt
ftp://user:
sftp, par contre, utilise le serveur ssh, pas le serveur ftp. Ça marche,
mais c'est une autre config que la mienne (cf. la réponse de Jean-Paul).
A moins que j'ai loupé un truc.
Effectivement. J'étais un peu réticent, mais ça le fait très bien :
$ /usr/bin/curl --silent --ssl --upload-file file_to_upload.txt
ftp://user:
sftp, par contre, utilise le serveur ssh, pas le serveur ftp. Ça
marche,
mais c'est une autre config que la mienne (cf. la réponse de Jean-
Paul).
A moins que j'ai loupé un truc.
Merci.
Le 06/09/2017 à 15:51, Dominique Asselineau a écrit :curl supporte à peu près tous les protocoles
Effectivement. J'étais un peu réticent, mais ça le fait très bien :
$ /usr/bin/curl --silent --ssl --upload-file file_to_upload.txt
ftp://user:pass@host
sftp, par contre, utilise le serveur ssh, pas le serveur ftp. Ça
marche,
mais c'est une autre config que la mienne (cf. la réponse de Jean-
Paul).
A moins que j'ai loupé un truc.
Merci.
Le 06/09/2017 à 15:51, Dominique Asselineau a écrit :
> curl supporte à peu près tous les protocoles
Effectivement. J'étais un peu réticent, mais ça le fait très bien :
$ /usr/bin/curl --silent --ssl --upload-file file_to_upload.txt
ftp://user:
sftp, par contre, utilise le serveur ssh, pas le serveur ftp. Ça
marche,
mais c'est une autre config que la mienne (cf. la réponse de Jean-
Paul).
A moins que j'ai loupé un truc.
Merci.
Le 06/09/2017 à 15:51, Dominique Asselineau a écrit :curl supporte à peu près tous les protocoles
Salut,
Le 06/09/2017 à 16:44, Thierry Bugier a écrit :SFTP est pour l'envoi de fichier par serveur SSH, FTPS est pour l'envoi
de fichiers avec un serveur FTP prenant en charge SSL/TLS. FTP(S)
requiert l'ouverture d'au moins 2 ports: 22 pour le canal de commandes
et 1 port ou une plage de ports pour le transfert de fichiers.
FTPS, oui c'est le transfert entre un client FTP et un serveur FTP. Le S
pour la version sécurisée par chiffrement
Port 21 selon la convention, mais on peut le changer. C'est par ici que
le client viendra "causer" au serveur.
Puis le serveur proposera une fourchette de port (passif) pour le
transfert de fichiers.Il faut aussi configurer le mode passif ou actif sur les passerelles du client,
et du serveur...
Uniquement du coté serveur. Le client reçoit automatiquement les infos à
propos des ports passifs à utiliser ;)
Parfois dans un client graphique comme Filezilla, c'est mieux de lui
annoncer qu'il s'agit d'un serveur explicit (avec ports passifs).Bref, un vrai bazar, sans compter que la transmission des identifiants peut encore se faire en clair avant le basculement en mode chiffré.
A mon avis c'est l'inverse. Il y a échange de clés dans un premier,
rendant la connexion chiffrée, et une fois que le client a accepté, hop
le client envoie l'identifiant + pass au serveur, le tout entant chiffré.Du coup j'ai estimé il y a pas mal d'années que FTP est un protocole
obsolète et quelques lectures que j'ai pu avoir vont dans ce sens. SFTP
est bien plus facile à mettre en oeuvre et est plus sûr.
Le FTP c'est vieux comme les rues,
c'est dans les vieux pots.... ;)
Et en plus si c'est chiffré comme il faut, c'est pénard ;)
Petit bouquinage rapide du soir : https://fr.wikipedia.org/wiki/FTPS
Je pense ne pas avoir raconté de bêtises, si un "sage" peut confirmer ;)
Salut,
Le 06/09/2017 à 16:44, Thierry Bugier a écrit :
SFTP est pour l'envoi de fichier par serveur SSH, FTPS est pour l'envoi
de fichiers avec un serveur FTP prenant en charge SSL/TLS. FTP(S)
requiert l'ouverture d'au moins 2 ports: 22 pour le canal de commandes
et 1 port ou une plage de ports pour le transfert de fichiers.
FTPS, oui c'est le transfert entre un client FTP et un serveur FTP. Le S
pour la version sécurisée par chiffrement
Port 21 selon la convention, mais on peut le changer. C'est par ici que
le client viendra "causer" au serveur.
Puis le serveur proposera une fourchette de port (passif) pour le
transfert de fichiers.
Il faut aussi configurer le mode passif ou actif sur les passerelles du client,
et du serveur...
Uniquement du coté serveur. Le client reçoit automatiquement les infos à
propos des ports passifs à utiliser ;)
Parfois dans un client graphique comme Filezilla, c'est mieux de lui
annoncer qu'il s'agit d'un serveur explicit (avec ports passifs).
Bref, un vrai bazar, sans compter que la transmission des identifiants peut encore se faire en clair avant le basculement en mode chiffré.
A mon avis c'est l'inverse. Il y a échange de clés dans un premier,
rendant la connexion chiffrée, et une fois que le client a accepté, hop
le client envoie l'identifiant + pass au serveur, le tout entant chiffré.
Du coup j'ai estimé il y a pas mal d'années que FTP est un protocole
obsolète et quelques lectures que j'ai pu avoir vont dans ce sens. SFTP
est bien plus facile à mettre en oeuvre et est plus sûr.
Le FTP c'est vieux comme les rues,
c'est dans les vieux pots.... ;)
Et en plus si c'est chiffré comme il faut, c'est pénard ;)
Petit bouquinage rapide du soir : https://fr.wikipedia.org/wiki/FTPS
Je pense ne pas avoir raconté de bêtises, si un "sage" peut confirmer ;)
Salut,
Le 06/09/2017 à 16:44, Thierry Bugier a écrit :SFTP est pour l'envoi de fichier par serveur SSH, FTPS est pour l'envoi
de fichiers avec un serveur FTP prenant en charge SSL/TLS. FTP(S)
requiert l'ouverture d'au moins 2 ports: 22 pour le canal de commandes
et 1 port ou une plage de ports pour le transfert de fichiers.
FTPS, oui c'est le transfert entre un client FTP et un serveur FTP. Le S
pour la version sécurisée par chiffrement
Port 21 selon la convention, mais on peut le changer. C'est par ici que
le client viendra "causer" au serveur.
Puis le serveur proposera une fourchette de port (passif) pour le
transfert de fichiers.Il faut aussi configurer le mode passif ou actif sur les passerelles du client,
et du serveur...
Uniquement du coté serveur. Le client reçoit automatiquement les infos à
propos des ports passifs à utiliser ;)
Parfois dans un client graphique comme Filezilla, c'est mieux de lui
annoncer qu'il s'agit d'un serveur explicit (avec ports passifs).Bref, un vrai bazar, sans compter que la transmission des identifiants peut encore se faire en clair avant le basculement en mode chiffré.
A mon avis c'est l'inverse. Il y a échange de clés dans un premier,
rendant la connexion chiffrée, et une fois que le client a accepté, hop
le client envoie l'identifiant + pass au serveur, le tout entant chiffré.Du coup j'ai estimé il y a pas mal d'années que FTP est un protocole
obsolète et quelques lectures que j'ai pu avoir vont dans ce sens. SFTP
est bien plus facile à mettre en oeuvre et est plus sûr.
Le FTP c'est vieux comme les rues,
c'est dans les vieux pots.... ;)
Et en plus si c'est chiffré comme il faut, c'est pénard ;)
Petit bouquinage rapide du soir : https://fr.wikipedia.org/wiki/FTPS
Je pense ne pas avoir raconté de bêtises, si un "sage" peut confirmer ;)
Salut,
Le 06/09/2017 à 16:44, Thierry Bugier a écrit :SFTP est pour l'envoi de fichier par serveur SSH, FTPS est pour
l'envoi
de fichiers avec un serveur FTP prenant en charge SSL/TLS. FTP(S)
requiert l'ouverture d'au moins 2 ports: 22 pour le canal de
commandes
et 1 port ou une plage de ports pour le transfert de fichiers.
FTPS, oui c'est le transfert entre un client FTP et un serveur FTP.
Le S
pour la version sécurisée par chiffrement
Port 21 selon la convention, mais on peut le changer. C'est par ici
que
le client viendra "causer" au serveur.
Puis le serveur proposera une fourchette de port (passif) pour le
transfert de fichiers.Il faut aussi configurer le mode passif ou actif sur les
passerelles du client,
et du serveur...
Uniquement du coté serveur. Le client reçoit automatiquement les
infos à
propos des ports passifs à utiliser ;)
Parfois dans un client graphique comme Filezilla, c'est mieux de lui
annoncer qu'il s'agit d'un serveur explicit (avec ports passifs).Bref, un vrai bazar, sans compter que la transmission des
identifiants peut encore se faire en clair avant le basculement en
mode chiffré.
A mon avis c'est l'inverse. Il y a échange de clés dans un premier,
rendant la connexion chiffrée, et une fois que le client a accepté,
hop
le client envoie l'identifiant + pass au serveur, le tout entant
chiffré.
Du coup j'ai estimé il y a pas mal d'années que FTP est un
protocole
obsolète et quelques lectures que j'ai pu avoir vont dans ce sens.
SFTP
est bien plus facile à mettre en oeuvre et est plus sûr.
Le FTP c'est vieux comme les rues,
c'est dans les vieux pots.... ;)
Et en plus si c'est chiffré comme il faut, c'est pénard ;)
Petit bouquinage rapide du soir : https://fr.wikipedia.org/wiki/FTPS
Je pense ne pas avoir raconté de bêtises, si un "sage" peut confirmer
;)
Salut,
Le 06/09/2017 à 16:44, Thierry Bugier a écrit :
> SFTP est pour l'envoi de fichier par serveur SSH, FTPS est pour
> l'envoi
> de fichiers avec un serveur FTP prenant en charge SSL/TLS. FTP(S)
> requiert l'ouverture d'au moins 2 ports: 22 pour le canal de
> commandes
> et 1 port ou une plage de ports pour le transfert de fichiers.
FTPS, oui c'est le transfert entre un client FTP et un serveur FTP.
Le S
pour la version sécurisée par chiffrement
Port 21 selon la convention, mais on peut le changer. C'est par ici
que
le client viendra "causer" au serveur.
Puis le serveur proposera une fourchette de port (passif) pour le
transfert de fichiers.
> Il faut aussi configurer le mode passif ou actif sur les
> passerelles du client,
> et du serveur...
Uniquement du coté serveur. Le client reçoit automatiquement les
infos à
propos des ports passifs à utiliser ;)
Parfois dans un client graphique comme Filezilla, c'est mieux de lui
annoncer qu'il s'agit d'un serveur explicit (avec ports passifs).
> Bref, un vrai bazar, sans compter que la transmission des
> identifiants peut encore se faire en clair avant le basculement en
> mode chiffré.
A mon avis c'est l'inverse. Il y a échange de clés dans un premier,
rendant la connexion chiffrée, et une fois que le client a accepté,
hop
le client envoie l'identifiant + pass au serveur, le tout entant
chiffré.
> Du coup j'ai estimé il y a pas mal d'années que FTP est un
> protocole
> obsolète et quelques lectures que j'ai pu avoir vont dans ce sens.
> SFTP
> est bien plus facile à mettre en oeuvre et est plus sûr.
Le FTP c'est vieux comme les rues,
c'est dans les vieux pots.... ;)
Et en plus si c'est chiffré comme il faut, c'est pénard ;)
Petit bouquinage rapide du soir : https://fr.wikipedia.org/wiki/FTPS
Je pense ne pas avoir raconté de bêtises, si un "sage" peut confirmer
;)
Salut,
Le 06/09/2017 à 16:44, Thierry Bugier a écrit :SFTP est pour l'envoi de fichier par serveur SSH, FTPS est pour
l'envoi
de fichiers avec un serveur FTP prenant en charge SSL/TLS. FTP(S)
requiert l'ouverture d'au moins 2 ports: 22 pour le canal de
commandes
et 1 port ou une plage de ports pour le transfert de fichiers.
FTPS, oui c'est le transfert entre un client FTP et un serveur FTP.
Le S
pour la version sécurisée par chiffrement
Port 21 selon la convention, mais on peut le changer. C'est par ici
que
le client viendra "causer" au serveur.
Puis le serveur proposera une fourchette de port (passif) pour le
transfert de fichiers.Il faut aussi configurer le mode passif ou actif sur les
passerelles du client,
et du serveur...
Uniquement du coté serveur. Le client reçoit automatiquement les
infos à
propos des ports passifs à utiliser ;)
Parfois dans un client graphique comme Filezilla, c'est mieux de lui
annoncer qu'il s'agit d'un serveur explicit (avec ports passifs).Bref, un vrai bazar, sans compter que la transmission des
identifiants peut encore se faire en clair avant le basculement en
mode chiffré.
A mon avis c'est l'inverse. Il y a échange de clés dans un premier,
rendant la connexion chiffrée, et une fois que le client a accepté,
hop
le client envoie l'identifiant + pass au serveur, le tout entant
chiffré.
Du coup j'ai estimé il y a pas mal d'années que FTP est un
protocole
obsolète et quelques lectures que j'ai pu avoir vont dans ce sens.
SFTP
est bien plus facile à mettre en oeuvre et est plus sûr.
Le FTP c'est vieux comme les rues,
c'est dans les vieux pots.... ;)
Et en plus si c'est chiffré comme il faut, c'est pénard ;)
Petit bouquinage rapide du soir : https://fr.wikipedia.org/wiki/FTPS
Je pense ne pas avoir raconté de bêtises, si un "sage" peut confirmer
;)
Port 21 selon la convention, mais on peut le changer.
Puis le serveur proposera une fourchette de port (passif) pour le
transfert de fichiers.
Il faut aussi configurer le mode passif ou actif sur les passerelles du client,
et du serveur...
Uniquement du coté serveur.
Le client reçoit automatiquement les infos à
propos des ports passifs à utiliser ;)
Port 21 selon la convention, mais on peut le changer.
Puis le serveur proposera une fourchette de port (passif) pour le
transfert de fichiers.
Il faut aussi configurer le mode passif ou actif sur les passerelles du client,
et du serveur...
Uniquement du coté serveur.
Le client reçoit automatiquement les infos à
propos des ports passifs à utiliser ;)
Port 21 selon la convention, mais on peut le changer.
Puis le serveur proposera une fourchette de port (passif) pour le
transfert de fichiers.
Il faut aussi configurer le mode passif ou actif sur les passerelles du client,
et du serveur...
Uniquement du coté serveur.
Le client reçoit automatiquement les infos à
propos des ports passifs à utiliser ;)
Le 06/09/2017 à 22:06, Thierry Bugier a écrit :Et si on est en mode SSL explicite c'est au client de réclamer un
basculement en SSL. du coup si le client ne la réclame pas et
envoie
des identifiants, ils seront envoyés en clair. Même si le serveur
les
rejette car la communication n'est pas chiffrée, des identifiant
(potentiellement VALIDES) auront transité en clair.
Il apparaît pourtant possible de configurer le serveur FTP pour qu'il
rejette systématiquement les connexions non chiffrées...
Le login/pass et tout le reste passera en chiffré automatiquement,
sur
la demande du serveur. Je pense qu'il s'agit de la config par défaut
?
Chez proftpd (désolé pour l'anglais :s)
http://www.proftpd.org/docs/howto/TLS.html :
Question: Does FTPS protect both the control connection *and* the
data
connections?
Question: Short answer: yes.
The long answer is, of course, that it depends. In the case ofmod_tls|, it depends on your |TLSRequired| setting. If you use:
TLSRequired on
then you are configuring |mod_tls| to *require* SSL/TLS protection
for
both control connections (/e.g./ protecting the username and password
used to log in) /and/ data connections. If you have:
TLSRequired off
then it is up to the FTPS client whether both control and data
connections will be protected via SSL/TLS. Other |TLSRequired|
settings
can be used to specify specific combinations: data connections only,
control connections only, authentication plus data data connections
only, /etc/. The |TLSRequired| documentation
<http://www.proftpd.org/contrib/mod_tls.html#TLSRequired> has the
details.
(dommage, erreur 404 pour le lien vers la doc°)Je ne dis pas le contraire, mais ssh est si facile à mettre en
oeuvre
et sans risque majeur d'erreur !
apt install openssh-server et hop ! (après les paranos iront
désactiver
le port forwarding et autres joyeusetés)
Justement j'essaie de temps en temps à heure perdue de comprendre
comment ces histoires d’échanges de clés entre serveurs fonctionnent,
j'ai rien capté ! Je pense utiliser rsync via SSH, avec tâches cron
derrière qui gèrent l'automatisme du truc... Où trouver ces clés, où
les
installer pour que ca fonctionne sans les mots de passe, comment bien
configurer le serveur ssh (et les clients) pour un max de sécurité
(virer "root" me parait la base car j'aime pas beaucoup savoir que
mon
serveur pourra être administrable par n'importe qui via internet,
éviter
que les autres comptes utilisateurs puissent fouiner dans tout le
système... etc...). Mais là c'est un autre sujet ;))) (apparemment
assez touffu !)
Le 06/09/2017 à 22:06, Thierry Bugier a écrit :
> Et si on est en mode SSL explicite c'est au client de réclamer un
> basculement en SSL. du coup si le client ne la réclame pas et
> envoie
> des identifiants, ils seront envoyés en clair. Même si le serveur
> les
> rejette car la communication n'est pas chiffrée, des identifiant
> (potentiellement VALIDES) auront transité en clair.
Il apparaît pourtant possible de configurer le serveur FTP pour qu'il
rejette systématiquement les connexions non chiffrées...
Le login/pass et tout le reste passera en chiffré automatiquement,
sur
la demande du serveur. Je pense qu'il s'agit de la config par défaut
?
Chez proftpd (désolé pour l'anglais :s)
http://www.proftpd.org/docs/howto/TLS.html :
Question: Does FTPS protect both the control connection *and* the
data
connections?
Question: Short answer: yes.
The long answer is, of course, that it depends. In the case of
> mod_tls|, it depends on your |TLSRequired| setting. If you use:
TLSRequired on
then you are configuring |mod_tls| to *require* SSL/TLS protection
for
both control connections (/e.g./ protecting the username and password
used to log in) /and/ data connections. If you have:
TLSRequired off
then it is up to the FTPS client whether both control and data
connections will be protected via SSL/TLS. Other |TLSRequired|
settings
can be used to specify specific combinations: data connections only,
control connections only, authentication plus data data connections
only, /etc/. The |TLSRequired| documentation
<http://www.proftpd.org/contrib/mod_tls.html#TLSRequired> has the
details.
(dommage, erreur 404 pour le lien vers la doc°)
> Je ne dis pas le contraire, mais ssh est si facile à mettre en
> oeuvre
> et sans risque majeur d'erreur !
>
> apt install openssh-server et hop ! (après les paranos iront
> désactiver
> le port forwarding et autres joyeusetés)
Justement j'essaie de temps en temps à heure perdue de comprendre
comment ces histoires d’échanges de clés entre serveurs fonctionnent,
j'ai rien capté ! Je pense utiliser rsync via SSH, avec tâches cron
derrière qui gèrent l'automatisme du truc... Où trouver ces clés, où
les
installer pour que ca fonctionne sans les mots de passe, comment bien
configurer le serveur ssh (et les clients) pour un max de sécurité
(virer "root" me parait la base car j'aime pas beaucoup savoir que
mon
serveur pourra être administrable par n'importe qui via internet,
éviter
que les autres comptes utilisateurs puissent fouiner dans tout le
système... etc...). Mais là c'est un autre sujet ;))) (apparemment
assez touffu !)
Le 06/09/2017 à 22:06, Thierry Bugier a écrit :Et si on est en mode SSL explicite c'est au client de réclamer un
basculement en SSL. du coup si le client ne la réclame pas et
envoie
des identifiants, ils seront envoyés en clair. Même si le serveur
les
rejette car la communication n'est pas chiffrée, des identifiant
(potentiellement VALIDES) auront transité en clair.
Il apparaît pourtant possible de configurer le serveur FTP pour qu'il
rejette systématiquement les connexions non chiffrées...
Le login/pass et tout le reste passera en chiffré automatiquement,
sur
la demande du serveur. Je pense qu'il s'agit de la config par défaut
?
Chez proftpd (désolé pour l'anglais :s)
http://www.proftpd.org/docs/howto/TLS.html :
Question: Does FTPS protect both the control connection *and* the
data
connections?
Question: Short answer: yes.
The long answer is, of course, that it depends. In the case ofmod_tls|, it depends on your |TLSRequired| setting. If you use:
TLSRequired on
then you are configuring |mod_tls| to *require* SSL/TLS protection
for
both control connections (/e.g./ protecting the username and password
used to log in) /and/ data connections. If you have:
TLSRequired off
then it is up to the FTPS client whether both control and data
connections will be protected via SSL/TLS. Other |TLSRequired|
settings
can be used to specify specific combinations: data connections only,
control connections only, authentication plus data data connections
only, /etc/. The |TLSRequired| documentation
<http://www.proftpd.org/contrib/mod_tls.html#TLSRequired> has the
details.
(dommage, erreur 404 pour le lien vers la doc°)Je ne dis pas le contraire, mais ssh est si facile à mettre en
oeuvre
et sans risque majeur d'erreur !
apt install openssh-server et hop ! (après les paranos iront
désactiver
le port forwarding et autres joyeusetés)
Justement j'essaie de temps en temps à heure perdue de comprendre
comment ces histoires d’échanges de clés entre serveurs fonctionnent,
j'ai rien capté ! Je pense utiliser rsync via SSH, avec tâches cron
derrière qui gèrent l'automatisme du truc... Où trouver ces clés, où
les
installer pour que ca fonctionne sans les mots de passe, comment bien
configurer le serveur ssh (et les clients) pour un max de sécurité
(virer "root" me parait la base car j'aime pas beaucoup savoir que
mon
serveur pourra être administrable par n'importe qui via internet,
éviter
que les autres comptes utilisateurs puissent fouiner dans tout le
système... etc...). Mais là c'est un autre sujet ;))) (apparemment
assez touffu !)
Bonjour
La versions stable actuelle de debian désactive par défaut le compte
root. Même si on si on met les bons identifiants, la phase
d'authentification échouera (paramètre PermitRootLogin). Par contre il
doit être possible de s'authentifier avec une clé.
J'ai quelques notes à propos de la génération d'une pair e de clés et
l'installation de la clé publique sur un serveur.
https://howto-it.dethegeek.eu.org/index.php?title=Authentification_ss h_
sans_mot_de_passe
J'ai aussi repris un billet de blog intéressant sur la sécuri sation de
ssh
https://howto-it.dethegeek.eu.org/index.php?title=Openssh_-_Restreind re
_les_fonctionnalit%C3%A9s_de_tunnel
et j'ai une brève note / brouillon sur quelques configurations de
sécurité
https://howto-it.dethegeek.eu.org/index.php?title=S%C3%A9curiser_linu x
Bonjour
La versions stable actuelle de debian désactive par défaut le compte
root. Même si on si on met les bons identifiants, la phase
d'authentification échouera (paramètre PermitRootLogin). Par contre il
doit être possible de s'authentifier avec une clé.
J'ai quelques notes à propos de la génération d'une pair e de clés et
l'installation de la clé publique sur un serveur.
https://howto-it.dethegeek.eu.org/index.php?title=Authentification_ss h_
sans_mot_de_passe
J'ai aussi repris un billet de blog intéressant sur la sécuri sation de
ssh
https://howto-it.dethegeek.eu.org/index.php?title=Openssh_-_Restreind re
_les_fonctionnalit%C3%A9s_de_tunnel
et j'ai une brève note / brouillon sur quelques configurations de
sécurité
https://howto-it.dethegeek.eu.org/index.php?title=S%C3%A9curiser_linu x
Bonjour
La versions stable actuelle de debian désactive par défaut le compte
root. Même si on si on met les bons identifiants, la phase
d'authentification échouera (paramètre PermitRootLogin). Par contre il
doit être possible de s'authentifier avec une clé.
J'ai quelques notes à propos de la génération d'une pair e de clés et
l'installation de la clé publique sur un serveur.
https://howto-it.dethegeek.eu.org/index.php?title=Authentification_ss h_
sans_mot_de_passe
J'ai aussi repris un billet de blog intéressant sur la sécuri sation de
ssh
https://howto-it.dethegeek.eu.org/index.php?title=Openssh_-_Restreind re
_les_fonctionnalit%C3%A9s_de_tunnel
et j'ai une brève note / brouillon sur quelques configurations de
sécurité
https://howto-it.dethegeek.eu.org/index.php?title=S%C3%A9curiser_linu x