Configuré dos nuevos cuadros CentOS 7 simultáneamente, por lo que las configuraciones deberían ser idénticas, solo diferentes direcciones IP y nombres de host.
Instalé VSFTPD y lo configuré para puertos pasivos. Un cuadro se conecta bien, sin problemas, sin embargo, el segundo cuadro continuamente me arroja este error:
GnuTLS error -15: An unexpected TLS packet was received. Aquí está el seguimiento de depuración de FileZilla:
Status: Connecting to 192.168.20.68:21... Status: Connection established, waiting for welcome message... Trace: CFtpControlSocket::OnReceive() Response: 220 (vsFTPd 3.0.2) Trace: CFtpControlSocket::SendNextCommand() Command: AUTH TLS Trace: CFtpControlSocket::OnReceive() Response: 234 Proceed with negotiation. Status: Initializing TLS... Trace: CTlsSocket::Handshake() Trace: CTlsSocket::ContinueHandshake() Trace: CTlsSocket::OnSend() Trace: CTlsSocket::OnRead() Trace: CTlsSocket::ContinueHandshake() Trace: CTlsSocket::OnRead() Trace: CTlsSocket::ContinueHandshake() Trace: CTlsSocket::OnRead() Trace: CTlsSocket::ContinueHandshake() Trace: TLS Handshake successful Trace: Protocol: TLS1.2, Key exchange: ECDHE-RSA, Cipher: AES-256-GCM, MAC: AEAD Status: Verifying certificate... Status: TLS connection established. Trace: CFtpControlSocket::SendNextCommand() Command: USER datamover Trace: CTlsSocket::OnRead() Trace: CFtpControlSocket::OnReceive() Response: 331 Please specify the password. Trace: CFtpControlSocket::SendNextCommand() Command: PASS ******* Trace: CTlsSocket::OnRead() Trace: CTlsSocket::Failure(-15) Error: GnuTLS error -15: An unexpected TLS packet was received. Trace: CRealControlSocket::OnClose(106) Trace: CControlSocket::DoClose(64) Trace: CFtpControlSocket::ResetOperation(66) Trace: CControlSocket::ResetOperation(66) Error: Could not connect to server El error siempre aparece justo después de la verificación de la contraseña.
Sé que el problema NO ES SELinux, ya que lo desactivé. El problema tampoco es el firewall, ya que intenté deshabilitar el demonio del firewall (firewalld).
Aquí está la parte relevante del archivo /etc/vsftpd/vsftpd.conf.
listen=YES listen_ipv6=NO pasv_enable=YES pasv_max_port=10100 pasv_min_port=10090 pasv_address=192.168.20.88 ssl_enable=YES allow_anon_ssl=NO force_local_data_ssl=YES force_local_logins_ssl=YES ssl_tlsv1=YES ssl_sslv2=NO ssl_sslv3=NO ssl_ciphers=HIGH require_ssl_reuse=NO rsa_cert_file=/etc/ssl/private/vsftpd.pem rsa_private_key_file=/etc/ssl/private/vsftpd.pem Hice una búsqueda en Google pero no vi ningún código de error de 15.
¿Pensamientos?
Respuesta
Tuve el mismo error después del comando PASS en CENTOS 7. (Error GnuTLS -15: Se recibió un paquete TLS inesperado).
Mi solución es la siguiente:
Tuve que agregar lo siguiente a vsftpd.conf:
allow_writeable_chroot=YES chroot_local_user=YES local_root=/ftphome/$USER user_sub_token=$USER Comentarios
- Gracias, por mi archivo /etc/vsftpd.conf agrego: user_sub_token = $ USER y ahora no tengo el error GNUTLS -15 Ahora mismo aparece otro error: No se pudo establecer la conexión de datos: ECONNREFUSED – Conexión rechazada por el servidor
- Resolví mi archivo /etc/vsftpd.conf, puse el mismo valor para » listen_address = 192.168.1.2 » & » pasv_address = 192.168.1.2 » agrego este último y funciona lo necesito: D
- En mi caso tenía local_root apuntando a un directorio faltante – cuando modifiqué esa variable, el error 15 había desaparecido.
Respuesta
Estoy publicando esta respuesta con la esperanza de que pueda ayudar a alguien en el futuro, posiblemente a mí, ya que sufrí al resolver este problema.
No tenía local_root en el archivo /etc/vsftpd/vsftpd.conf configurado correctamente. La configuración apuntaba a una carpeta, que no existía.
Lo que a través de mí fue que vi el error en el comando de contraseña en FileZilla, así que pensé que no le gustaba la contraseña. Lo que me hizo pensar en la dirección correcta fue que me tomé el tiempo para investigar por qué no recibía registros detallados. No recibí registros. Una vez que comencé a recibir registros de depuración, donde vi los protocolos FTP, vi que el servidor FTP decía OK a la contraseña. Lamentablemente, no hubo ningún tipo de registro, pero me encontré con la idea de que negociar la raíz local sería el siguiente curso de acción después de autenticar la contraseña. Tenía razón y eso me llevó al problema.
Aquí está el fragmento de código en el archivo /etc/vsftpd/vsftpd.conf, que contiene la raíz local.
# You may specify an explicit list of local users to chroot() to their home # directory. If chroot_local_user is YES, then this list becomes a list of # users to NOT chroot(). # (Warning! chroot"ing can be very dangerous. If using chroot, make sure that # the user does not have write access to the top level directory within the # chroot) chroot_local_user=YES #local_root=/mnt/raid1 local_root=/ftproot #chroot_list_enable=YES # (default follows) #chroot_list_file=/etc/vsftpd/chroot_list Así es como finalmente encendí el registro detallado, aunque lo apagaré ahora para ahorrar espacio en disco y mejorar el rendimiento.
# Activate logging of uploads/downloads. xferlog_enable=YES # # If you want, you can have your log file in standard ftpd xferlog format. # Note that the default log file location is /var/log/xferlog in this case. xferlog_std_format=NO log_ftp_protocol=YES # # Activate logging of uploads/downloads. xferlog_enable=YES En mi humilde opinión, consideraría el comentario un error, ya que xferlog_enable es más que la carga y descarga de archivos. Esta propiedad también activa el registro. Una investigación de Google demuestra que log_ftp_protocol=YES requiere xferlog_enable=YES.
Comentarios
- Acabo de caer en la misma trampa debido a un error ortográfico. La configuración de un directorio raíz local válido resolvió el problema.
Respuesta
Me enfrenté exactamente al mismo error (Error: error GnuTLS -15: Se recibió un paquete TLS inesperado) y me golpeé la cabeza durante una hora, pero luego descubrí que el directorio de inicio de los usuarios de ftp que estaba en el volumen de Gluster no estaba montado. Se resolvió el problema y el volumen de Gluster montado.
Respuesta
Debe permitir chroot grabable en su archivo de configuración:
sudo nano /etc/vsftpd.conf Luego agregue esta línea en la parte inferior:
allow_writeable_chroot=YES Y reinicie el servicio:
sudo service vsftpd restart Respuesta
Extrañamente para mí, este problema surgió al intentar ls después de iniciar sesión.
Resultó ser que había desinstalado httpd a favor de nginx y el La carpeta que estaba usando era propiedad de apache:apache y el usuario fue eliminado cuando eliminé httpd. I chcon «d los directorios a nginx:nginx y luego reemplacé al usuario en estas líneas en mi archivo de configuración: guest_username=nginx nopriv_user=nginx
Esperamos que esto ayude a alguien porque los mensajes de error no fueron útiles en absoluto.
Respuesta
Me gustaría agregar a Ndianabasi:
Cuando tenga:
allow_writeable_chroot=NO y tiene chroot habilitado, el directorio de Chroot no puede ser escrito por el usuario con el que está intentando iniciar sesión. Este fue mi caso y surgió el mismo error. Lo batí (el directorio raíz) en root: root y eso me lo arregló.
P.D. Comprobé que «no puedo encontrar la opción mencionada en las páginas de manual, pero puede estar disponible en versiones anteriores.
Comentarios
- Si la respuesta es que debe permitir chroot escribible, ¿cómo esto ayuda a alguien que tiene este problema?
Respuesta
compruebe si el directorio y sus directorios principales son legibles y ejecutables para el usuario sftp.
Comentarios
- Tenga en cuenta que esto una pregunta en particular tiene una respuesta aceptada , lo que significa que su problema ya se resolvió.
- gracias, pero solo quería agregar cómo resolví este problema en mi caso. ¿O crees que aún es inapropiado agregar algo?
- Mencioné la respuesta existente porque parecía que este problema en particular tenía una respuesta muy específica. ¿Se encontró con exactamente los mismos síntomas? no, siempre puedes pedirle a & que responda a tu propio problema específico con su respuesta específica.
- Sí, tenía exactamente los mismos síntomas.
Respuesta
No puedo publicar comentarios todavía, así que esto es en parte en respuesta al comentario de Scott y para aclarar la respuesta del Sr.Fantástico …
Me encontré con el mismo problema y después un poco de prueba y error descubrió lo que esto realmente significa y una mejor solución (en mi humilde opinión) que configurar allow_writeable_chroot = YES.
Significa que vsftpd debería permitir la situación en la que el directorio de inicio del usuario puede ser escrito por ese usuario . En cambio, por razones de seguridad, cambié los permisos en la carpeta raíz del usuario a 555. Según otro hilo, esto mitiga un «ATAQUE DE BESTIA RUGIENTE».
En mi caso, la configuración original era: (777) drwxrwxrwx / home / ftpuser /
Cambiar el directorio del usuario a: (555) dr-xr-xr-x / home / ftpuser /
hizo que el directorio de inicio del usuario NO escribible por el usuario y por lo tanto no tuve que usar allow_writeable_chroot = YES. Esto está bien (y más seguro) para mi situación, ya que tengo una estructura de directorio preestablecida y no quiero que el usuario cree nuevos archivos o directorios en su carpeta raíz de todos modos.
Me di cuenta de esto cuando cambié el directorio de inicio a / var / ftp a través del parámetro local_root = para vsftpd y funcionó sin tener que establecer allow_writeable_chroot = YES. Esta carpeta / var / ftp es (755) pero es propiedad de root y, por lo tanto, no se puede escribir en ftpuser.