São apenas os processos 'servidor' e 'cliente' do NX que usam uma conta de usuário especial chamada "nx". Essas contas servem para configurar o estágio inicial da conexão e usar o par de chaves que você mencionou, e isso é tudo antes o login do usuário real acontece. Essa chave é NÃO usada para o login do usuário real da sessão do NX.
Quando esse estágio inicial for concluído, haverá um canal seguro e criptografado. É, então, esse canal criptografado (estabelecido com a ajuda da chave NX SSH padrão) que é usado para fazer o login do usuário real .
Portanto, com somente sabendo a chave SSH padrão, ninguém pode efetuar login em um servidor NX. Ele só pode iniciar a fase inicial de "handshake" e é então preso.
É como se você fizesse login em um servidor HTTPS, que mostra a caixa de diálogo nome de usuário + senha ... [E você consideraria isso particularmente inseguro: uma caixa de diálogo de senha aparecendo antes de o login do usuário HTTPS ser concluído?]
É claro que, para uma sensação de segurança adicional , você pode criar sua própria chave e substituir as chaves NX / NoMachine padrão - melhor se você criar uma par de chaves para cada servidor NX diferente. Hmmm .... esta (s) chave (s) de usuário conhecida (s), então você deve distribuir para todos os usuários de seus respectivos servidores NX. E agora você deve começar a fazer mais trabalhos administrativos para gerenciar todas as chaves dos diferentes servidores NX. Segurança adicional vem com trabalho adicional ....