A good news story… courtesy of LogMeIn

Posted on By Mark Wilson
This content is 16 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

A few days ago, one of my colleagues was telling me about how his father’s stolen laptop has been recovered. I’m leaving out the names (for privacy reasons) but it’s a good news story for the end of the week.

In common with many IT workers, my colleague provides technical support for family members and, to make this easier, he had installed LogMeIn. There are any remote control products available (I just use standard RDP/VNC connections) but the advantages of some of the specialist products include NAT traversal (and other firewall-friendly functionality) and, it seems, alerting when a PC is available (or not).

After his father’s PC was stolen, my colleague started to build a new one for him, so, imagine his surprise when the original machine appeared online! Using the remote control software, he was able to identify the user as they browsed a social networking site and then provide the police with fairly conclusive evidence as to who was using the machine.

In the words of my anonymous friend:

“Go technology…”

Thanks to his use of the LogMeIn software and the user browsing a social networking site (in the process revealing their identity) the computer was recovered and three people spent some time in the custody of the local police force (although I understand the actual recipient of the computer was later released with a caution).

Maybe I’ve finally found a use for social networking websites!

Changes to the Microsoft Remote Desktop Connection command line switches

Posted on By Mark Wilson
This content is 17 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

Garry Martin alerted me to a useful piece of information this morning…

It seems that the /console switch introduced to the Remote Desktop Connection client in Windows Server 2003 has been deprecated in Windows Server 2008 (and Windows Vista SP1). It fails silently (so you still think that you are connected to the console session) but closer inspection reveals that a different session number is in use.

The replacement command is mstsc /v:servername /admin – John Howard has more information on his blog.

Connecting to a Linux server using VNC

Posted on By Mark Wilson
This content is 17 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

Many of my computers are not in my office/den but are providing server functions for which the need to access them directly is rare. When I do need access to the Windows machines, I can connect to them using a variety of RDP clients; for my Red Hat Enterprise Linux (RHEL) 5 box it’s a similar situation but this time using SSH (for command line access) or VNC (for a GUI).

Although RHEL includes a VNC server and I’d opened up TCP port 5900 in the firewall configuration (using system-config-securitylevel), for some reason I was still having problems creating a VNC connection and it turns out that there were two main reasons for this.

  1. Each VNC display will use a new port number, so display 0 is on 5900, display 1 on 5901, etc. I was trying to connect on port 5900 but it’s not as simple as opening the port – I needed to start a session with vncserver (supplying a password if required – the vncpasswd command can also be used for this), then note the port number (open the appropriate firewall ports) and connect from my chosen VNC client.
  2. For connection to an existing logged on console session on the server running a graphical environment (display 0), it’s necessary to enable this in the Remote Desktop preferences:

Remote Desktop PreferencesOnce I’d got around this, it was fairly straightforward to connect to display 1 on port 5901 but the default display was using the rather dated Tab Window Manager(TWM) GUI (although starting GNOME applications like gedit applied the GNOME look and feel to that application’s window. By editing the /root/.vnc/xstartup file I could comment out the twm & line and replace it with startx &; however, because there was already an instance of X running on the server (for display 0), I found that the startx & command failed and I needed to use gnome-session & in its place. I also commented out the line starting with xterm and included gnome-terminal & at the end of the script so my xstartup file now reads:

#!/bin/sh

# Uncomment the following two lines for normal desktop:
# unset SESSION_MANAGER
# exec /etc/X11/xinit/xinitrc

[ -x /etc/vnc/xstartup ] && exec /etc/vnc/xstartup
[ -r $HOME/.Xresources ] && xrdb $HOME/.Xresources
xsetroot -solid grey
vncconfig -iconic &
# xterm -geometry 80x24+10+10 -ls -title "$VNCDESKTOP Desktop" &
# twm &
gnome-session &
gnome-terminal &

Just for completeness, here are a few more notes that might be useful:

  • Use chkconfig --list to check whether the VNC server service is started by default (if necessary, use chkconfig --levels 5 vncserver to make it start in run level 5 in future).
  • If not already running, then start the service with service vncserver start.
  • Kill VNC desktops with vncserver -kill :displaynumber.
  • VNC sessions may be tunnelled through SSH for a secure connection.

Microsoft’s MacBU is moving in the right direction, just not fast enough

Posted on By Mark Wilson
This content is 17 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

Office for Mac product iconsA few weeks back, I wrote about the frustration of working (or rather not be able to work) with Open XML documents on a Mac. Some wag even pointed out on a recent podcast that Apple beat Microsoft to provide support for its own document formats in the new iWork 08 application suite. I hear good things about iWork and it’s very reasonably priced (especially when compared to Microsoft Office) but I work with Microsoft Office 2007 on Windows and need something functionally equivalent for the Mac so I’m sure I’ll be getting a copy of Office 2008 for Mac in due course (attempts to get a beta invitation have failed dismally). There is light at the end of the tunnel though – since my original post, the MacBU has released a (time-limited) beta of the Microsoft Office Open XML File Format Converter for Mac, so that at least gives me something to work with for now (the previous version was only for Word documents).

Mac RDC logoAnother new product from the MacBU is (at last) a universal binary version of the Remote Desktop Connection Client for Mac. I’ve been beta testing this and whilst it’s far more stable on an Intel Mac than the old version, it still doesn’t seem to offer something that I need – support for multiple client connections. I’ve provided feedback on this (others were less charitable in their contributions). In the meantime, I’ll be sticking with CoRD.

It seems that the MacBU is releasing new products but at an almost glacial pace. I don’t care that it’s been 4 years between Office releases – there was a similar gap for the Windows product – but surely the file format converters could have been ready when Office 2007 shipped on Windows. Similarly, based on what I’ve seen with the Microsoft’s RDC client for the Mac, it’s not exactly worth waiting for.

Remote Desktop alternative for Mac users

Posted on By Mark Wilson
This content is 17 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

I frequently connect to Windows hosts from my Mac and I have been using the Microsoft Remote Desktop Connection client for Mac OS X. The trouble with this is that it only allows a single connection and it’s not a universal binary (it also has a tendency to crash on exit, requiring a forced quit). I use rdesktop on my Linux boxes, and figured it ought to be available for the Mac (it is, using fink, or by compiling from source) but I also came across CoRD (via Lifehacker) and TSclientX (via the comments on the Lifehacker post) – both of which seem to offer a much richer user experience:

  • CoRD allows multiple RDP connections as well as storing login credentials. It seems pretty responsive too.
  • TSclientX s essentially a GUI wrapper for rdesktop and therefore requires X11. That shouldn’t really be a problem but it does sometimes feel like a bit of a kludge – even so, it has the potential to be extremely useful as it supports SeamlessRDP. Unfortunately, SeamlessRDP requires additional software to be present on the remote Windows system and I couldn’t get it to work for me, possibly because I was connecting to a Windows XP machine (which only supports a single connection) and rdesktop creates a X11 window for each window on the server side.

At the moment, I’ve settled on CoRD, largely due to its ease of use but both clients seem to offer a great improvement over Microsoft’s RDP offering for Mac users.

SSH addendum

Posted on By Mark Wilson
This content is 18 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

Since my recent posts about using SSH to securely remote administer Mac OS X, Linux and Windows computers, a couple of extra points have come up that are probably worth noting:

  • To use the console interactively, it may be better to use PuTTY (putty) than PuTTY Link (plink). In seems that PuTTY Link is fine for setting up a tunnel and then connecting using VNC, RDP or another remote control method but I found that control codes were echoed to the console window when I connected to a Linux of Windows computer and the command line experience was generally better using PuTTY interactively. This is because (quoting from the PuTTY documentation) “The output sent by the server will be written straight to your command prompt window, which will most likely not interpret terminal control codes in the way the server expects it to […] Interactive connections like this are not the main point of Plink”.
  • For another method of generating SSH keys, an online SSH key generator is available (I haven’t tried it myself).

Secure, remote administration of a Windows computer

Posted on By Mark Wilson
This content is 18 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

I was going to call this post “secure, remote administration of a Windows computer from within Windows” but that sounds a bit odd, unless you realise that the last two posts have been “secure, remote administration of a Linux computer from within Windows” and “secure, remote administration of a Mac OS X computer from within Windows“. Basically, after getting SSH tunneling to work for administering Mac OS X and Linux machines, I thought that it would make sense to apply the same principles to Windows.

John Fitzgibbon’s comparison of free SSH and SCP programs for Windows 9x, NT, ME, 2000 and XP explains the various SSH server options for Windows but one option he doesn’t mention is Tevfik Karagülle’s CopSSH, which I found on a list of free SSH implementations recommended by OpenSSH.

CopSSH bundles parts of OpenSSL, OpenSSH and Cygwin into a Windows installer. It’s straightforward to install, and includes a GUI interface to activate a user for SSH, including the generation of a public/private key pair (saved to %programfiles%\copSSH\username\username.key and %programfiles%\copSSH\username\username.key.pub). The private key needs to be imported into PuTTYgen after which it can be saved in PuTTY’s .PPK format and used as previously described for Mac OS X and Linux. The only other point to note is that the sshd_config file is stored in %programfiles%\copSSH\etc and requires the same AllowTcpForwarding yes and PasswordAuthentication no settings as seen previously.

To access the desktop via VNC, I installed UltraVNC Server on the target machine noting there are two settings that need to be configured for a successful connection through the SSH tunnel:

  • A password must be defined for VNC connections.
  • Loopback connections must be allowed.

That’s fine for using an SSH tunnel to secure a VNC session, but why not tunnel remote desktop (RDP) connections to Windows servers instead of using VNC? In theory, all that should involve is changing the forwarded source port from 5900 (VNC) to 3389 (RDP) and setting the corresponding SSH port forwarding destination to localhost:3389 but Windows doesn’t like that, producing an error message as follows:

Remote Desktop Disconnected

The client could not connect. You are already connected to the console of this computer. A new console session cannot be established.

One suggested fix is to change the destination to use another address from the loopback range (e.g. 127.0.0.2) but I found this just directed me to my own machine (as might be expected with a loopback). For a while, it looked as though the resolution would be related to a change made in Windows XP service pack 2, which prevents connections to loopback addresses other than 127.0.0.1, and Microsoft knowledge base article 884020 includes a hotfix that alters this behaviour but I don’t think it helped me much (I later removed the hotfix and didn’t notice any differences). Eventually I got things working by creating a new forwarded source port of 3390 and destination of localhost:3389 for SSH port forwarding, after which I could connect using mstsc /v:loopback:3390.

It’s been an interesting few days getting acquainted with using SSH tunnels to securely connect to remote systems running a variety of operating systems – hopefully posting my experiences here will be useful to others.

Secure, remote administration of a Linux computer from within Windows

Posted on By Mark Wilson
This content is 18 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

Yesterday I wrote about using SSH to securely connect to a Mac from a Windows PC. At the time, I suggested that the advice should be equally applicable to a Linux system, or even to a Windows Server with an SSH server installed and I’ve since tested it with a Linux machine (running Fedora Core 5).

The Linux process is almost identical to my original post for Mac OS X, except that:

  • The sshd_config file is found in /etc/ssh.
  • SSH is enabled in the firewall using the system-config-securitylevel command.
  • The SSH deamon is restarted using the service sshd restart command.
  • GNOME includes a VNC server called vino, which needs to be enabled (users of other graphical environments will need to choose an alternative VNC server).

(Also… RTFM… I spent a lot of time trying to work out why I couldn’t connect, only to find that I’d neglected to place the public key in ~/.ssh/authorized_keys).

Falko Timme has written an excellent tutorial on key-based SSH logins with PuTTY which outlines all the key steps (in fact, if I knew that existed then I wouldn’t have spent so much time writing up the process here!) but Jeremy Mates’ OpenSSH public key authentication article includes a useful troubleshooting guide for public key authentication problems.

VNC is all very well for forwarding the entire desktop, but X11 forwarding can be used to run individual X applications on the Windows machine. Because Microsoft Windows doesn’t include an X Window server, it is necessary to download an X11 port for Windows – I used XMing. Once XMing (and the XMing fonts) were installed and running, I edited my PuTTY connection to enable X11 forwarding and ensured that the sshd_config file on the Linux box included X11Forwarding yes (that was the default on my Fedora Core 5 installation) and could launch an xapplication from within the PuTTY terminal window with xapplicationname & (e.g. xeyes &) (I found this information at the Linux Documentation Project). XEyes is nothing special, so how about running a Linux application on the Windows desktop… try mozilla & or gimp & – it feels “wrong” but it’s also pretty impressive and oh so “right” at the same time!

Using XMing to run X11 applications on a Windows XP machine

Secure, remote administration of a Mac OS X computer from within Windows

Posted on By Mark Wilson
This content is 18 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

In a recent post about multimedia file format conversions, ripping DVDs, playback and more, I linked to a number of Mark Pilgrim’s “How To” articles; however there was one which wasn’t relevant to that particular post – how to use your Mac from anywhere (although it is intended for remote control of a Mac the advice should be equally applicable to a Linux system, or even to a Windows Server with an SSH server installed).

A few months back, I blogged about using creating an SSL VPN to access my network but Mark’s video explains how to open a single firewall port and use SSH to provide a secure tunnel through which other protocols (in this case VNC) can be run for remote administration of a single computer. I tried it earlier and it’s very straightforward. Best of all, the software involved is all freely available under open source licensing agreements!

I recommend downloading Mark Pilgrim’s video for a full explanation but the notes below explain what is involved (some of the Unix concepts may be unfamiliar to those more used to a graphical environment and my quick introduction to Linux for Windows administrators might be useful):

  1. Download and install the PuTTY, PuTTYgen, Pageant and Plink SSH utilities on a Windows PC.
  2. Using puttygen, generate a public/private key pair and protect it with a passphrase. Save the private key to a file on the Windows PC and copy the public key to the remote computer (e.g. within a text file transmitted via e-mail or FTP).
  3. On the Mac, open a terminal session (either using the OS X Terminal application or an alternative such as iTerm) and enter the following commands from the home (~) directory:
    • mkdir .ssh (this was already present on my machine as I already had the SSH server running).
    • chmod 700 .ssh (again, I didn’t need to do this).
    • chmod 600 publickeyfilename (the default permission set is 640).
    • mv publickeyfilename .ssh/authorized_keys
    • sudo nano /etc/sshd_config (non-admin users may need to su - to an admin account first as explained in my earlier post about running sudo as a standard user) and make the following edits:
      • Allow SSHtunnelling (also known as TCP forwarding or port forwarding) by changing #AllowTcpForwarding yes to AllowTcpForwarding yes
      • (Optionally) Prevent the use of usernames and passwords for login (the public/private key pair and passphrase will provide the security for the connection) by changing #PasswordAuthentication yes to PasswordAuthentication no
      • (OS X 10.4 only) Disable pluggable authentication modules by changing #UsePAM no to UsePAM no
    • Exit nano and save the changes to /etc/sshd_config (exit to the original shell if su was previously used to escalate privileges).
    • Generate an SSH key fingerprint (to prevent man-in-the-middle attacks) using ssh-keygen -l -f /etc/ssh_host_rsa_key.pub and make a note of the fingerprint.
  4. Open TCP port 22 on any firewalls/routers between the Windows and Macintosh computers and enable port forwarding to the appropriate internal IP address (it may be necessary to apply a static IP address to the Mac but I prefer to use a DHCP reservation).
  5. If the external IP address for the network is not static (mine is) then use a dynamic DNS service to assign a DNS name so that it may be located on the Internet.
  6. Within the OS X System Preferences, Open Sharing and enable Remote Login (restart the service if it is already running in order to pick up the changes made earlier to /etc/sshd_config). Because password authentication has been disabled, remote login (SSH) will only be possible from a machine with the appropriate private key.
  7. Although OS X includes Apple Remote Desktop, which is a VNC server, alternatives such as Vine Server (OSXvnc) offer additional functionality. In particular, VNC is insecure by default; however by selecting to only allow local connections (require SSH) and start the system server (i.e. run as a service, rather than in the context of a particular user), it is possible to run a secure VNC server each time the system is restarted.
  8. At this stage, it should be possible to create an SSH tunnel to the Mac. On the Windows PC, run pageant which is a PuTTY helper application (SSH agent) to cache the passphrase for the private key, which adds a level of security if the PC is compromised but which would also become a nuisance if it needed to be repetitively entered. Add a key using the private key file generated in step 2 and enter the passphrase that was used when created the key.
  9. Next, run putty and enter:
    • The hostname/ipaddress in the basic session options.
    • The auto-login username for the Macintosh for the connection data.
    • The privatekeyfilename for SSH authentication.
    • A new forwarded source port of 5900 and destination of localhost:5900 for SSH port forwarding.
  10. Save the session with an appropriate sessionname and open the connection. On the first connection, the host key will be unknown; however the reported key can be compared with the one generated earlier to ensure that the host is the intended target computer. Assuming that all is well and the connection is allowed to continue, then a Welcome to Darwin! greeting should be displayed, along with a shell prompt.
    • If the connection fails and there is a prompt for the private key then Pageant is not correctly configured.
    • If there is a prompt for a password then /etc/sshd_config was not correctly edited.
  11. Unless command line interaction with the Mac is required, the PuTTY window can be minimised. In order to create the SSH tunnel automatically at login, a startup shortcut can be created with the target of "%programfiles%\PuTTY\pageant.exe" privatekeyfilename -c "%programfiles%\PuTTY\plink.exe" sessionname
  12. Finally, a graphical connection may be initiated with a VNC viewer such as UltraVNC. The connection should be made to localhost; however because localhost:5900 has been defined as the forwarded port in the SSH tunnel, the request is securely transferred to the VNC server on the Mac.

It’s worth noting that when I originally tried to test this configuration from a remote network I was unable to get past my employer’s firewall; however there are plenty of unsecured wireless networks around which I could use to test the connection!

Note that the original information that provided inspiration for writing this post is licensed under a creative commons attribution sharealike 2.5 license and consequently so is the information contained in this post.

RDP backslash fix for an Apple UK keyboard

Posted on By Mark Wilson
This content is 18 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

A few days back, in my post about typing # on an Apple UK keyboard, I commented that I can’t type a backslash (\) on an RDP session to a Windows server from my Mac.

An anonymous contact very kindly tipped me off about Ira Rainey’s backslasher system tray application which Carl Slater has mirrored on his site (alongside a very nice VW Camper and motocrossing Honda C90s!). It works fantastically on my Windows Server 2003 SP1 system using the Microsoft Remote Desktop Connection Client for Mac v1.0.3 and Mac OS X 10.4.8.