Erro do MySQL: Acesso negado para o usuário 'a'@'localhost' (usando senha: YES)

​​​​​​​​​​Aqui está um método rápido e sujo para verificar como o MySQL executa uma autenticação bem-sucedida.

Execute esta consulta:

SELECT USER(),CURRENT_USER();

USER() relata como você tentou autenticar no mysqld

CURRENT_USER() relata como você teve permissão para autenticar pelo mysqld

Às vezes, USER()e CURRENT_USER()são diferentes. Isso porque a autenticação mysql segue um protocolo específico.

De acordo com o Guia de Estudo de Certificação MySQL 5.0

as páginas 486.487 informam o seguinte sobre o algoritmo de autenticação do mysql:

Existem dois estágios de controle de acesso do cliente:

No primeiro estágio, um cliente tenta se conectar e o servidor aceita ou rejeita a conexão. Para que a tentativa seja bem-sucedida, alguma entrada na tabela de usuários deve corresponder ao host do qual o cliente se conecta, o nome de usuário e a senha.

Na segunda etapa (que ocorre apenas se um cliente já tiver se conectado com sucesso), o servidor verifica todas as consultas que recebe do cliente para ver se o cliente possui privilégios suficientes para executá-la.

O servidor compara um cliente com as entradas nas tabelas de concessão com base no host do qual o cliente se conecta e no usuário fornecido pelo cliente. No entanto, é possível que mais de um registro corresponda:

Os valores de host nas tabelas de concessão podem ser especificados, pois os padrões contêm valores curinga. Se uma tabela de concessões contiver entradas de myhost.example.com, %.example.com, %.come %, todas elas correspondem a um cliente que se conecta de myhost.example.com.

Os padrões não são permitidos para os valores do usuário nas entradas da tabela de permissões, mas um nome de usuário pode ser fornecido como uma string vazia para especificar um usuário anônimo. A string vazia corresponde a qualquer nome de usuário e, portanto, atua efetivamente como um curinga.

Quando os valores de Host e User em mais de um registro da tabela de usuários correspondem a um cliente, o servidor deve decidir qual deles usar. Ele faz isso classificando os registros com os valores de coluna de Host e Usuário mais específicos primeiro e escolhendo o registro correspondente que ocorre primeiro na lista classificada, a classificação ocorre da seguinte maneira:

Na Coluna Host, valores literais como localhost, 127.0.0.1e myhost.example.comclassificam à frente de valores como aqueles %.example.com que possuem caracteres padrão neles. Os valores padrão são classificados de acordo com a sua especificidade. Por exemplo, %.example.comé mais específico que %.com, que é mais específico que %.

Na coluna Usuário, os nomes de usuário não em branco são classificados à frente dos nomes de usuário em branco. Ou seja, usuários não anônimos classificam à frente de usuários anônimos.

O servidor executa essa classificação quando é iniciado. Ele lê as tabelas de concessões na memória, as classifica e usa as cópias na memória para controle de acesso.

A partir desta descrição, você não precisa se preocupar com a ordem das tabelas mysql.user, pois há uma cópia na memória das tabelas de concessões que são classificadas conforme mencionado anteriormente.

Com relação a como você fez login, só mysql -u afuncionou. Volte e faça login novamente e execute esses comandos

SELECT USER(),CURRENT_USER();
SELECT user,host,password FROM mysql.user;

Certifique-se de que

• cada usuário tem uma senha.
• não há usuários anônimos (quando o usuário está em branco)

Isso é apenas um palpite, mas suspeito mysql -u ade conectar via localhost porque quando o protocolo de conexão não é especificado, o padrão é conectar através do arquivo de soquete. Pode existir uma entrada mysql.userque permite conexão anônima de host local.

Execute esta consulta:

SELECT user,host,password FROM mysql.user WHERE user='' AND host='localhost';

Se você voltar uma linha sem senha, isso explica totalmente por que mysq -u afunciona.

ATUALIZAÇÃO 2012-01-19 11:12 EDT

Craig Efrein levantou uma questão interessante: se dois nomes de usuário idênticos existirem na tabela mysql.user, um com senha e outro sem, isso significa que o MySQL nega autenticação quando não está usando uma senha?

Esta pergunta é um excelente aviso sobre a autenticação do usuário do MySQL.

Por favor, note que a chave primária de mysql.user é host,user. Não há outros índices. Isso permite várias ocorrências de um nome de usuário. Cada ocorrência pode ter uma senha diferente ou nenhuma senha. Isso permite que o usuário 'dbuser' faça login localmente (dbuser@localhost) usando nenhuma senha e o mesmo login de usuário de outro servidor dentro de um determinado netblock (dbuser@'10.1.2.20') com uma senha como 'pass1' e esse usuário faça login remotamente de qualquer lugar (dbuser@'%') com uma senha remota como 'pass2'.

Dado o algoritmo de autenticação que o MySQL usa, não há restrições impostas aos usuários com a presença ou ausência de uma senha.

É por isso que o Guia de Estudo de Certificação do MySQL 5.0 diz na página 498 Parágrafo 6 em seus marcadores que mostra como limpar o processo de autenticação:

No Unix, o MySQL vem com um script mysql_secure_installation que pode executar várias operações úteis relacionadas à segurança em sua instalação. O script tem os seguintes recursos:

• Defina uma senha para as contas root
• Remova quaisquer contas root acessíveis remotamente.
• Remova as contas de usuários anônimos. Isso melhora a segurança porque evita a possibilidade de qualquer pessoa se conectar ao servidor MySQL como root a partir de um host remoto. O resultado é que qualquer pessoa que queira se conectar como root deve primeiro poder fazer login no host do servidor, o que oferece uma barreira adicional contra ataques.
• Remova o banco de dados de teste (se você remover as contas anônimas, também poderá remover o banco de dados de teste ao qual elas têm acesso).

O curinga do host '%' não corresponde a 'localhost'. Por padrão, o cliente mysql tentará se conectar através de um soquete em vez de tcp (geralmente em algum lugar como /var/lib/mysql/mysql.sock).

Você pode alterar sua concessão para 'a'@'localhost' ou forçar o cliente a operar na pilha TCP como:

mysql -u a -p --protocol=TCP

Você verificou se o MySQL está realmente ouvindo em 3306? Execute um netstat -tlpn e forneça os resultados. Se você não vir 3306, provavelmente não.

Em my.cnf você deve verificar se --skip-networking está comentado

[mysqld]
user            = mysql
pid-file        = /var/run/mysqld/mysqld.pid
socket          = /var/run/mysqld/mysqld.sock
port            = 3306
basedir         = /usr
datadir         = /var/lib/mysql
tmpdir          = /tmp
language        = /usr/share/mysql/English
bind-address    = 65.55.55.2
# skip-networking

Como o @atxdba descreveu, para conectar o daemon mysql do remoto que não se conecta via soquete, então você precisa se conectar remotamente via TCP.

Para isso, você deve especificar as --protocol=TCPconexões por cada. Embora, você possa configurá-lo no my.cnfservidor:

[client]
protocol=tcp