unfortunately I don't have access to ssh server, I can only see:

Platform: i586-pc-linux-gnu
Compiled with: liblua-5.2.3 openssl-1.0.1k libpcre-8.35 libpcap-1.6.2 nmap-libdnet-1.12 ipv6
Compiled without:
Available nsock engines: epoll poll select

ssh -vvvl user ip

debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: mac_setup: setup hmac-sha1
debug1: kex: server->client 3des-cbc hmac-sha1 none
debug2: mac_setup: setup hmac-sha1
debug1: kex: client->server 3des-cbc hmac-sha1 none
debug2: bits set: 502/1024
debug1: sending SSH2_MSG_KEXDH_INIT
debug1: expecting SSH2_MSG_KEXDH_REPLY
Connection closed by IP 

You should be solve adding:


ssh -o MACs=hmac-sha1 -vvvl user ip
  • 3
    explanation? what happens? what is missing, and how this answer solves the problem? ... please? – Matyas Oct 5 '15 at 21:02
  • 2
    Its obviously the right answer in this situation but doesn't help anyone who wants to know why it works!! – Paul Rooney Feb 25 '16 at 7:10
  • 4
    The answer solves the problem because it forces the SSH client to use a specific Message Authentication Code (MAC) that is supported by the server. The option -o MACs=hmac-sha1 sets the MAC to use a code base on SHA1 algorithm which is the one supported by the server (as can be seen via the -vvvl option). More infos at this link best regards, MrClick – user377728 Sep 26 '16 at 21:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.