Saiweb

They say necessity is the mother of invention, if this is true then surely the mother of all fuck ups is shoddy customer service, say an isp that will randomly shut down a port because it has high bandwidth usage without asking the customer about it first, and flat out refusing to do anything for 24hrs …

In one of the worst customer service experiences I’ve ever had the miss fortune to have been a part of all access was closed to our in office version control systems due to “high usage”, now this is a pretty essential service as you might imagine, how then to restore access, when the restrictions are beyond your control? (And I mean EVERY inbound port was dead …)

Fortunately it would seem outbound SSH was not affected, so after much vocal drawing and re-drawing many times over on the whiteboard I had a cunning plan …

Using 3 linux devices I would create the following.

1. A device through which using host entries / dns changes the version control would be available whilst not actually running on the box itself.

2. An in house device which would be the device on which the tunnels are created in the first place.

3. The device(s) on which the version control systems reside.

Gateway device

On the gateway device sshd_config needs to be updated with:

And sshd reloaded.

Also if you are using a local firewall (i.e. iptables) you will need to setup the appropriate rules as if the service were running natively on the device

Pivot Device

Generate rsa ssh keys and deploy your id_rsa.pub to the gateway device, (update sshd_config to enable RSA Auth if required)

The tunnel.

Now you only really need to use root if the port you need to gateway is a privileged port (<1024).

Here 10.0.0.1 is the internal address of the device the connection should "pivot" onto.

Once the tunnel was in place the services could be reached via the gateway device, this was essentially a "poor mans" NAT in a time of need, I really do not suggest this for long term use.

Tweet

This is one of those things I find my jaw dropping at, whilst punching myself for not knowing about it sooner.
It’s true as much as I live in the cli & ssh to do my job I find sometimes I require a VNC connection (i.e. the plethora of system-config-* stuff in RH)

Now however there is an alternative (so long as your client machine has x11 installed)

That’s it simple as that, now use a cli command to launch your normal gui tool i..e

And x11 will launch on the machine you are working from, now don’t think the gui is running form your machine it’s not!

your machine is now acting as a thin client simply interacting over SSH, with the gui tool running from the server itself!

And there is where the awesomeness lies, esp if like me you run OSX whilst managing *nix servers.

*grin*

Tweet

This is something I have wanted to get working for some time now, and thanks to James P for passing me a note that as of OpenSSH 4.4 you can infact add command line args for the Subsystem configuration, which when combined with the (I assume new) logging functionality of the sftp-service allows you to finally log what is occuring during an sftp session.

Note: Requires OpenSSH >= 4.4

Replace the susbsystem line in your /etc/ssh/sshd_config with

Add the following to /etc/syslog.conf

Restart the sshd and syslog services, try an sftp upload and review the logs @ /var/log/sftpd.log
Tweet

I should of really written about this ages ago.

SSH Keys allow you to log into a server without the need for passwords by providing a public, private keypair for authentication, you can of course choose to specify a password for the authentication for an added level of security (Allowing you to have one unified login for you servers).

For the general user I would suggest the use of a password for securing the key further, you can forgo this in the case of secured automated processes however. (i.e. server to server backup via scp).

From the client machine:

Generate the key

Follow the prompts to enter your password (or just hit enter for no password).

Copy the key

You must now copy the key to the server you wish to log in to.

Now log into the target server.

Now exit the shell on the target server, and re-login.

If you are prompted to enter a password this should be the password you entered when generating the key, if you did not specify a password you should now be logged into the target server without being prompted for a password.

This process works for both linux and MAC OSX, when generating keys as the client.

NOTE: If you regenerate the key for whatever reason this will replace the olde key pair, and you will need to go through the procedure of copying to the target server again.Tweet