połączenie z hostem z uruchomionym serwerem ssh2 przy użyciu klienta ssh

Próbuję połączyć się z hostem linux (host_hosta) z uruchomionym sshd2 przy użyciu klienta ssh (host_hosta);

ssh-keygen -e -f id_rsa.pub > client_host_ssh2_id_rsa.pub

i skopiował client_host_ssh2_id_rsa.pub do target_host. Jednak gdy próbuję się połączyć, otrzymuję „brak alg hostkey”

ssh user@target_host -v
OpenSSH_5.1p1, OpenSSL 0.9.8a 11 Oct 2005
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Connecting to target [169.35.74.21] port 22.
debug1: Connection established.
debug1: identity file /home/user/.ssh/identity type -1
debug1: identity file /home/user/.ssh/id_rsa type 1
debug1: identity file /home/user/.ssh/id_dsa type 2
debug1: Remote protocol version 2.0, remote software version 6.0.12.81   SSH  Tectia Server
debug1: no match: 6.0.12.81 SSH Tectia Server
debug1: Enabling compatibility mode for protocol 2.0
 debug1: Local version string SSH-2.0-OpenSSH_5.1
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
no hostkey alg

Czy ktoś może mi pomóc określić, czego tu brakuje?

— birjoossh
źródło

Najprawdopodobniej tego, czego brakuje, na zdalnej maszynie:

 cd $HOME/.ssh;  cat client_host_ssh2_id_rsa.pub >> authorized_keys

Jeśli to nie wystarczy, zatrzymaj demona sshd, a następnie uruchom go ponownie w następujący sposób:

 /usr/sbin/sshd -Dd

co zapobiega demonizacji i wyświetla komunikat o błędzie na standardowym wyjściu. Podczas próby zalogowania się w ten sposób będziesz mógł zobaczyć komunikaty o błędach po stronie serwera, które są znacznie bardziej pouczające niż te po stronie klienta, z oczywistych względów bezpieczeństwa. Pomoże to nam / nam debugować problem.

— MariusMatutiae
źródło