traceroute or tracert in Windows is almost always the wrong tool to use to debug any kind of application, specifically the most known ones, like all based on TCP, with their default settings.
This is because they use by default UDP and/or ICMP packets to trace the path by progressively incrementing the TTL of the packet and expecting each intermediary node hit by a packet reaching a TTL of 0 to reply with an ICMP packet with its own IP address as source, so that it gets detected, and finally for the whole path to be discovered.
This, nowadays, more often breaks than works, and even if it does work the results (specifically the time to answer and the drop percentage) will be almost meaningless and always uncorrelated to the real protocol you wish to debug, like TCP port 22 in your case, for ssh.
Because most networks filter ICMP packets (and often wrongly based on some old attacks that are now myths) and typically route UDP differently than TCP and with different priorities applied.
So the path seen by default can be entirely different, including not available at all, from what the application real traffic would look like.
Hence, I recommend to never use this tool like that (and for the same reason, not ping either). On the contrary any modern one can be passed parameters, like -T --port=22 (sometimes just tcptraceroute $host 22), to force it to use TCP packets, on the specific port you need, 22 for ssh. By doing so you, you will observe exactly what happens when you open your ssh connection (some networks may even apply some filtering for this case, by "detecting" traceroute traffic that is slightly different than normal one, especially if you also do DPI, but this is less often the case than ICMP filtering or different paths/priorities for UDP and TCP).
