Trouble connecting to MySQL server:

[John_Nagle]

Ref: Unknown authentication protocol: `sha256_password` · Issue #396 · blackbeam/rust-mysql-simple · GitHub

I'm trying to connect to a MySQL server on Dreamhost shared hosting. Error message is:

Server side error message:

DriverError { Unknown authentication protocol: `sha256_password` }

This seems to indicate that the mysql crate is sending a different kind of authentication than the server expects. Here's the login setup:

let opts = mysql::OptsBuilder::new()
    .enable_cleartext_plugin(true)
    .secure_auth(false)
    .ip_or_hostname(creds.get("DB_HOST"))
    .tcp_port(portnum)
    .user(creds.get("DB_USER"))   
    .pass(creds.get("DB_PASS"))  
    .db_name(creds.get("DB_NAME"));

I've tried this with and without disabling secure_auth.
I tried what the documentation says is the correct OpsBuilder functions for that, but it doesn't help.

MySQL version: 8.0.28-0ubuntu0.20.04.3

Note that this is shared hosting. I can't look at mysql.user to see auth modes.

It's been reported as a mysql crate issue previously by someone else. But there's no reply on Github.

[relunsec]

Hello, @John_Nagle

I Think This is a Bug in mysql crate you report it but no response. Wait for a time i already report 2 issues in github even 3/2 days ago no response you need be patient because the team should be review etc....

[John_Nagle]

What seems to be happening is a conflict between Dreamhost setting a retro option to support old versions of Wordpress vs the mysql crate, being a modern implementation, not supporting deprecated encryption formats.

Dreamhost support page:

DreamHost has made modifications to its MySQL 8 configuration to provide broader support for most sites and software. The following are default settings in MySQL 8 that have been modified in DreamHost's configuration:

Setting	Default	DreamHost
Encryption plugin	caching_sha2_password	mysql_native_password

The original mysql_native_password encryption is deprecated in MySQL 8 and removed in MySQL 9. It's a proprietary encryption and there is a vulnerability CVE. So the mysql crate is doing it right, and Dreamhost is wrong.

Submitted trouble ticket to Dreamhost. More tomorrow.

Ticket with Dreamhost:

Ref: https://help.dreamhost.com/hc/en-us/articles/30003134864276-Using-reserved-words-in-MySQL-8

Error message: Unknown authentication protocol: sha256_password

This seems to be an encryption versioning problem.

The Rust crate "mysql" and Dreamhost servers seem to be unable to agree on an authentication encryption. The correct standard today, since about 2018, is 'caching_sha2_password'. The Rust crate supports this. So does MySQL 8, which you are running. But for WordPress sites, the note referenced indicates you change this for compatibility with old Wordpress. My site (animats.info, database "terrain.animats.info") is not a Wordpress site.Right now, I can't get the Rust crate to connect via any authentication method. On the Rust side, sha256_password has been removed as obsolete and insecure.

I think your backwards compatibility patch broke forwards compatibility. Please advise.

[relunsec]

Yes sha256_password deprecated and removed auth method and insecure and unsafe so you need use a modern mysql server use hostinger and other instead of DreamHost.

[John_Nagle]

That's what the mysql crate code says, all right:

src/conn/mod.rs

Despite what Dreamhost documentation says, the login name seems to be configured for sha256_password

[John_Nagle]

Found the problem.

In the Rust "mysql" documentation:

pub fn secure_auth(self, secure_auth: bool) -> Self

Disables mysql_old_password plugin (defaults to true).

Ref: OptsBuilder in mysql - Rust

As is standard for Rust, the most secure mode is the default. Set that to false for legacy Dreamhost servers.
Have to explicitly turn off secure_auth to allow the old mysql_native_password, which is known to be vulnerable. With secure_auth turned on, negotiation fails because there's no overlap between what Dreamhost uses for IDENTFIED BY and what Rust considers secure.

How it got to sha256_password, which neither end supports, I don't know. Probably both ends were trying to negotiate some auth mode that would work that would work and that message cane from the final failed try, leading to a confusing error message.