SSH issue are not problem at Mikrotik router but ISP problem.
I have switched ISP - from laggy, lossy LTE to cable Internet.
Without changing anything in configuration (except WAN interface), SSH works again.
LTE Internet latency over 100ms with at least 10% packet loss
Cable Internet 10-20ms (local vs worldwide)
My guess is my SSH server simply dropped connection due crap connection and timeout. Fasttrack bypassed firewall and most likely connection timeout was already on the limit…with fasttrack off…connection timed out.
I have this problem as well. SSH negotiates everything it needs with the server, but times out when opening the final channel.
It only works when activating fasttrack for the connection in the firewall.
I haven’t done extensive testing yet, but I can share a few observations:
Somehow this only affects linux clients
Ubuntu PC (ethernet) and Ubuntu Notebook (wifi): ssh client does not work
Windows VM running on Linux (virtualbox on ubuntu, bridge interface): Putty does NOT work
Windows PC: SSH works from Putty and WSL
connecting to an ssh server over VPN works
This started to happen suddenly after upgrading to 7.1beta2 (from stock 7.0beta6), but I still have it with 7.0beta8 (had to downgrade because of routing issues)
Fasttrack solves the problem
My internet connection is flawless (thanks to the fantastic Chateau)
There is a serverfault thread with exactly the same issue, just not mkrotik related. I tried about everything suggested there. The only fix/workaround in my case is fasttrack.
I’ve the same issue - with LMT Mikrotik LTE18 router. Despite “fasttrack” turned on - SSH doesn’t work.
Average latency on LTE connection is 13-25ms. Before that I was using Huawei LTE modem and everything worked fine. So that should be Mikrotik RouterOS related issue.
I’m running standard RouterOS v7.0 that came on the router. Didn’t tried upgrade to beta or development.
I recently got 7.0beta6 from mikrotik support and downgraded my Chateau, but SSH was still not working without fasttrack. This is getting strange now.
I upgraded back to 7.1beta2 and now SSH was not even working with fasttrack. 7.1beta1 is working (with fasttrack) again.
Additionally, with the fasttrack workaround ssh connections have lots of TCP retransmissions, which make the connection lag. Folder listings and longer output in general hangs after a few lines until i press a key to make ssh notice the lost packets. This looks like a typical MTU issue, but it’s not. I tried with many MTU sizes, even very small ones like 900.
Everything works fine over a VPN connection established from the PC (tried ssl-vpn to the office and a commercial vpn provider).
I will try to do some tests with ssh debugging and wireshark later and report back.
Today router suddenly stoped working at all. After reboot - just power lights on and nothing else happens.
UPDATE:
Actually there is happening something. Rooter reboots itself every ~30 seconds, but after that stays in the same “power on” mode.
UPDATE 2:
Turned out the router was dead, so I returned yesterday to LMT and got another one in exchange. And in this new one situation is the same - no SSH is passing through.
please contact LMT support so they could update your router with the new test RotuerOS version that could potentially fix this problem.
If that doesn’t help then please provide some information how we could reproduce this problem locally. We could try to reproduce this problem locally if you could tell where we need to try to make the SSH connection. You can send that information to the support@mikrotik.com and refer to this Forum topic.
The issue I have is that ssh to a server on the internet. It aborts with “broken pipe”
As you can see in the ssh -v debug Info, it stops in the last phase
OpenSSH_8.1p1, LibreSSL 2.7.3
debug1: Reading configuration data /Users/ch/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 47: Applying options for *
debug1: Connecting to ********.com port 22.
debug1: Connection established.
debug1: identity file /Users/ch/.ssh/id_rsa type 0
debug1: identity file /Users/ch/.ssh/id_rsa-cert type -1
debug1: identity file /Users/ch/.ssh/id_dsa type -1
debug1: identity file /Users/ch/.ssh/id_dsa-cert type -1
debug1: identity file /Users/ch/.ssh/id_ecdsa type -1
debug1: identity file /Users/ch/.ssh/id_ecdsa-cert type -1
debug1: identity file /Users/ch/.ssh/id_ed25519 type -1
debug1: identity file /Users/ch/.ssh/id_ed25519-cert type -1
debug1: identity file /Users/ch/.ssh/id_xmss type -1
debug1: identity file /Users/ch/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.1
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.9p1 Debian-10+deb10u2
debug1: match: OpenSSH_7.9p1 Debian-10+deb10u2 pat OpenSSH* compat 0x04000000
debug1: Authenticating to ***.com:22 as 'ch'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256@libssh.org
debug1: kex: host key algorithm: ssh-ed25519
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ssh-ed25519 SHA256:wxLJ.....
debug1: Host '*****.com' is known and matches the ED25519 host key.
debug1: Found key in /Users/ch/.ssh/known_hosts:1
debug1: rekey out after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey in after 134217728 blocks
debug1: Will attempt key: /Users/ch/.ssh/id_rsa RSA SHA256:f1XWK....
debug1: Will attempt key: /Users/ch/.ssh/id_dsa
debug1: Will attempt key: /Users/ch/.ssh/id_ecdsa
debug1: Will attempt key: /Users/ch/.ssh/id_ed25519
debug1: Will attempt key: /Users/ch/.ssh/id_xmss
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,ssh-rsa,rsa-sha2-256,rsa-sha2-512....
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering public key: /Users/ch/.ssh/id_rsa RSA SHA256:f1XWKDZEy......
debug1: Server accepts key: /Users/ch/.ssh/id_rsa RSA SHA256:f1XWKDZEy......
debug1: Authentication succeeded (publickey).
Authenticated to *****.com ([*.*.*.11]:22).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: pledge: network
debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0
debug1: Remote: /home/ch/.ssh/authorized_keys:1: key options: agent-forwarding port-forwarding pty user-rc x11-forwarding
debug1: Remote: /home/ch/.ssh/authorized_keys:1: key options: agent-forwarding port-forwarding pty user-rc x11-forwarding
debug1: Sending environment.
client_loop: send disconnect: Broken pipe
Everything else, web, email, … is working fine. with the Huawei router everything was fine. So no issue at provder or SSH server.
We have confirmed from few customers that the RouterOS v7.0.1 test that was provided for the LMT fixes the SSH issue as well.
This fix will be included also in the RotuerOS v7.1beta3.