Ssh – Measure total latency of SSH session

Which ISP are you using? That info might be useful as other people on the same ISP may be able to confirm the behaviour (as they have the same problem) or report all is well for them (indicating that the ISP doesn't have a general problem with SSH traffic).

One possibility if it is the ISP, is that they've changed their traffic management structure and it is mistaking your encrypted SSH connection as an encrypted P2P connection. If you can turn off the web server at the other end temporarily without causing to much trouble, try running SSH on port 80 to see if it runs better that way (if it does then something somewhere is probably doing port based traffic shaping that is affecting SSH). You could also try a bulk transfer via SSH (i.e. a download via SCP/SFTP) running through a HTTP based tunnel like this one to see what difference it makes (it will need to be a bulk transfer, as otherwise any performance issues will be hidden by the extra latency added by the tunnel).

If you have a generic setup for SSHD, it's just a matter of telling your Linksys router to forward TCP port 22 to the IP you want access to internally, then from the outside ssh to the static IP, and you'll want to have the machine internally running ssh to have a static IP assigned, not a dynamic (DHCP) address.

Personally, I would change the port to another port not used on your machine, as a nonstandard port makes it more difficult for bots to scan you (And it will happen). But that's up to you. If you use the standard port, you need to be more careful with passwords and usernames, and don't allow root to log in to that port, and you may want to consider installing Denyhosts to block ip's that give an incorrect password 3 times automatically.

Make sure your VM (I assume that's where you are running sshd?) is assigned it's own IP and is using bridged networking so it's not natted twice. That's asking for a world of hurt (nat behind the router, then natted again behind the Leopard machine's VM software). Bridged networking makes the machine appear as if it were another physical machine in your network from the logical view.

You don't necessarily need to set up ssh on the server to a nonstandard port...you could set up a nonstandard port on the router to forward to the internal machine's port 22, if your router supports non-one-to-one mapping (i.e., forward external port 26 to internal port 22 on 192.168.xxx.xxx...), so that only machines outside your network need to use the nonstandard port assignment. But my personal preference is to alter the SSH port on the inside just to tick off bot-scanners.

To sum up...tell your linksys to forward port 22 (or what you choose to use) to your VM's IP. I recommend using a different port, though. Make sure your internal VM machine is using a static, not DHCP, ip address on your internal network, so reboots don't break the forwarding map. Then it's a matter of ssh'ing to your external static IP from an external system to test it. I also recommend using denyhosts if you stick with default port 22 to ban probes. Make sure your VM instance is running bridged, not NAT, networking on the host computer.