static const char quality_config_key[] =
so that it goes into the rodata section.

(I just rechecked with a small test program, and yes, this is still valid, a const char* goes into .data while a const char[] goes into .rodata)

the connect could move under #ifdef LIBSSH_FOUND

I would add a comment here, for the next reader.

// This is called by the main thread, but from a slot connected to our signal via BlockingQueuedConnection, so this is safe even without a mutex, the semaphore in BlockingQueuedConnection takes care of the synchronization.

(missing space after if, here as well)

You could use a local RAII class to avoid duplicating close+ssh_disconnect+ssh_free in every return code path (initialize m_server_sock to -1 in the constructor so you can test for it before calling close).

As a benefit this huge method would be a little bit less huge ;)

"any error here will propagate" confused me, I was wondering how those two threads would communicate then.
After your clarification over chat, I think this comment should say something like "any socket error here will be detected by the vnc thread".

missing space after while
one space too many after eof...

Should this also say while (!error && ...)? I'm not sure, but it looks like the current code might go into an infinite loop if FD_ISSET always return false for some reason.
OTOH I'm not sure if you want to abort on first error...

Instead of the if+continue above, this line could say if (!error && !channel_read_buffer), to match the next if() which also does if (!error && ...). It just seems asymetric to use continue in one case and if in the other.

On error, this delete[] might never happen. Maybe do it at end of block too?

This is for sure a race on m_server_sock. I guess this is here in order to wake up ssh_select in the thread?

In that case, m_server_sock needs to be mutex-protected, everywhere it's used.
But the run() method could use a local variable with a copy of that socket value, so that it only needs mutex-protection to write into the member variable, once, when the value is first known.

But actually, ssh_select has a timeout of 200ms so m_stop_thread is checked every 200ms, no?
(not sure why it needs to wake up so often, though, especially if we can stop the thread by closing the socket).

It seems to me that either the timeout stays short and stop() can just wait 200ms, or the timeout becomes much longer and we do need to shutdown here. Am I missing something?