VSFTPD FileZilla GnuTLS erro -15 (pacote TLS inesperado foi recebido)

Eu tive o mesmo erro após o comando PASS no CENTOS 7. (Erro GnuTLS -15: Um pacote TLS inesperado foi recebido.)

Minha solução é a seguinte:

Eu tive que adicionar o seguinte ao vsftpd.conf:

allow_writeable_chroot=YES chroot_local_user=YES local_root=/ftphome/$USER user_sub_token=$USER 

Comentários

• Obrigado, pelo meu arquivo /etc/vsftpd.conf adiciono: user_sub_token = $ USER e agora não tenho o erro GNUTLS -15 Agora recebo outro erro: A conexão de dados não pôde ser estabelecida: ECONNREFUSED – Conexão recusada pelo servidor
• resolvi em meu arquivo /etc/vsftpd.conf, coloquei o mesmo valor para ” listen_address = 192.168.1.2 ” & ” pasv_address = 192.168.1.2 ” adiciono este último e funciona, preciso: D
• No meu caso, tinha local_root apontando para um diretório ausente – quando eu modifiquei essa variável, o erro 15 havia desaparecido.

Estou postando esta resposta na esperança de que ela possa ajudar alguém no futuro, possivelmente eu, já que sofri com a resolução desse problema.

Eu não tinha local_root em o arquivo /etc/vsftpd/vsftpd.conf definido corretamente. A configuração apontava para uma pasta, que não existia.

O que através de mim foi que vi a falha no comando de senha no FileZilla, então pensei que não gostou da senha. O que me fez pensar na direção certa foi que dediquei um tempo pesquisando por que não estava recebendo registros detalhados. Não recebi registros. Assim que comecei a receber logs de depuração, onde vi os protocolos FTP, vi que o servidor FTP disse OK para a senha. Infelizmente, não houve nenhum tipo de registro, mas pensei que negociar a raiz local seria o próximo curso de ação depois de autenticar a senha. Eu estava certo e isso me levou ao problema.

Aqui está o fragmento de código no arquivo /etc/vsftpd/vsftpd.conf, contendo a raiz 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 

Aqui está como eu finalmente ativei o registro detalhado, embora vá desligá-lo agora para economizar espaço em disco e melhorar o desempenho.

# 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 

IMHO, eu consideraria o comentário um bug, já que xferlog_enable é mais do que o próprio upload e download de arquivos. Esta propriedade também ativa o registro. Uma pesquisa do Google prova que log_ftp_protocol=YES requer xferlog_enable=YES.

Comentários

• Acabei de cair na mesma armadilha devido a um erro de ortografia. Definir um diretório local_root válido resolveu o problema.

Encontrei exatamente o mesmo erro (Erro: erro GnuTLS -15: Um pacote TLS inesperado foi recebido.) E bati minha cabeça por cerca de uma hora, mas então descobri que o diretório inicial dos usuários de ftp que estava no volume Gluster não estava montado. Volume do Gluster montado e problema resolvido.

Você precisa permitir chroot gravável em seu arquivo de configuração:

sudo nano /etc/vsftpd.conf 

Em seguida, adicione esta linha na parte inferior:

allow_writeable_chroot=YES 

E reinicie o serviço:

sudo service vsftpd restart 

Estranhamente para mim, esse problema surgiu ao tentar ls depois de fazer login.

Descobri que eu havia desinstalado httpd em favor de nginx e o a pasta que eu estava usando pertencia a apache:apache e o usuário foi removido quando removi httpd. Eu chcon “d os diretórios para nginx:nginx e substituí o usuário nessas linhas em meu arquivo de configuração: guest_username=nginx nopriv_user=nginx

Espero que isso ajude alguém porque as mensagens de erro não foram úteis em nada.

Eu gostaria de adicionar a Ndianabasi:

Quando você tiver:

allow_writeable_chroot=NO 

e você ativou o chroot, o diretório do Chroot não pode “ser gravável pelo usuário com o qual você está tentando fazer o login. Este foi o meu caso e ocorreu o mesmo erro. Eu alterei (o dir root) para root: root e isso consertou para mim.

P.S. Verifiquei não consigo mais encontrar a opção mencionada nas páginas de manual, mas pode estar disponível em versões anteriores.

Comentários

• Se a resposta é que você deve permitir chroot gravável, como isso ajuda alguém que tenha esse problema?

verifique se o diretório e seus diretórios pais são legíveis e executáveis para o usuário sftp.

Comentários

• Observe que isto determinada pergunta tem uma resposta aceita , significando que o problema já foi resolvido.
• obrigado, mas eu só queria adicionar como resolvi esse problema no meu caso. ou você acha que ainda é impróprio adicionar algo?
• Mencionei a resposta existente porque parecia que este problema específico tinha uma resposta muito específica. Você encontrou exatamente os mesmos sintomas? Se não, você sempre pode pedir & para responder ao seu problema específico com sua resposta específica.
• Sim, tinha exatamente os mesmos sintomas.

Não posso postar comentários ainda, então isso é parcialmente em resposta ao comentário de Scott e para esclarecer a resposta do Sr. Fantástico …

Eu encontrei o mesmo problema e depois algumas tentativas e erros descobriram o que isso realmente significa e uma solução melhor (IMHO) do que definir allow_writeable_chroot = YES.

Isso significa que o vsftpd deve permitir a situação em que o diretório inicial do usuário pode ser escrito por esse usuário . Em vez disso, por razões de segurança, alterei as permissões na pasta raiz do usuário para 555. De acordo com outro tópico, isso atenua um “ATAQUE DE BESTA RUGIDO”.

No meu caso, a configuração original era: (777) drwxrwxrwx / home / ftpuser /

Alterar o diretório do usuário para: (555) dr-xr-xr-x / home / ftpuser /

torna o diretório inicial do usuário NÃO gravável pelo usuário e, portanto, não precisei usar o allow_writeable_chroot = YES. Isso é bom (e mais seguro) para minha situação, já que tenho uma estrutura de diretório predefinida e não quero que o usuário crie novos arquivos ou diretórios em sua pasta raiz de qualquer maneira.

Eu descobri isso quando mudei o diretório inicial para / var / ftp através do parâmetro local_root = para vsftpd e funcionou sem a necessidade de definir allow_writeable_chroot = YES. Esta pasta / var / ftp é (755), mas pertence ao root e, portanto, não pode ser gravada pelo ftpuser.