I have a small lab at home, and periodically need to gain console access to one or more of the machines. Since I don’t have a KVM switch or a monitor to devote to each machine, I will typically hook up a serial cable to port A on machine one, and serial port B on machine two. Once the connection is in place, I use minicom or tip to connect to node one once I establish an SSH session to node two. Since tip and SSH both default to using “~” as the escape character, issues will arise if you need to send a break remotely. To avoid this issue, I always use the ssh client’s “-e” (escape character to use) option to set an escape character that doesn’t conflict with tip:
$ ssh -C -e ^ host
This caused me some grief today, since the box I was SSH’ed into didn’t have my .profile installed (my default profile contains an ssh alias with “-e”). Tip is c-well!
I was reading through O’Reilley’s OnLamp today, and came across their interview with the OpenBSD developers. In the interview, Dave Miller discussed the new features in OpenSSH 4.X, and described the following awesome new feature:
Added the ability to store hostnames added to ~/.ssh/known_hosts in a hashed format. This is a privacy feature that prevents a local attacker from learning other hosts that a user has accounts on from their known_hosts file.
So instead of hostnames being stored in plain text like:
> yourhost.example.com ssh-rsa
They are hashed first, so they don’t reveal the hostname. E.g.:
> |1|bRGYyrC+bfKZGGd5GZH4wo1AnsI=|xcQ+54QNVwQ+fBCldn0= ssh-rsa
We added at the request of some MIT researchers who found that a substantial number of user private keys on shared systems are not encrypted (a really dumb thing to do, BTW). This lack of user care, coupled with the information in the known_hosts files, allowed attackers to spread their attacks to multiple systems.
Right now this is disabled by default, but administrators of sites with lazy users can turn it on with the HashKnownHosts
If you do this, you should probably also hash your existing known_hosts file (ssh-keygen -H).
I sometimes think I am the only person that uses ssh-agent to store private keys in memory, and strong complex passwords to protect keys on disk. While a competent attacker would use a packet analysis tool to find SSH destinations, this may protect admins in select situations.
Ever wonder how you can tunnel web and AIM traffic securely from one location to another? This can be accomplished with ssh’s “-D” option. This allows traffic to be sent securely over a SSH session, and routed out through a remote endpoint. This looks like:
Firefox/GAIM < -- HTTP/AIM--> loopback:PORT < -- SSH --> REMOTE END < -- HTTP/AIM --> Internet
To create a local proxy on TCP port 8000, we can pass the value 8000 to the “-D” option:
$ ssh -C -D 8000 -p 443 firstname.lastname@example.org
Once the SSH connection is established, you need to configure your client (e.g., firefox, gaim) to proxy connections to the loopback interface on TCP port 8000. Once your clients are configured to use the localhost.8000 listener, all application traffic will be sent securely through your ssh session, and routed through the Internet connection on the remote end.
Since most web proxies tunnel secure connections, you can setup your remote endpoint to accept SSH connections on TCP port 443. This is amazingly useful for routing around corporate firewalls and proxies. You don’t want to get caught looking for jobs while your at work, right? ;)