J'essaie de configurer FTP sur Amazon Cloud Server, mais sans chance .. Je recherche sur Internet et il n'y a pas d'étapes concrètes à suivre pour le faire.
J'ai trouvé ces commandes à exécuter:
$ yum install vsftpd
$ ec2-authorize default -p 20-21
$ ec2-authorize default -p 1024-1048
$ vi /etc/vsftpd/vsftpd.conf
#<em>---Add following lines at the end of file---</em>
pasv_enable=YES
pasv_min_port=1024
pasv_max_port=1048
pasv_address=<Public IP of your instance>
$ /etc/init.d/vsftpd restart
Mais je ne sais pas où les écrire.
Jaminto a très bien répondu à la question, mais j'ai récemment suivi le processus moi-même et je voulais développer la réponse de Jaminto.
Je suppose que vous avez déjà créé une instance EC2 et que vous y avez associé une adresse IP Elastic.
SSH sur votre serveur EC2. Type:
> Sudo yum install vsftpd
Cela devrait installer vsftpd .
Ensuite, vous devrez ouvrir les ports FTP sur votre serveur EC2. Connectez-vous à la console de gestion AWS EC2 et sélectionnez Groupes de sécurité dans l'arborescence de navigation de gauche. Sélectionnez le groupe de sécurité attribué à votre instance EC2. Ensuite, sélectionnez l'onglet Entrant, puis cliquez sur Modifier:
Ajoutez deux règles TCP personnalisées avec les plages de ports 20-21 et 1024-1048. Pour Source, vous pouvez sélectionner «Partout». Si vous décidez de définir Source sur votre propre adresse IP, sachez que votre adresse IP peut changer si elle est attribuée via DHCP.
Editez votre fichier de configuration vsftpd en tapant:
> Sudo vi /etc/vsftpd/vsftpd.conf
Désactivez le FTP anonyme en modifiant cette ligne:
anonymous_enable=YES
à
anonymous_enable=NO
Ajoutez ensuite les lignes suivantes au bas du fichier vsftpd.conf:
pasv_enable=YES
pasv_min_port=1024
pasv_max_port=1048
pasv_address=<Public IP of your instance>
Votre fichier vsftpd.conf devrait ressembler à quelque chose comme ceci - sauf assurez-vous de remplacer le pasv_address par votre adresse IP publique:
Pour enregistrer les modifications, appuyez sur échappement, puis tapez :wq
, puis appuyez sur entrée.
Redémarrez vsftpd en tapant:
> Sudo /etc/init.d/vsftpd restart
Vous devriez voir un message qui ressemble à:
Si cela ne fonctionne pas, essayez:
> Sudo /sbin/service vsftpd restart
Si vous jetez un coup d’œil à/etc/vsftpd/user_list, vous verrez ce qui suit:
# vsftpd userlist
# If userlist_deny=NO, only allow users in this file
# If userlist_deny=YES (default), never allow users in this file, and
# do not even Prompt for a password.
# Note that the default vsftpd pam config also checks /etc/vsftpd/ftpusers
# for users that are denied.
root
bin
daemon
adm
lp
sync
shutdown
halt
mail
news
uucp
operator
games
nobody
En gros, cela signifie "N'autorisez pas l'accès FTP de ces utilisateurs". vsftpd autorisera l'accès FTP à tout utilisateur ne figurant pas sur cette liste.
Ainsi, pour créer un nouveau compte FTP, vous devrez peut-être créer un nouvel utilisateur sur votre serveur. (Ou, si vous avez déjà un compte d'utilisateur qui ne figure pas dans/etc/vsftpd/user_list, vous pouvez passer à l'étape suivante.)
La création d'un nouvel utilisateur sur une instance EC2 est assez simple. Par exemple, pour créer l'utilisateur 'bret', tapez:
> Sudo adduser bret
> Sudo passwd bret
Voici à quoi cela ressemblera:
À ce stade, vos utilisateurs FTP ne sont pas limités à leurs répertoires de base. Ce n'est pas très sécurisé, mais nous pouvons y remédier assez facilement.
Modifiez à nouveau votre fichier de configuration vsftpd en tapant:
> Sudo vi /etc/vsftpd/vsftpd.conf
Supprimer le commentaire de la ligne:
chroot_local_user=YES
Cela devrait ressembler à ceci une fois que vous avez terminé:
Redémarrez le serveur vsftpd à nouveau comme suit:
> Sudo /etc/init.d/vsftpd restart
Terminé!
vsftpd ne démarre pas automatiquement au démarrage de votre serveur. Si vous êtes comme moi, cela signifie qu'après le redémarrage de votre instance EC2, vous sentirez un moment de terreur lorsque FTP semble être brisé - mais en réalité, il ne fonctionne tout simplement pas!. Voici un moyen pratique de résoudre ce problème:
> Sudo chkconfig --level 345 vsftpd on
Si vous utilisez redhat, vous pouvez également gérer vos services en utilisant cette interface utilisateur graphique astucieuse pour contrôler les services devant démarrer automatiquement:
> Sudo ntsysv
Maintenant, vsftpd se lancera automatiquement au démarrage de votre serveur.
* NOTE: Iman Sedighi a mis en ligne une solution plus élégante pour restreindre l’accès des utilisateurs à un répertoire spécifique. S'il vous plaît se référer à son excellente solution posté comme une réponse *
Vous souhaiterez peut-être créer un utilisateur et restreindre son accès FTP à un dossier spécifique, tel que/var/www. Pour ce faire, vous devrez modifier le répertoire de base par défaut de l'utilisateur:
> Sudo usermod -d /var/www/ username
Dans cet exemple spécifique, il est typique d'accorder à l'utilisateur des autorisations sur le groupe 'www', souvent associé au dossier/var/www:
> Sudo usermod -a -G www username
Pour activer le protocole FTP passif sur un serveur EC2, vous devez configurer les ports que votre serveur FTP doit utiliser pour les connexions entrantes, puis ouvrir une liste des ports disponibles pour les connexions de données client FTP.
Je ne connais pas très bien Linux, mais les commandes que vous avez publiées sont les étapes pour installer le serveur FTP, configurer les règles de pare-feu ec2 (via l'API AWS), puis configurer le serveur FTP pour utiliser les ports que vous avez autorisés sur le pare-feu ec2 .
Donc, cette étape installe le client ftp (VSFTP)
> yum install vsftpd
Ces étapes configurent le client ftp
> vi /etc/vsftpd/vsftpd.conf
-- Add following lines at the end of file --
pasv_enable=YES
pasv_min_port=1024
pasv_max_port=1048
pasv_address=<Public IP of your instance>
> /etc/init.d/vsftpd restart
mais les deux autres étapes sont plus faciles à effectuer via la console Amazon sous les groupes de sécurité EC2. Là, vous devez configurer le groupe de sécurité affecté à votre serveur pour permettre les connexions sur les ports 20,21 et 1024-1048.
Merci @ clone45 pour la solution Nice. Mais je n’avais qu’un seul problème important avec l’annexe b de sa solution. Immédiatement après avoir changé le répertoire de base en var/www/html, je ne pouvais pas me connecter au serveur via ssh et sftp car il affiche toujours les erreurs suivantes.
permission denied (public key)
ou dans FileZilla j'ai reçu cette erreur:
No supported authentication methods available (server: public key)
Mais je pouvais accéder au serveur via une connexion FTP normale.
Si vous rencontrez la même erreur, annulez simplement l'annexe b de la solution @ clone45 en définissant le répertoire de base par défaut pour l'utilisateur:
Sudo usermod -d /home/username/ username
Mais lorsque vous définissez le répertoire de base par défaut de l'utilisateur, celui-ci a accès à de nombreux autres dossiers en dehors de/var/www/http. Pour sécuriser votre serveur, procédez comme suit:
1- Créer un groupe sftponly Créez un groupe pour tous les utilisateurs pour lesquels vous souhaitez limiter leur accès aux seuls accès ftp et sftp à var/www/html. faire le groupe:
Sudo groupadd sftponly
2- Jail the chroot .__ Pour restreindre l’accès de ce groupe au serveur via sftp, vous devez emprisonner le chroot afin de ne pas permettre aux utilisateurs du groupe d’accéder aux dossiers autres que le dossier html de son répertoire personnel. Pour ce faire, ouvrez /etc/ssh/sshd.config dans vim avec Sudo . À la fin du fichier, veuillez commenter cette ligne:
Subsystem sftp /usr/libexec/openssh/sftp-server
Et puis ajoutez cette ligne ci-dessous:
Subsystem sftp internal-sftp
Nous avons donc remplacé le sous-système par internal-sftp. Puis ajoutez les lignes suivantes en dessous:
Match Group sftponly
ChrootDirectory /var/www
ForceCommand internal-sftp
AllowTcpForwarding no
Après avoir ajouté cette ligne, j’ai sauvegardé mes modifications puis redémarré le service ssh en:
Sudo service sshd restart
3- Ajouter l'utilisateur au groupe sftponly Tout utilisateur que vous souhaitez restreindre leur accès doit être membre du groupe sftponly. Par conséquent, nous le rejoignons ensuite: Sudo usermod -G sftponly nom d'utilisateur
4- Limiter l’accès des utilisateurs uniquement à var/www/html Pour restreindre l’accès des utilisateurs uniquement au dossier var/www/html, nous devons créer un répertoire dans le répertoire de base (avec le nom 'html') de cet utilisateur, puis montez/var/www dans/home/nom d'utilisateur/html comme suit:
Sudo mkdir /home/username/html
Sudo mount --bind /var/www /home/username/html
5- Définir l'accès en écriture Si l'utilisateur a besoin d'un accès en écriture à/var/www/html, vous devez l'envoyer en prison sur/var/www, qui doit posséder les droits root: root et 755. Vous puis besoin de donner/var/www/html la propriété de root: sftponly et les permissions de 775 en ajoutant les lignes suivantes:
Sudo chmod 755 /var/www
Sudo chown root:root /var/www
Sudo chmod 775 /var/www/html
Sudo chown root:www /var/www/html
6- Bloquer l'accès au shell Si vous souhaitez limiter l'accès au Shell sans le rendre plus sécurisé, changez simplement le Shell par défaut en bin/false comme suit:
Sudo usermod -s /bin/false username
Excellent article ... a fonctionné comme un jeu d'enfant sur Amazon Linux AMI.
Deux autres commandes utiles:
Pour changer le dossier de téléchargement FTP par défaut
Étape 1:
edit /etc/vsftpd/vsftpd.conf
Étape 2: Créez une nouvelle entrée au bas de la page:
local_root=/var/www/html
Pour appliquer une autorisation de lecture, d'écriture, de suppression sur les fichiers du dossier afin que vous puissiez gérer à l'aide d'un périphérique FTP
find /var/www/html -type d -exec chmod 777 {} \;
Si vous avez activé ufw, n'oubliez pas d'ajouter ftp:
> Sudo ufw allow ftp
Il m'a fallu 2 jours pour réaliser que j'avais activé ufw.
Cela ne sera pas correct tant que vous n'aurez pas ajouté votre utilisateur au groupe www à l'aide des commandes suivantes:
Sudo usermod -a -G www <USER>
Cela résout le problème de permission.
Définissez le chemin par défaut en ajoutant ceci:
local_root=/var/www/html
N'oubliez pas de mettre à jour votre pare-feu iptables si vous en avez un pour autoriser les gammes 20-21 et 1024-1048.
Faites cela depuis/etc/sysconfig/iptables
Ajouter des lignes comme ceci:
-A INPUT -m state --state NEW -m tcp -p tcp --dport 20:21 -j ACCEPTER
-A INPUT -m state --state NEW -m tcp -p tcp --port 1024: 1048 -j ACCEPT
Et redémarrez iptables avec la commande:
Sudo service iptables redémarrer
J'ai simplifié les étapes clone45:
Ouvrez les ports comme il l'a mentionné
Sudo su
Sudo yum install vsftpd
echo -n "Public IP of your instance: " && read publicip
echo -e "anonymous_enable=NO\npasv_enable=YES\npasv_min_port=1024\npasv_max_port=1048\npasv_address=$publicip\nchroot_local_user=YES" >> /etc/vsftpd/vsftpd.conf
Sudo /etc/init.d/vsftpd restart
J'ai suivi la réponse de clone45 jusqu'à la fin. Un excellent article! Comme j'avais besoin d'un accès FTP pour installer des plug-ins sur l'un de mes sites wordpress, j'ai changé le répertoire de base en/var/www/mysitename. Ensuite, j'ai continué à ajouter mon utilisateur FTP au groupe Apache (ou www) comme ceci:
Sudo usermod -a -G Apache myftpuser
Après cela, j'ai encore vu cette erreur sur la page d'installation du plug-in de WP: "Impossible de localiser le répertoire de contenu WordPress (wp-content)". Vous avez recherché et trouvé cette solution lors d'une session de questions/réponses de wp.org: https://wordpress.org/support/topic/unable-to-locate-wordpress-content-directory-wp-content et a ajouté le texte suivant fin de wp-config.php:
if(is_admin()) {
add_filter('filesystem_method', create_function('$a', 'return "direct";' ));
define( 'FS_CHMOD_DIR', 0751 );
}
Après cela, mon plugin WP a été installé avec succès.
Si le mot de passe 530 est incorrect
1 étape supplémentaire nécessaire
dans le fichier/etc/shells
Ajouter la ligne suivante
/ bin/false
peut-être mérite-t-il d'être mentionné en plus de la réponse de clone45 :
Correction des autorisations d'écriture pour les utilisateurs FTP chrootés dans vsftpd
La version de vsftpd fournie avec Ubuntu 12.04 Precise n’est pas permet aux utilisateurs locaux chrootés d'écrire par défaut. Par défaut, vous aurez avoir ceci dans /etc/vsftpd.conf:
chroot_local_user=YES write_enable=YES
Afin de permettre aux utilisateurs locaux d'écrire, vous devez ajouter le paramètre suivant:
allow_writeable_chroot=YES
Remarque: Les problèmes d'autorisations en écriture peuvent se présenter comme suit: les erreurs FileZilla:
Error: GnuTLS error -15: An unexpected TLS packet was received.
Error: Could not connect to server
Références:
Correction des autorisations d’écriture pour les utilisateurs FTP en mode chrooté dans vsftpd
VSFTPd a cessé de fonctionner après la mise à jour