Acesso remoto MySQL: como liberar com segurança

Aprenda a liberar o acesso remoto ao MySQL no Ubuntu em três travas: bind-address, usuário por IP e firewall, com teste criptografado e erros comuns.

Por Redação Eleven Host · @robson.direitodigital · 27 de outubro de 2026 · 8 min de leitura

Para liberar o acesso remoto MySQL num servidor Ubuntu, são três travas: o MySQL escutar na rede (bind-address), um usuário com permissão para o IP de origem e o firewall abrindo a porta 3306 só para esse IP.

Este guia leva as três travas na ordem, testa a conexão com criptografia e mostra erros comuns. Os endereços são exemplos: 203.0.113.10 é o servidor do banco, 198.51.100.20 é a máquina do app, e app e meu_banco são nomes de exemplo. Troque pelos seus.

Você precisa mesmo abrir?

Por padrão, num servidor Ubuntu com o pacote mysql-server, o MySQL escuta só no próprio servidor (127.0.0.1). Isso protege o banco: um app em outra máquina não consegue conectar, e a porta não fica exposta na rede.

Se o app roda na mesma VPS que o banco, deixe como está. A conexão local já funciona e você não abre porta nenhuma.

Se o app está em outra máquina, ou se você só quer abrir o banco no seu computador para consultar dados, existe uma alternativa que não abre a 3306: o túnel SSH. Neste comando, o seu computador passa a ter a porta 3307 ligada ao MySQL do servidor:

ssh -L 3307:127.0.0.1:3306 usuario@203.0.113.10

Com o túnel aberto, o cliente do MySQL conecta em 127.0.0.1, porta 3307, e o tráfego viaja dentro do SSH. Para entrar no servidor sem senha, veja Como criar chave SSH e entrar na VPS sem senha.

Quando o app precisa ficar ligado ao banco o tempo todo, de outra máquina, o caminho é abrir o acesso remoto. Siga os passos abaixo.

Passo 1: mudar o bind-address

No Ubuntu, a configuração do servidor fica em /etc/mysql/mysql.conf.d/mysqld.cnf. Abra o arquivo com o seu editor:

sudo nano /etc/mysql/mysql.conf.d/mysqld.cnf

Procure a diretiva bind-address. A documentação do Ubuntu manda trocá-la pelo IP do servidor para aceitar conexões de outras máquinas. O valor muda o que o MySQL aceita:

• 127.0.0.1: só conexões do próprio servidor. É o valor que o pacote do Ubuntu deixa no arquivo.
• Um endereço específico, como 203.0.113.10: o MySQL escuta só nesse endereço.
• 0.0.0.0: todas as interfaces IPv4.
• ::: IPv4 e IPv6.
• *: o padrão do próprio MySQL, que escuta em todas as interfaces IPv4 e, se houver, IPv6.

A documentação do MySQL aceita uma lista com vários valores, mas nesse caso sem curingas. Prefira o endereço específico do servidor: assim você escolhe em qual interface o banco escuta. Salve o arquivo e reinicie o serviço:

sudo systemctl restart mysql

Confira onde o MySQL está escutando:

sudo ss -tlnp | grep 3306

A linha deve mostrar o endereço que você escolheu, seguido de :3306. Se ainda aparecer 127.0.0.1:3306, talvez o arquivo editado não seja o que o serviço lê ou o reinício não tenha acontecido. Repita o passo.

Passo 2: criar um usuário para o IP de origem

No MySQL, a conta é identificada por usuário e origem, no formato 'usuario'@'host'. Se você omitir o host, o MySQL entende '%', que significa qualquer origem. Por isso, escreva o IP de onde o app vai sair. Abra o cliente do MySQL no servidor, com um usuário administrador, e rode:

CREATE USER 'app'@'198.51.100.20' IDENTIFIED BY 'senha-forte-aqui';

Depois dê só as permissões que o app usa. Para um app que lê e grava dados, use estas, como exemplo:

GRANT SELECT, INSERT, UPDATE, DELETE ON meu_banco.* TO 'app'@'198.51.100.20';

Três cuidados nessa etapa:

• Evite o root remoto. Se a conta de administrador vazar, o estrago alcança o servidor de banco inteiro.
• Evite '%' sem um motivo claro. Com ele, a conta vale para qualquer origem que alcance a porta.
• Troque senha-forte-aqui por uma senha longa e única, guardada num gerenciador de senhas.

Para exigir conexão criptografada nessa conta, acrescente:

ALTER USER 'app'@'198.51.100.20' REQUIRE SSL;

Essa regra faz o MySQL aceitar só conexões criptografadas para essa conta. Se precisar copiar dados para o banco depois, veja Importar banco de dados MySQL: passo a passo e erros comuns.

Precisa de um banco de dados na nuvem? Conheça o 11SQL, a partir de R$ 9,90/mês no 11SQL Mini; confira na loja o que cada plano inclui. Ver planos do 11SQL

Passo 3: liberar a porta 3306 só para o IP do app

Com o firewall ufw, abra a 3306 apenas para a máquina do app:

sudo ufw allow from 198.51.100.20 to any port 3306 proto tcp

Não use ufw allow 3306 sem o from: esse comando abre a porta para a internet inteira. Confira a regra criada:

sudo ufw status

A linha da 3306 deve trazer o IP do app. Se o ufw ainda não está configurado no servidor, o guia Firewall para VPS: como proteger seu servidor explica como começar.

Passo 4: testar com conexão criptografada

Na máquina do app (o IP que você usou no usuário), conecte com o cliente do MySQL:

mysql -h 203.0.113.10 -u app -p --ssl-mode=REQUIRED meu_banco

Segundo a documentação do MySQL, o modo REQUIRED exige conexão criptografada e falha se não conseguir criá-la. Os modos VERIFY_CA e VERIFY_IDENTITY vão além: também conferem o certificado e, no segundo caso, o nome do servidor. Digite a senha quando o cliente pedir. Se aparecer o prompt mysql>, a conexão funcionou.

Criptografia: o que o servidor precisa ter

Sem criptografia, os dados da conexão viajam sem proteção pela internet. Pela documentação, o servidor ativa as conexões criptografadas quando encontra os arquivos ca.pem, server-cert.pem e server-key.pem no diretório de dados. Servidores compilados com OpenSSL podem gerar esses arquivos sozinhos ao iniciar, e os certificados gerados assim são autoassinados.

Isso tem um efeito prático. Com certificado autoassinado, o modo REQUIRED exige que o tráfego vá criptografado, mas não confere o certificado nem o nome do servidor. Se você quer essa conferência, os modos VERIFY_CA e VERIFY_IDENTITY a fazem, e o certificado do servidor precisa ser aceito pelo cliente.

Para o servidor recusar conexão TCP sem criptografia, e não só as de uma conta, ligue a opção require_secure_transport no arquivo de configuração do servidor:

require_secure_transport=ON

Reinicie o MySQL depois da mudança. Quem tentar conectar sem criptografia recebe o erro ER_SECURE_TRANSPORT_REQUIRED.

Erros comuns

• Conexão recusada ou tempo esgotado: olhe primeiro as duas travas de rede, o bind-address e o firewall. Rode o ss do passo 1 e o ufw status do passo 3.
• "Access denied": o usuário, o host ou a senha não batem. O host da conta tem de ser o IP de onde o app sai.
• O app parou de conectar depois de um tempo: uma causa possível é o IP do app ter mudado. Nesse caso, crie o usuário para o novo IP, repita a regra do firewall e remova as antigas.
• O banco precisa de cópia de segurança: abrir o acesso não protege os dados. Veja Backup MySQL com mysqldump: como fazer e restaurar.

Quer o banco e o app em servidores seus? Os planos de VPS começam em R$ 17,00/mês, no Plano Bronze; confira na loja o que cada plano inclui. Ver planos de VPS

Perguntas frequentes

É seguro liberar o acesso remoto do MySQL?

Fica mais seguro com as travas deste guia: usuário por IP, permissões mínimas, firewall só para o IP do app e conexão criptografada. Abrir a 3306 para a internet inteira, com um usuário aberto a qualquer origem, é o que você deve evitar.

Qual valor colocar no bind-address?

Para aceitar conexões de outras máquinas, a documentação do Ubuntu manda usar o IP do servidor. O valor 127.0.0.1 deixa o banco só local, e 0.0.0.0 escuta em todas as interfaces IPv4.

Posso usar o usuário root para conectar de fora?

Evite. Crie uma conta para o app, ligada ao IP de origem e com só as permissões de que ele precisa.

Por que recebo "Access denied" mesmo com a senha certa?

Pode ser porque a conta no MySQL vale para um usuário e um host. Se o app sai de um IP diferente do que você usou no CREATE USER, o MySQL trata como outra conta. Crie o usuário para o IP certo.