Coredump

At work, I connect to remote servers through SSH. Sometimes, I use Hummingbird Exceed to forward X and xterm sessions to colleagues. Hummingbird is not only proprietary, but also prohibitively expensive, so I use the open source alternative at home: XMing.

In PuTTy, I enable X11 forwarding in the config (Connection > SSH > X11). In /etc/ssh/sshd_config on the remote host, I set up the following:

X11Forwarding yes
X11DisplayOffset 0

and do a service sshd restart. Once Xming is fired up and I’m connected to the remote box, I can issue something like xclock &, and the app gets displayed in my Windows machine:

I sometimes telecommute. And when I badly need some files on my office desktop, I can connect remotely through the company’s SSH gateway and tunnel RDP to my desktop. Here’s how:

1. Using PuTTY, create a new session for the SSH gateway.
   
2. In Connection > SSH > Tunnels, add a new forwarded port: the source can be an arbitrary port number (e.g. 4444) and the destination should be the address of the remote desktop with the port set to tcp/3389 (the RDP port). Make sure the “Local” is selected because we will be forwarding the local port (4444) to the remote desktop’s port (remote.desktop:3389).

   

3. Connect and log in in the SSH session. (We use one-time RSA SecurID passkeys, so I always keep that nob handy.)
4. In Windows XP (yes, my notebook is still not free), open up Remote Desktop Connection, add connect to localhost:4444. This should then be forwarded through the SSH session to the remote desktop port 3389.

   

5. You would have to authenticate again, and if all goes well, you’ll be presented with your remote desktop.
   

Steps 1 and 2 above can also be achieved from the command line, using Plink:

C:\> plink -N -L 4444:remote.desktop:3389 user@ssh.server.org

Take note that the SSH gateway must be able to forward tcp/3389. (Setting that up is beyond the scope of this post. ;)) It would have been great if the VNC port (tcp/5900) was set up as well, but unfortunately, only RDP is allowed. So to connect to my Linux box at work, I either use SSH or, in the remote desktop, open up TightVNC. It looks a bit surreal: having a remote desktop within a remote desktop.

I’ve worked with lots of servers, most of which I cannot access directly, so I often use remote access: Remote Desktop Connection or Terminal Services in Windows, and ssh in *nix.

While I do have PasswordSafe to remember all those passwords, I’m the lazy admin type, so I often opt for password-less authentication using public keys. For this, I use PuTTY, et. al.

1. First, I generate an RSA key using PuTTYgen. I don’t enter anything for the passphrase. Warning: NOT recommended for production servers!
2. I save the public and secret keys (in .PPK format) in a directory. I also cut and paste the RSA string in a text file, key.txt.
3. For now, the remote box is configured for “normal” ssh, that is, through password authentication. So, I copy over the RSA string file to the remote box:

   C:\> pscp \path\to\key.txt user@remote-host:/home/user/.

I log on to the remote host using PuTTY, and do the following:

$ mkdir .ssh
$ mv key.txt .ssh/authorized_keys
$ chmod 700 .ssh; chmod 600 .ssh/authorized_keys

4. I also edit the SSHd config file, /etc/ssh/sshd_config, with the following parameters:

   RSAAuthentication yes
   PubkeyAuthentication yes
   AuthorizedKeysFile     .ssh/authorized_keys
   PasswordAuthentication no
   PermitRootLogin no

5. SSHd is then restarted.
6. Back in Windows, I launch PuTTY, and enter the host name for the remote box. In the SSH/Auth category, I place the private key file saved earlier. I save the session, named remote-nopass.
7. I then launch Pageant, drill down to Saved Sessions > remote-nopass. It will bring up the SSH login page, where I enter my login name, after which, I am authorized through the pubkey, and log in to the SSH session.

Seems tedious at first, but I can then export key.txt to other remote servers, and just save sessions for Pageant’s use. Pageant is conveniently located in the system tray within reach.

Add this to the iptables ruleset:

iptables -A INPUT -m hashlimit -m tcp -p tcp --dport 22 --hashlimit 1/min --hashlimit-mode srcip --hashlimit-name ssh -m state --state NEW -j ACCEPT

The rule limits one connection to the SSH port from one IP address per minute.

For more information, man iptables and iptables -m hashlimit --help.

Reference: https://www.redhat.com/archives/fedora-test-list/2005-August/msg00061.html