The abrupt change could be the result of a change in the configuration file on the servers
sshd configuration, but you indicate cannot check or alter that without admin right. You can still try the following if the server’s admins cannot be reached (in time).
Your log only indicates the local version string, you should check the versions of
sshd running on the server and the intermediate machine.
If these versions differ (especially between the local machine and the server and less between the intermediate machine and the server) there might be some negotiation incompatibility, this has happened before in
ssh. The solution used to be to shorten the Ciphers, HostKeyAlgorithms and/or MACs entries, either on the commandline (
ssh -c aes256-ctr, etc.) or on in your
You should look in the debug information (from connecting via the intermediate to the server) for appropriate values as argument for the
MACs commandline resp. ssh_config changes.
I haven’t had this problem myself for a while, but IIRC when I did it was enough to manually force the Ciphers and HostKeyAlgorithms setting, after which I could update the server’s
sshd version and the problem went away.
You may have been banned by
denyhosts. In such a case (and also to check it), if you don’t want to bother with your server provider assistance, you need to log into your server from another IP address : e.g. another server, or a friend’s home connection, or a wifi hot spot, or using SSH with TOR.
Once logged in, check that your IP address indeed appears in
/etc/hosts.deny (on the server side). If so, then
denyhosts must be the culprit indeed.
See answers to this question for the procedure to prevent
denyhosts to block your address continuously. For
fail2ban find your ip with
iptables -L --line-number and unban you ip with
iptables -D <chain> <chain number>, you check details on howtoforge.
You may want to add your IP address to
denyhosts whitelists (respectively
/var/lib/denyhosts/allowed-hosts, create it if needed (but beware that the path may be different on your distribution)) to prevent the issue to happen again.
On the host server, remove the ssh pub.key located here:
~/.ssh/authorized_keysfor your mac. Then
tail -f /var/log/auth.log while you open another terminal and try to ssh again
ssh -v me@server. If you are prompted for a password then there was a problem with your ssh key. If you are still seeing the ‘ssh_exchange_identification: read: Connection reset by peer’ response, then you should be able to identify what the problem is from the log entry in the ‘/var/log/auth.log’ file after your failed attempt to login.
If you still failed to connect, post the logged entry from the auth file here and I’ll revise my answer.