1- Para consertar o erro "WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!"
No servidor execute:
ssh-keygen -R "hostname" -f "/home/usuario/.ssh/known_hosts"
Ou pelo IP:
ssh-keygen -R "192.168.1.X" -f "/home/usuario/.ssh/known_hosts"

Para o comando pelo hostname funcionar sem dúvidas com IP estático (fixo) o arquivo /etc/hosts do servidor e do(s) cliente(s) tem de estar configurados iguais, senão pode funcionar umas vezes e outras não, contudo, esse erro geralmente acontece (tanto com IP dinâmico ou estático) se você alterar o hostname em alguma das máquinas, se você desinstalar e reinstalar o ssh, etc, ou seja, caso você fizer alguma alteração de identificação das máquinas envolvidas no processo de autenticação por ssh.

Ou com:
ssh-keygen -R 192.168.1.X
ssh-keygen -R hostname

O comando ssh-keygen serve para gerar, gerenciar e converter chaves ssh; nesse caso em específico (opção -R) ele remove todas as chaves pertencentes ao cliente no arquivo da opção -f.
man ssh-keygen

E tente a conexão outra vez, em alguns casos precisa copiar a chave novamente.

Copie a chave executando no servidor:
ssh-copy-id hostname
ou
ssh-copy-id 192.168.1.X

E tente a conexão.

2- Para evitar o erro "client_loop: send disconnect: Broken pipe"
Acesse o arquivo de configuração do ssh no servidor:
sudo vim /etc/ssh/sshd_config
Procure as seguintes linhas e deixe elas assim (ou aumente o tempo [300 segundos são 5 minutos]):
ClientAliveInterval 300
ClientAliveCountMax 3
sudo systemctl restart sshd

Após os primeiros 300 segundos (5 minutos) de inatividade do cliente, o servidor enviará uma mensagem de alive para o cliente para manter a sessão SSH ativa e fará isso 2 vezes, ou seja, enviará duas mensagens (aos 300 e aos 600) e depois aos 900 segundos a conexão SSH será terminada ou desconectada.

Esse erro também pode ser uma interrupção momentânea da rede, da internet, etc, bastando aguardar um pouco e tentar a conexão novamente, porém, caso você aumentar os valores dos parâmetros e continuar caindo em demasia e a toda hora, verifique a conectividade da rede.

3- O erro "ssh: connect to host xxx.xxx.xxx.xxx port 22: No route to host" é o mais genérico de todos, pois pode significar várias coisas: que o host está desligado, que a porta destinada ao ssh não está escutando, que o firewall está bloqueando, que as credenciais (chave e/ou senha) estão incorretas, uma interrupção momentânea na rede, algumas vezes pode ser até os relógios do servidor e dos clientes que não estão em sincronia, etc.
Já me aconteceu que depois de instalar o Chrony no servidor e nos clientes, configurando o servidor como servidor NTP dos clientes, o ssh estabilizou.

A primeira providência com o erro genérico é reiniciar o servidor ssh e caso não resolver, reinicie o computador.

Execute no servidor e no cliente que não conecta:
which ssh
A saída deverá ser:
/usr/bin/ssh
ou algo parecido, depende do sistema.
Isso mostrará que, pelo menos, o ssh está instalado.

Verifique sempre o arquivo de configuração /etc/ssh/sshd_config:
sudo vim /etc/ssh/sshd_config

Veja os parâmetros:
#PubkeyAuthentication yes
#PasswordAuthentication yes

Geralmente para conectar com chave ou chave em branco basta deixar nos padrões, porém, de qualquer modo, mesmo com chave em branco o ssh gerará um hash público (pubkey) que deverá ser copiado para o(s) cliente(s).
Lembrando que chave e senha no ssh não são a mesma coisa, veja no link a diferença:
https://www.hostwinds.pt/tutorials/ssh-password-vs-key-based-authentication

Verifique no link abaixo os padrões:
https://man.openbsd.org/sshd_config#PasswordAuthentication

Execute
man ssh
ou
man sshd

Aqui tem mais algumas opções para resolver o erro genérico:
https://runcloud.io/blog/fix-ssh-connection-refused