Tag Archives: OpenSSH

[Linux] Setting Up a Debian VNC Server (via SSH tunnel)

“and first for something complete different”: Muzaq… coding or administrating system can’t do without gooood muzaq. Check our latest tunes here ;-)

I. Abstract

No doubt, configuring a web server won’t work without being in the know of basics about the terminal, vim or nano. Anyway many tasks can also be performed by administrating a server using a GUI. The problem is: only Windows 2003 or Windows 2008 come with a preinstalled remote desktop connection – and they are really much more expensive than Linux solutions. When using our beloved and most stable Linux distribution Debian, it mostly comes preinstalled with almost nothing.

The following article assumes, you have a server, which can be managed via ssh rather than by physically access. We will show you how to setup a GNOME desktop on that server and virtually connect to that desktop using an SSH tunnel.

In case you are running a client machine with:

  • Linux or Mac OS X, just keep on reading, all tools come onboard
  • MS Windows, please install Cygwin with the openSSH package first
    (Note: you may also use the Putty/Pageant combo instead, but this will require some different steps. The following article is straightened to using Cygwin, because we feel it’s got several client sided advantages in contrast to Putty)

II. Preparations

First of all: log into your server via SSH as root. Make sure openSSH has been updated, a serious security flaw has been discovered some days ago concerning Debian based Linux distros. Make also sure you have secured your SSH access. We really recommend public-, private-key crypto for ssh login.

III. Update and Upgrade your server with current packages

Being logged into your server as root, do the following:

  • server$ apt-get update
  • server$ apt-get upgrade
  • server$ apt-get dist-upgrade

to upgade your whole installation.

IV. Installing GNOME

After having done a dist-upgrade we are used to reboot the servers. This might not be necessary in all cases and might be a strange obsession from ancient MS Windows times, but we would recommend it to allow all scripts to become initialized anew.

After reboot login as root again and do the following:

  • server$ apt-get install gnome-desktop-environment

V. Install fonts for GNOME and VNC

Install some (required) fonts for the VNC server GNOME session:

  • server$ apt-get install xfonts-100dpi
  • server$ apt-get install xfonts-100dpi-transcoded
  • server$ apt-get install xfonts-75dpi
  • server$ apt-get install xfonts-75dpi-transcoded
  • server$ apt-get install xfonts-base

VI. Install VNC server

We prefer TightVNCServer, simply because it worked from the very beginning…

  • server$ apt-get install tightvncserver
    (installs TightVNCServer)
  • server$ tightvncserver :1
    (initialize the VNC server for the first time, it will copy some files to ~/.vnc folder and it will ask twice for a VNC password – we recommend to provide it for your own safety)
  • server$ tightvncserver -kill :1
    (stop VNC server – for further configuration purposes)

VII. Configure VNC server

In this example we’re gonna use nano, you can also use vim, vi or whatever you think what editor fits your needs best:

  • server$ nano ~/.vnc/xstartup

We need to change the standard X-Windows interface, since we like to use GNOME.

Original xstartup file:

  • #!/bin/shxrdb $HOME/.Xresources
    xsetroot -solid grey
    x-terminal-emulator -geometry 80x24+10+10 -ls -title "$VNCDESKTOP Desktop" &
    x-window-manager &

Change this to

  • #!/bin/shxrdb $HOME/.Xresources
    xsetroot -solid grey
    x-terminal-emulator -geometry 80x24+10+10 -ls -title "$VNCDESKTOP Desktop" &
    # x-window-manager &

    gnome-session &

Save and exit nano (ctrl + x).

VIII. Setup an SSH tunnel for VNC connections

VNC connections are usually to be found on port 5901. Usually they are not encrypted on that port. That means you send the VNC password unencrypted thru the net to that port. Since this allows too many attacks, it is just too weak for a web server solution.

We don’t want to provide possible Zombies. So the solution is: we just setup an SSH tunnel as a wrapper for our VNC connection. Further information about SSH tunneling can be found here and here.

On your client machine do the following:

  • client$ ssh -f -N -L 5901:localhost:5901 root@yourserver.net

In case you changed the ssh port on your server (like we recommended in our article here), you need to specify your ssh port for the SSH tunneling aswell, like:

  • client$ ssh -f -N -L 5901:localhost:5901 root@yourserver.net -p 8722
    (in this case we use port 8722 instead of the standard port 22)

IX. Connect to your server via VNC

Start tightvnc on your server:

  • server$ tightvncserver :1

In case you like to have a different screen resolution than 1024×768 you may start tightvnc with:

  • server$ tightvncserver -geometry 1280x1024 :1

On a Mac the VNC client is called Chicken of the VNC (Download here). On Windows you can use RealVNC (Download here). Both work quite similar and contain almost the same features.

Use the VNC client (like Chicken of the VNC) to connect to your SSH tunnel,

  • connect to localhost (or 127.0.0.1)
  • display 1, because of port 5901 (display 0 would be port 5900)
  • enter your VNC password
    (the password, that has been setup in step VI. Install VNC server)

 

  • hit connect and
  • you should see something like that (on vservers the performance may be kinda slow and GNOME’s GUI may take some time to initialize).

Congratulations, you’re done.

X. Stopping VNC session and SSH tunneling

You can simply quit the VNC session by just closing your VNC client. But the SSH tunnel from your client to your server will still be up until you stop it (means until you kill it). We may provide a simple script to do that when we finished cleaning it up. Right now it is kinda spaghetti code. Although this is not too comfy, you may live with a simple command until then:

  • client$ killall ssh

It simply kills every SSH process :-)

XI. Final words

We hope you enjoyed our trip into the amazing VNC worlds on Debian and also hope you learned something. You could now setup a firewall like firestarter, which is GUI driven. We will publish some words about this in the early future.

And of course, you are still invited to consider our sponsor (Google-Adsense) and help us maintaining this project here free. Thanks…

[Linux] Severe SSH security issues in Debian

I. Abstract

It has been found by Luciano Bello that the Debian OpenSSL package has a severe security bug since 2006. By removing some lines of code from the md_rand.c source code that originally caused the memory check tool Valgrind to alert (see original Debian discussion here) the box of pandorra has been opened and the flaw been introduced.

By removing that specific part of the OpenSSL code, effectively the random seed function has been crippled, and eventually the only random value remaining was the current process ID. Since on linux only a maximum no of 32,768 process IDs exist, the worth of this pseudo random number generator (PRNG) is heavily limited.

Update: a set of instructions has been added under IV. How to fix/repair your server (click here).This shows the steps to a secure server with new SSH server side keys.

Update II: a new fix has been released as of May, 16th (4.3p2-9etch2). You should therefore apply step IV. again to upgrade your SSH package to the recent version.

II. Impact

As a summary based on infos from metasploit.com.

  • Debian based distributions are affected aswell (i.e. Ubuntu, Kubuntu, Xubuntu, Edubuntu, Gobuntu etc. pp)
  • SSL and SSH keys generated between 09/2006 and 05/2008 are vulerable to brute force attacks
  • SSL certificates need recreation and signed again by Certificate Authority
  • Certificate Authority keys need to be regenerated and revoked.
  • SSH public key authentication on other distributions than Debian may be affected aswell when keys have been generated on Debian systems
  • SSH servers using host keys generated on Debian are vulnerably to man-in-the-middle attacks

III. Testing for weakness and vulerability

Debian released a program for testing the vulnerability of keys. Download it here (see OpenPGP signature). You may do the following. Log into your server as root and do:

  • server$ wget -c http://security.debian.org/project/extra/dowkd/dowkd.pl.gz
  • server$ gunzip dowk.pl.gz
  • server$ chmod 700 dowk.pl
  • server$ ./dowkd.pl host 127.0.0.1
    (checks your local SSH host keys)
  • server$ ./dowkd.pl user
    (checks all users available on your system)

Vulnerabilities will be reported. Nonetheless we recommend to apply step IV. How to fix/repair your server (click here).

Before reading on: if this article helps you, please click our non-offensive sponsor (Google-Adsense) and help us maintaining this project free. Thanks…


IV. How to fix/repair your server

Log into your server as root and perform the following steps:

  • server$ apt-get update
  • server$ apt-get upgrade
  • server$ apt-get dist-upgrade

The OpenSSH and OpenSSL packages will be updated then. You will be asked a couple of questions concerning your server configuration. It should be fairly self explaining.

The server side SSH keys (known_host keys on your local machine) will be regenerated. If you still don’t trust your server, you can check your new host keys for vulnerability by entering this:

  • server$ ssh-vulnkey
    (the response should be Not blacklisted)
  • server$ ./dowkd.pl user
    (if this reports weak keys read on)

Login as user whose keys have been recognized as weak and do the following:

  • server$ ssh-keygen -t dsa -b 1024
    (provide passphrase!)

You should be done now.

V. Tools

H.D. Moore of metasploit.com already prepared Debian toys and rainbow tables (pre-generated keys) for all possible 32,768 PIDs with up to 4096 bits in keysize that may be used for testing the brute force vulnerability of your systems.

VI. Links:

» debian.org: Security Advisory DSA-1571-1 openssl
» debian.org: Security Advisory DSA-1576-1 openssh
» debian.org: Vulnerability test tool… (OpenPGP signature)…
» metasploit.com: OpenSSL Rainbow Tables

[Linux] Workaround for SSH buffer error

I. Abstract
Some of you may already have experienced the same phenomenon. We wanted to secure one of our servers and disallow any password login. We configured the passwordless login to use ssh and use public-, private-key mode (see here) instead. But after having saved the sshd_config file, we eventually couldn’t reconnect to our Debian server from our Cygwin console. Instead we received a buffer error. The following lines show what we did and a somewhat not 100% clean workaround.

II. What did we do?

  • we set up a Debian Etch server to use Public and Private Key authentication only (see here how to do it)
  • we edited the sshd_config
    server$ nano /etc/ssh/sshd_config
  • we set
    PasswordAuthentication No
  • we saved sshd_config and quit vim
  • we restarted out beloved ssh deamon
    server$ /etc/init.d/ssh restart
  • we then logged out and found that we cannot login by entering
    client$ ssh -o PreferredAuthentications=publickey root@somedomain.com
  • arghhhhh…

III. Workaround

  • we examined the errors:
    buffer_get_ret: trying to get more bytes 4 than in buffer 0
    buffer_get_int: buffer error
  • After fumbling here and there we just removed the known_hosts file on the local client
    client$ rm ~/.ssh/known_hosts
  • we reauthorized the domain and guess what?
  • The error vanished
  • obviously the known_hosts was modified to have a line break somewhere in the middle of the public-key. I suspect openSSHp to have caused this incident

If the above solved your problem aswell, please help us maintaining this site by visiting our sponsors:

IV. Sponsored by