Don't use passwords for remote authentication

Command line? Bah. Seahorse with Gnome-keyring and ssh-agent provide a more-or-less complete gui-based ssh solution for Linux desktops. Secure remote GUI, secure file transfer, secure terminal access.

One happy accident was that Seahorse used Gnutls so that it was not vulnerable to the OpenSSL issues with Debian. Dumb luck that one, at least on my part.

Certainly you can use command line, I do, but that's not even necessary anymore.

> Create user SSH private keys only on machines you have physical control over, or where local policy prohibits such caution, on a few machines where you have the most confidence of their integrity.

When I can help it I only have ssh keys on one machine. My local workstation. No point in anything else, usually.

I look at it like a spider. My reach goes out to my machines from my laptops. Without the key there is no way for anybody to get access to any of my systems. Only reach out and pull, never push from outside in.

From a personal standpoint ssh does everything.

Which, of course, is why the attacker was very interested in OpenSSH.

------------------------------------------------

As far as firewalls go...

As long as I can get out into the internet over HTTPS then the entire internet is available to me. Such is the magic of OpenVPN... It's virtually impossible to block if you want to allow even proxy-filtered http access. Stick a remote server up to run OpenVPN on port 443, tell it to use TCP, and a couple other options and your done. I use Shorewall for the firewall/router rules. Then I have my own private NAT firewall sitting out there on the internet, hundreds of miles from any network I use.

-----------------------------------

For private networks in private networks with filtering firewalls at the router, as long as they have remote access to ssh on a machine on the inside then it's possible to access any port on any server on that network using Ssh port-forwarding. No special rules required.

I've even done port reversal and opened up holes in networks so I can get remote access to a network that otherwise would of been completely blocked off. (Multiple levels of NAT be damned. If you can get out, they can get in. No question about it. Just need a man (aka Windows XP and Outlook) on the inside.)

So if you have a couple hops to get to a internal server then it's possible to tunnel ssh over ssh via forwarding and keep one session separate from the other, even if it's inside the other. Of course you may run into latency issues that cause such a setup to be to irritating to use in that manner.

That is:

(private network X)|firewall||internet||firewall|(private network Y)

Private Network X has Host A on it.
Private Network Y has Host B and Private Server C.

Now.. Lets assume that:
* Your on 'Host A'.
* The NAT Firewall for 'Network Y' has a pinhole stuck in it so port 22 on host B is exposed to the world.
* You want to get to port 22 on 'Private Server C'

So you ssh from Host A to Host B. Then you setup port forwarding so port 8020 on Host A connects over ssh to port 22 on Private Server C.

Now you can connect directly from the Host A to Private Server C via port 8020 on A's localhost. That is "ssh -P8020 127.0.0.1 " connects directly to "privateServerC:22"

So you see, tunnel ssh over ssh to piggyback while preserving isolation. :) Even if Host B got hacked, they still would not have any access to Server C.

Works very well for any port on any system.