Remote Access

Remote “command line”
[#ssh]: SSH

See: Secure Shell

[#telnet]: Telnet
See: Telnet
[#rlogin]: rlogin

RFC 1282: BSD Rlogin is an interesting title for the RFC: The protocol can certainly be used by other operating systems. Rlogin client for BeOS. VanDyke software had a program called CRT, which stood for Combined RLogin and Telnet, which is some older software that even worked with Windows 3.1. It seems that software has since added SSH support as well (and has a Mac OS X version), and the new version is called SecureCRT.

The section about Telnet discusses using Telnet as a remote access prompt, and further discusses the OpenSSH artwork proclaiming the (desired) end to Rlogin, Telnet, and Rsh.

[#rsh]: “rsh

Similar to SSH, but lacking authentication features. In this way, rsh may have some similarities to rlogin.

There are actually two different rsh programs, which may be incompatible with each other, although both may use the same filename to run the executable. (Therefore, each system is likely to have only one of the commands in the PATH.)

[#remotshl]: Remote Shell

This is one of the protocols known as rsh.

Comes with some operating systems. This is one of the protocols shown as buried by OpenSSH artwork proclaiming the (desired) end to Rlogin, Telnet, and Rsh. The server is called rshd and may be communicated to, by using a client called rsh. There may be other software to take advantage of a software routine called rcmd.

Documentation may be seen by: OpenBSD Manual Page for the rsh remote shell client, OpenBSD Manual Page for the rshd remote shell server.

Restricted shell

Wikipedia's article about “Restricted shell”


The neat thing about this old MS-DOS shareware is that it has very low hardware requirements. This was used back in the days when dial-up modems were common because faster options, such as DSL and cable modems, hadn't yet become widely used.

This program probably had issues with the fact that some MS-DOS programs would write directly to video memory, and not use the BIOS routines that Doorway would try to capture in order to redirect output over the communications connection. If such a program would then wait for user input, such as the MS-DOS Editor, then the remote connection may become effectively unusable. So, some tasks (like copying files, and probably even uncompressing files) could be doable, but other tasks might result in either some lost output (which may be rather acceptable/tolerable), or even worse, the entire loss of the ability to keep interacting.

What's even worse is that if the remote person then disconnected a modem connection, and then tried to call back, the computer might still be running the program that was run from within Doorway, and so the computer might still be rather unresponsive. As MS-DOS was largely a single-tasking operating system, fixing this may commonly have required non-remote interaction.

Some other DOS programs

These were metnioned by TOOGAM's Software Archive: Terminal programs: “DOORWAY 2.31, Gateway2, PCAnywhere, and Carbon Copy”.

Web Services-Management (“WS-Management”)

(Little information is known at the time of this writing. It seems this may be piggybacking over an HTTP or HTTPS connection.

Windows Remote Management (“WinRM”)

Windows Vista comes with a client called winrs. The command line help (shown by using “winrs/? ”) states (among other information):

Windows Remote Management (WinRM) is the Microsoft implementation of
the WS-Management protocol which provides a secure way to communicate
with local and remote computers using web services.
Remote access to TCP ports

The most common way may be to use an SSH tunnel. Software which uses SSH to provide access to a remote “command line” is generally the software used to create tunnels, so check out the software in that section to find something that supports SSH tunnels. For information on actually setting up the tunnels, see the section on tunneling network traffic.

[#shvisdsp]: Remote graphics connection: sharing screens (visual displays)
Many software implementations that share visual displays may share access to other resources, including the clipboard of a GUI, sound, printer objects, file sharing, and perhaps file system sharing (so a file system can be viewed and perhaps even accessed similar to a local file system)
Needs checking: Probably shares programs, but perhaps entire screens?
[#xforward]: XForwarding: X11 being used as remote access

When using X fowarding, make sure that the communications are secured! This may be done through the use of firewalls and techniques such as port forwarding with an SSH tunnel. (This warning may be elaborated upon with details about just what access is provided. (To research: is it direct memory access?))

This section is not very complete right now and is just providing some pointers to directions for research. For now, this section is especially one to use at your own risk!

Some topics that should be covered here: Xhost/Xauth/SSH, support by SSH programs (OpenSSH ForwardX11, PuTTY X Forwarding), DISPLAY variable

[#xauth]: Xauth

Xauth will use a “cookie file” that can be displayed by running “ xauth -v ”. If the XAUTHORITY environment variable is set, the “cookie file” is the file specified by that environment variable. Generally it is not set, so the file used is “~/.Xauthority”. Note that the reference to ~ is the home directory of the currently logged in user account, and so that directory will be different for different user accounts. The “cookie file” should/must have specific permissions.

magic cookie: Remote X Apps mini-HOWTO section 6.2: Xauth says “This authorization scheme is formally called MIT-MAGIC-COOKIE-1.”

Linux XDMCP HOWTO section 2.2: “Security Reminder” says “If you must use XDMCP, be sure to use it only in a trusted networks, such as corporate network within a firewall.” The next section, Linux XDMCP HOWTO section 3: X11 Forwarding using SSH says “using XDMCP to display X across Internet is basically a no-no, due to” its “lack of encryption across the Internet.”
Techniques to not use
[#xhost]: Xhost

The bottom of Remote X Apps mini-HOWTO section 6.1: Xhost says “Xhost is a very insecure mechanism. It does not distinguish between different users on the remote host. Also, hostnames (addresses actually) can be spoofed.” (Emphasis was not added to that quoted text. Rather, the emphasis was part of the quoted text..) So, unless performing very basic, preliminary testing in a security environment, it is best to just avoid Xhost and instead use another method such as Xauth.

Actually, Xhost may be worth checking into, to make sure that it is disabled. Admittedly, this guide does not have yet info on how to do this. Perhaps Remote X Apps mini-HOWTO section 6.1: Xhost shows this?

Some tips have been compiled regarding troubleshooting the use of Xhost. These were noted during a successful troubleshooting session. (This guide might not be very condensed; it may show more than the precise minimum of steps needed.)

  • Don't use it. Using Xauth is likely more secure. The time it takes to troubleshoot XHost may be better spent by learning about how to use Xauth. Actually, most guides seem to be recommending using the “X11 forwarding” feature of OpenSSH (or PuTTY).
  • To get it to work, authorization needs to be granted. Using “ xhost + ” will open things up fairly widely. (Perhaps, until this is clarified, run that on both the system that will be showing the graphics and the system that will be running the program.)
    • This is an amazingly gaping security hole and should only be considered when the network is thoroughly locked down ahead of time. Otherwise, at least limit xhost by specifying what Internet addresses should be able to connect.
  • The system that is running the program should have the DISPLAY value set. Variations to try could include running any one of the following:
    • export DISPLAY=
    • export DISPLAY=
    • export DISPLAY=
  • To check whether things are working, try using the xdpyinfo command. Specifically, “ xdpyinfo --help ” may show syntax, and “ xdpyinfo -display $DISPLAY ” may show a report. If xdpyinfo runs but is not connecting, chances are that no other X program will be working either. That may be run on the computer that is running programs, and be faster than needing to run a program and then try to find a graphical window on the other computer.)
    • If xdpyinfo seems to just hang up, consider waiting it out. Perhaps after several minutes there will be an error message displayed.
  • As an alternative, try specifying the address of (especially when using xdpyinfo). If that works, but listening to a non-loopback IP address is not working, then the traffic is probably not being reached. Perhaps the X server is only listening on loopback (and is not listening for traffic on the other, more normal, IP address). Or, perhaps traffic routing (such as a firewall) is blocking traffic. (Likely ports to be affecting this could include TCP 6000 and other higher ports (6001 being next-most-likely) or perhaps UDP 177? A guide for XDMCP also suggests ports 16001 and 35091 for users of Gnome.
  • Make sure that the computer is listening or the X traffic.
    • Checking TCP ports may be doable with something like:
      • netstat -na | grep -i 6000 | grep -v grep ” (in Unix)
      • netstat -na | find /i 6000 ” (in Microsoft Windows)

      Or, perhaps there may be some minor variations (e.g. using TCP port 6001 instead of 6000, which would likely also require adjusting the value of the DISPLAY being used).

    • If Xorg is being used, try seeing seeing what is running to see if Xorg is being run with the “ -nolisten tcp ” parameter. (This might be especially common if X Windows was not started up manually.) If so, that parameter may need to be removed. (This may require figuring out what is causing the parameter to be run, and fixing the problem, and then restarting X Windows and perhaps also the display manager login (e.g. gdm)
      • The solution may be to back up (using the cpytobak command for an easy implementation) and then edit a text file named /etc/sysconfig/displaymanager and adjust DISPLAYMANAGER_XSERVER_TCP_PORT_6000_OPEN="yes". (Having this set to “yes” is likely desirable.) (Novel doc 3560166 also suggests setting “DISPLAYMANAGER_REMOTE_ACCESS="yes"”.)
        • In a system using YaST (e.g. OpenSUSE), this may be an option that can be edited using a program. In YaST (TUI mode or GUI mode), try checking under “System”, and then under “/etc/sysconfig Editor”, and then under “Desktop”, and then under “Display Manager”.
      • Some more changes are made. Perhaps, as described by (after bypassing the human-test redirection) specified changes to /etc/opt/kde3/share/config/kdm/kdmrc and/or /etc/X11/xdm/Xaccess files? Perhaps also changed was /etc/gdm/custom.conf having a “[security]” section, which may need a line changed/added to say “DisallowTCP=no”. (On another line in that same section, “AllowRemoteRoot=true” may be useful?) (Perhaps that is more likely needed for RHEL?)

      If any of this gets changed, restarting the display login manager (e.g. gdm) and then restarting X may be needed. Once the changes are made, re-check if Xorg has stopped using the “ -nolisten tcp ” option. If so, retry the desired results and/or other recommended troubleshooting steps.

  • Some common errors might include “Can't open display”
“Low Bandwidth X” (“LBX”)

NX Components guide says, “Some people still use an X11 extension called "LBX" (Low Bandwidth X). Please note that LBX is deprecated by the creators, since it doesn't compress traffic more efficiently than "ssh -C", but is more unsecure and considerably more complicated to setup and maintain.”

[#nx]: NX
Wikipedia's article on “NX technology”: section of “Other display protcols” says, “Although designed primarily to optimize X11 sessions, NX server can be configured as a proxy server to tunnel Remote Desktop Protocol (for Windows Remote Desktop Services sessions) and remote Virtual Network Computing sessions (most modern general-purpose operating system platforms), giving them some of the same speed improvements.” (NoMachine NX documetnation: Getting Started with NX section 4.1 says “NX supports either RDP and VNC sessions by running the RDP (rdesktop) or VNC (tightVNC) client directly within the X11 session.”
Original design
FreeNX Redesign info
Neatx (by Google)
Neatx's web page says “Neatx was developed by Google for an internal project. That project is now finished, and the source was released” for public benefit.
Sharing applications (window commands)
[#xpra]: X Persistent Remote Applications (“Xpra”) now redirects to: Google Code section related to Xpra which calls this: A window manager library and “screen for X11”. (This is meant to be a reference to the software named “Screen”, a multiplexer similar to tmux. Wikipedia's page on Xpra says “The idea for Xpra was inspired after the original author's experience of attempting to use various NX technology based setups.” That sentence cites Google releases Neatx NX server (comment 343389), where above the lower comments, the main text on that page ends with a note by Xpra's author about Neatx, “I was so frustrated that I wrote a competitor”.
[#remtctrx]: Remote access based on technologies by Citrix

After Citrix re-packaged Windows NT 3.51 into WinFrame (noted by Wikipedia's article on Citrix WinFrame), technology was licensed in the other direction and Citrix's “MultiWin” technology was used when “forming the basis of Microsoft's Terminal Services.” (This text is still quoting from Wikipedia's article on Citrix WinFrame.)

[#rdc]: Remote Desktop Connection (“RDC”) (over Remote Desktop Protocol (”RDP”)), a.k.a. “Terminal Services”

Enough has been written about this particular method of remote access that the information has been moved to its own separate section:


This includes moving the following sub-sections:

[#incmpuar]: “Independent Computing Architecture” (“ICA”)

Developed and supported by Citrix (Citrix XenApp), this is similar to RDC. IANA's list of TCP and UDP ports has TCP port 1494 and UDP port 1494 reserved for ICA, although traffic may also use TCP/UDP 2598 (which IANA's list of TCP and UDP ports calls “Citrix MA Client”, and which Wikipedia's page on ICA calls “Common Gateway Protocol (CGP)”.

Slashdot commentary on Citrix and RDP (probably meaning RDC)

Microsoft says about ICA (and Windows Terminal Server), in MS Q239088, “Printer redirection is not possible with the RDP 4 client in Windows NT Server 4.0, Terminal Server Edition. In a Windows NT 4.0 Terminal Server environment, you must use Citrix MetaFrame and the Independent Computing Architecture (ICA) client to redirect client printers.”

Citrix struggling and then striking a deal with Microsoft.

Sharing screens (or screen area)
These solutions may involve sharing an entire screen, or possibly even just a certain segment of the screen. For the most part, the basic technology these protocols are based on is to share the pixels shown by each program. This is a slower approach than sharing window commands, although optimizations may be possible to reduce the cost.
[#rfbvnc]: Remote framebuffer (“RFB” or “rfb”), and VNC (which uses RFB)

There's quite a few clients, including TightVNC, FreeNX, UltraVNC, and more. Be aware that security may not be high: Some software may only test the first eight characters of a password (even if more may be entered into the client). VNC is open source and probably the most widely compatible solution.

By the Olivetti Research Lab (“ORL”), later known as the Olivetti & Oracle Research Lab (“ORL”), and later purchased by AT&T and named AT&T Laboratories Cambridge.

RFB Protocol information

RFC 6143: Remote Framebuffer Protocol says “Because it works at the framebuffer level, it is applicable to all windowing systems and applications, including X11, Windows, and Macintosh. RFB is the protocol used in VNC.”

VNC protocol information

(At least some of this material may be moved to the RFB protocol section.)

[#vncsecur]: VNC Security considerations
[#vncpwlen]: Limited password strength

Some software may only test the first eight characters of a password (even if more may be entered into the client). TightVNC FAQ about security states, “VNC uses a DES-encrypted challenge-response scheme, where the password is limited by 8 characters, and the effective DES key length is 56 bits”.

This eight-character limit is known to be in effect in some software, even when that software allows more than eight characters to be typed into the server which keeps track of the passwords. The way to get around this is to use additional authentication, such as port forwarding with an SSH tunnel.

[#isvncryp]: [#vncrypsn]: VNC sessions transmitted without encryption
TightVNC FAQ notes that the session itself may be captured and replaced. To prevent this, one may need to resort to encrypting the session with external software. A method of doing that may be port forwarding with an SSH tunnel.
[#vncmltcp]: Multiple TCP ports being listed to
Although this may not be strictly part of the VNC protocol, this fact is true for multiple pieces of server software that implement the protocol. VNC servers may often share a VNC desktop to multiple TCP ports. Restricting access to just one of the TCP ports may not fully have the desired security effects if another TCP port without those restrictions may be used to access the same desktop. For details about the port numbers, see the section about VNC desktop numbers.
Password changes

HKCU might override.

This means that if a user logs in, the user's profile may include a password setting which overrides the password setting that the VNC server had been using before the user logged in. (This might be true with at least some VNC servers, while possibly not being true with others?)

[#vncdtpnm]: VNC desktop number
VNC desktop number details (overview)

VNC software may commonly use a notation such as which refers to an IPv4 address followed by a VNC desktop number. For example, refers to VNC desktop number 4. For applications using TCP/IPv4, typical notation would suggest that the number following a colon right after an IPv4 address is a TCP port address. However, that standard interpretation of the notation is quite often NOT what is used by VNC software. (In the case of Qemu's VNC server, the number following the colon typically refers to a desktop number rather than a TCP port number, although that is not true when using a “reverse” connection where the VNC server is in “listening” mode.) When working with software designed to be using VNC connections, be aware of how VNC software interprets that notation.

One may may be able to derive one or more TCP port numbers that correspond to a VNC desktop number, and vice versa, so there may be a relationship, but the VNC desktop number and the TCP port number are typically NOT the same number. For those familiar with standard notation, be aware when working with VNC software that the notation which looks standard may be using the VNC standard notation, not the general IPv4 standard notation.

A VNC desktop number most commonly translates to an RFB connection that uses a TCP port number which is 5900 higher than the desktop number. The most common desktop numbers, zero and one, correspond to TCP ports 5900 and 5901. However, some VNC servers may also use another port, such as using a TCP port which is 5800 higher than the desktop number for HTTP connections. TightVNC's Java Client: Readme says “Usually, VNC servers use ports 58xx for HTTP connections, and ports 59xx for RFB connections.” RealVNC's Java VNC Viewer page says “The server listens for HTTP connections on port 5800+display number.” Wikipedia's page on the RFB protocol also backs up those defaults, as well as noting that “listening mode” may use port 5500. (Presumably, that would actually be port 5500 above whatever the desktop number is.)

These numeric offsets, namely the difference between the web server's range (5800+desktop number) and the RFB server's range (5900+desktop number), may imply that desktop numbers must be below 100: That might not be strictly true, although it may be a good idea (so that VNC HTTP servers aren't listening in the range that is often being used for RFB connections, and so that RFB connections aren't using TCP port numbers 6000 or higher which may have another use.) (TCP port numbers which are 6000 and slightly higher tend to be used for another method of graphical access: X Window forwarding.) Whenever running a server such as a VNC server, prudence dictates that one should know (checking if needed) all the TCP port numbers that may be listened to. (A general technique, such as comparing the list of used TCP port numbers used before running the VNC software to the list of TCP port numbers used after running the VNC software, should work well. A faster, though not necessarily as thorough, method specific to VNC may be to check for the VNC desktop number added to each of three TCP port number offsets: 5900, 5800, and 5500.)

Note that this might not be handled consistently. TightVNC version history shows that TightVNC 1.3.9 caused the “host:port” syntax to be processed with “parsing maximally compatible with VNC4.” Numbers below 99 are treated as VNC desktop numbers, while larger numbers are treated as TCP port numbers. With this sort of inconsistent handling, one may need to be prepared to have some test connections be attempted. (If one connection type doesn't work, perhaps try connecting with an appropriate offset.)

[#vncdtpxm]: VNC desktop number example

The notation used in the VNC software to make this connection may be an IPv4 address followed by a colon followed by a VNC desktop number, such as That notation may look like the number 3 is a TCP port number, but it is not, as noted by the overview about VNC desktop numbers.

As an example of what the impact of the VNC desktop number is that if the VNC server specifies VNC desktop number 10, the VNC server software may actually be listening to TCP ports 5910, 5810, or 5510. If that TCP port is port forwarded (using port forwarding with an SSH tunnel) to TCP port 5903 on the machine with the VNC client, then TCP port 5903 ends up being the TCP port for the “local tunnel endpoint” used by the computer running the VNC client software.

In order to establish an RFB connection, the VNC client needs to connect to the TCP port number which represents the accessible (usually “local”) end point of the tunnel. If the computer running the VNC client is using an SSH tunnel that is created by software that supports OpenSSH notation, such as PuTTY, which is running on the same system as the VNC client, then that TCP port number to connect to may show up (in the SSH software and/or on the command line for the SSH software) with the letter L right by the TCP port number that is forwarded.

In order to connect to TCP port 5903 (which is simply being used as an example), the VNC client software may need to be instructed to connect to VNC desktop number 3. The VNC desktop number to connect to may be derived by subtracting 5900 from the TCP port number that the VNC client software should be connecting to. This subtracting may be done in anticipation of the fact that the VNC client software may be known to add 5900 to the referenced VNC desktop number when the VNC client software attempts to begin making an RFB connection.

[#vncsvr]: VNC server software
Using VNC viewing software
Many VNC implementations support a “listening mode”, where the client listens for a connection from the other VNC server software which supports “listening mode” by making an outgoing connection.
Mac OSX VNC servers
Built into the operating system
Apple Remote Desktop v2+ (Built in)

Apple Remote Desktop was not always VNC-compatible. Versions 1 through 1.2.4 Apple Remote Desktop used UDP port 3283 and ran on Mac OS 8.1 and later, as noted by “Releases” section of Wikipedia's article for “Apple Remote Desktop”.

Some VNC server software may be built into the operating system. With OS X 10.4 (“Tiger”) and later, go to the Apple menu and choose “System Preferences...”. Then in the “Internet” section (called “Internet & Network” in Mac OS X 10.4, and called “Internet & Wireless” in MAC OS X 10.6), choose the “Sharing” icon. Then place a check in the checkbox related to the service which serves as VNC server software. With OSX 10.4, this service is called “Apple Remote Desktop”. With OS X 10.6, the relevant checkbox is called “Screen Sharing”.

“Screen Sharing”
As noted in the section about “Apple Remote Desktop” (version 2+), with OS X 10.6, the service which provides remote service is called “Screen Sharing”. Wikipedia's article on “Screen Sharing” notes that Screen Sharing is “included as a part of Mac OS X v10.5”. (The name for that release of the operating system is Leopard.)
More info needed: Murphy Mac's tutorial on “Chicken of the VNC” says “The server component is built into OS X.” The software also mentions that (Vine Server's) OSXvnc “allows you to run the server on a port other than 5900”, which suggests that this software doesn't (although another port could be effectively communicated with by using a tunnel). This might be called “Apple Remote Desktop”.
Vine Server/OSXvnc
Vine Server (there is also the Vine Viewer client software), Vine Server (OSXvnc).
TightVNC is available in packages for a variety of platforms.
For Unix platforms
See software installation for details about using packages for the operating system being used (for many platforms). TightVNC may be downloaded from the main web site, so compiling from source may also be an option. The Older TightVNC versions section still has version 1.x available and worked in more Unix-like systems than version 2.x when version 2.x was still launched, although that may not have been a permanent situation. Also, be aware that any Java-compatible platform should be able to use the viewer designed for the Java version.
For Microsoft Windows

For Windows Server 2003, grab either TightVNC 1.3.10 or TightVNC 2. For Windows 2000 or XP, grab the DFMirage mirror display driver for imporved performance and also grab TightVNC (either version 1.3.10 or TightVNC 2).

There are some native binaries which will likely be a better solution than the Java-compatible solution, although the Java-compatible viewer may also be viable (even if it doesn't integrate as nicely with the system).

Vista and newer versions of Windows
For Windows Vista or newer, grab either TightVNC 2.0 (recommended by the TightVNC authors) or 1.3.10 (which should work but may have some limitations under these newer operating systems). For Microsoft Windows, version 2.x of TightVNC has dropped support for some platforms and runs only on Win2K, Win XP, and newer. However, version 2 also may support Windows Vista and newer better than the older TightVNC 1.x releases.
Older Microsoft Windows operating systems

The Older TightVNC versions section still makes version 1.x (e.g. 1.3.10) available which worked with Win9x/ME, NT 4.0 SP6, 2K, XP, and Server 2003 well, and may work a bit with newer operating system versions as well. (Note that unlike the TightVNC software, the site that distributes DFMirage does not seem to offer source code for DFMirage.)

Note that for Windows 2000, XP, and newer, if the computer using that operating system is going to be running the TightVNC 1.3.x server, the DFMirate mirror display driver is a “Recommended Add-on” that the TightVNC website recommends using. The reason is that “TightVNC Server can use this driver to detect screen updates and grab pixel data in a very efficient way.” (To summarize the impact: VNC sessions may update the screen faster.) The driver has had at least one WHQL-certified version which supports Win2K and Win XP through Win7 and Win Server 2008 R2. The web page also mentions NT4 compatability.

Until some time in July of 2012, there had been a TightVNC Portable Edition version 1.3.10 30-day evaluation version released by the TightVNC team. TightVNC Portable Edition home page, archived by the Wayback Machine @ The software was based on open source software, so other solutions were available (without the 30 day limit). This is likely different from: page: “Tight VNC Viewer Portable Development Test 2” shows some work in progress. (The website has some comments about TightVNC as well as UltraVNC a supported application on the main part of the website.)

[#ultravnc]: UltraVNC, a.k.a. UVNC or uVNC or Ultr@VNC
UltraVNC releases multiple UltraVNC products, including:
UltraVNC Server and viewer

downloads for UltraVNC Server and Viewer, (UltraVNC server documentation, UltraVNC Server MS-Logon Authentication), UltraVNC Server

UltraVNC Java Viewer

UltraVNC Command line parameters, UltraVNC installation guide (may have information that is also found elsewhere, like in UltraVNC Server's documentation), UltraVNC Usage Guide (describes hotkeys, and shows icons), UltraVNC Viewer Usage, UltraVNC Viewer Configuration, ultravnc.ini file information

UltraVNC Single Click
UltraVNC Single Click, UltraVNC Single Click, UltraVNC SC Create, UltraVNC SC online creator
(UltraVNC) Repeater
(UltraVNC) Repeater
Screen recorder
UltraVNC Screen Recorder

UltraVNC Addons

Mirror Driver

UVNC Mirror Driver (MD) Software Development Kit (SDK) states, “UVNC bvba hereby grants Ultr@VNC Team”... So it appears there are groups named UVNC bvba and Ultr@VNC.

UltraVNC Encryption info, UltraVNC Encryption Plugins

UltraVNC Forum

UltraVNC Documentation

[#realvnc]: RealVNC

“History” section of Wikipedia's article on VNC says “Following the closure of ORL in 2002, several members of the development team (including Richardson, Harter, Weatherall and Hopper) formed RealVNC in order to continue working on open source and commercial VNC software under that name.” RealVNC's company page says “RealVNC was founded in 2002 by the original developers of VNC to promote, enhance and commercialize VNC.” RealVNC Free Edition 4.1 links to some earlier versions (4.0, 3.3.7): it may be worthwhile to check the tab at the top of the page to make sure that is the latest version of the free product.

RealVNC feature comparison and download selctor: “Which version of VNC?” (as titled by the page and the site's VNC tab) compares the free version to other versions. Key differences can be which operating systems are supported: when checked in October 2010, the free version support Microsoft Windows NT 4, 2K, XP, and Server 2003, as well as “UNIX (Linux, Solaris, HP-UX, AIX)”, but not Windows Vista, Windows 7, or Windows Server 2008, nor Mac OSX (x86 and PPC). The paid-for personal edition supported all those just-mentioned Windows systems, but not UNIX (despite the free edition doing so) nor Mac OSX: The only version supporting Mac OSX was the Enterprise Edition.

[#vncsvxwn]: VNC Server software that is designed to work with X

One option may be to use a version of VNC that is designed for local use, and then run a VNC client. That may be more sensible for a computer that someone is going to use locally. Things like graphics acceleration may be more likely to work using this type of approach.

Another option may be to use a very lightweight X Window System server that has VNC built in. These options might not even display graphics locally, and they may be much smaller packages than a full X Window System distribution. (They may also rely on an existing X Window System distribution.)

libvncserver's x11vnc

A part of the libvncserver project is a program called x11vnc. (To install this from a package repository, check for a package called x11vnc.)

Checking shared memory

First, check how many shared memory segments are being used:

ipcs -p

Example output on a system that has not been using this type of shared memory:

Message Queues:
T       ID     KEY        MODE       OWNER    GROUP LSPID LRPID
Shared Memory:
T       ID     KEY        MODE       OWNER    GROUP  CPID  LPID
T       ID     KEY        MODE       OWNER    GROUP

Right now, there may be very little output (just showing some headers). Later, re-running the same command may show quite a bit more information. So, the purpose of running this now is just to get a feel for the initial output, for better comparison later. However, some systems might actually use some shared memory segments. In that case, the output may be quite verbose to start with. That simple fact may be good to know later.

To securely listen only from connections on the local machine, use:

x11vnc -localhost -nopw -create -v &
echo $?

Or, perhaps even simpler:

x11vnc -localhost -create &
echo $?

As an alternative, if there is an already-running copy of X, then the following syntax might be more useful:

x11vnc -display :2 -localhost -nopw -v &
echo $?

When running the program, the following lines may be output (in addition to other lines):

The VNC dekstop is:      servername:0

After connecting with the client, the following three lines will be shown. (There will also be other lines of output, in addition to these three lines.)

DD/MM/YYYY hh:mm:ss Using X display :20


Using X display :20


DD/MM/YYYY hh:mm:ss X display :20 is 32bpp depth=24 true color


The VNC desktop is:      localhost:0



(For some reason, the system name may be more likely to be localhost, rather than the full system name, which was output earlier.)

Find one of the lines that shows the X desktop number. (This is not necessarily anything like the VNC desktop number.)

At this point, X Windows is running. Set the DISPLAY variable appropriately. For instance, if using a Bourne-compatible shell, and if the X desktop number is 20, you could run:

env DISPLAY=:21 xterm &

or, you could break that up into multiple commands, allowing you to run multiple programs by running some shorter commands. For instance, you could first run:

export DISPLAY=:21

At this point, go ahead and run your favorite programs.

xterm &
xeyes &

If x11vnc and X are closed, check to see if the program is cleaning up after itself well. Run: ipcs. (Further details are discussed in the Troubleshooting section.)

Long connects, blank screen, programs not startable

In some cases, the client may connect but then may take some time (like 3 minutes after a decently fast local network) before showing graphical data. Then, the X Window Session may show a default screen (alternating black and white pixels), with no window manager. Trying to start a program may result in the program being unable to interact with the X display (which will generally cause the program to display an error message, and then exit).

Make sure that ~/.xsession is owned by the correct user. (If you are logged in as a user other than root, which is generally desired, then do not have the file be owned by root.)

Slow connection speed

This should just generally be expected with VNC. However, at the cost of system memory (both on the server, and on the clients), this VNC server has some methods to try to speed up the display. This may take up about 100MB for a typical megapixel screen (about 1,000 pixels by 1,000 pixels in size). Try:

x11vnc -display :2 -localhost -nopw -create -v -ncache 10 &
echo $?

This will allow graphics to be seen even if they should not be shown (e.g. for windows that have been minimized). This may be considered to be a bug (but that problem is necessary to implement this speed-up in a way that is compatible with most VNC viewers). This is generally not really a problem: the stuff that should be invisible will generally be hidden below the visible area, although the clients may show a scroll bar that makes the content visible if the user scrolls down. Users of the client named SSVNC might not be affected by this issue (documentation of x11vnc client side caching notes that SSVNC “ can do this automatically.” Later, part of the next paragraph of the documentation says, “The Enhanced TightVNC Viewer (SSVNC) Unix viewer has a nice -ycrop option to help hide the pixel cache area from view. It will turn on automatically if the framebuffer appears to be very tall (height more than twice the width), or you can supply the actual value for the height. If the screen is resized by scaling, etc, the ycrop value is scaled as well.”). For more documentation about this feature, see: documentation of x11vnc client side caching or x11vnc options related to ncache.

Cannot make a connection: shmget issues

Some of the last output may be:

DD/MM/YYYY hh:mm:ss shmget(tile_row) failed.
DD/MM/YYYY hh:mm:ss shmget: No space left on device

This technique uses an adaptation from and similar advice.

See if “ipcs” turns up any results. For instance, when reporting “Shared memory”, there may be a header line (“T       ID     KEY        MODE       OWNER    GROUP”, followed by dozens of additional lines.

See if “ipcs -s” turns up any results with the first column having the letter “s”. If not, see if “ipcs -m” turns up any results with the first column having the letter “m

Still, just seeing that there is a lot of shared memory usage does not indicate that the shared memory usage came from x11vnc. Affecting other, running programs is not desirable. So, check whether anything is using the memory. Use: “ipcs -p” to verify the CPID (which shows up right after the OWNER username and PROUP columns). See if there is any current task that is using that PID. e.g.:

ps -auxww | grep pidNumber

(Unfortunately, that example may need adjustment for other platforms. See: ps command differences for an overview.)

If there are dozens of entries that are not related to currently running programs, clear them out. The following may help:

for X in $(ipcs -s | grep username | awk '{print $2}'); do echo ipcrm -s $X; done | tee -a /tmp/sema

Customize the username. If “ipcs -m” is not turning up results, but “ipcs -m” is turning up results, then modify both of the “ -s” occurrences in that command line, to instead use “ipcs -m”. e.g.:

for X in $(ipcs -m | grep username | awk '{print $2}'); do echo ipcrm -m $X; done | tee -a /tmp/sema

If results seem sensible, run the created script or re-run the command but take out the echo.


may provide similar capabilities as x11vnc?

Actually, this creates a border on one side of a screen. If the mouse cursor moves beyond that border, then the mouse cursor ends up affecting the screen of another computer. There is also a Microsoft Windows port, Win2VNC, which performs the same behavior.

The program's home page may refer to x0rfbserver. That project seems defunct: x0rfbserver home page from June 4, 2003, archived by the Wayback Machine @

[#xvncreal]: Xvnc (from RealVNC)

Some documentation: RealVNC documentation for Xvnc, Archived man page from 4.1 Unix version?


Xvnc -geometry 800x600 -depth 8 -rfbport 5905 -desktop SampleName -localhost &

Note: -geometry of 640x480 is default.
Note: -depth of 8 (8-bit color) is default.
Note: the default -rfbport is calculated as 5900 plus the display number
(the X desktop number)

You can also specify a display number. (Documentation suggests that is not an optional parameter, but it is.) If you don't specify one, then one is chosen. (Probably display zero.)

According to TigerVNC documentation for Xvnc (which does cite RealVNC, so that documentation does seem to be based on RealVNC code), using -interface could be used to specify which IP address to listen on, and “By default Xvnc listens on all available interfaces.” Some (perhaps only older) versions of the software did not support the -interfaces option, but did support -localhost. Using -localhost may cause the software to listen on ::1 only. If using older versions of PuTTY which didn't support IPv6 nicely, that could be a bit problematic. However, such older versions of PuTTY could still work with DNS, so trying to connect to something like ip6-localhost or ip6-loopback (followed by a colon and TCP port number) could accomplish success.

Following is some sample output of a session that started running Xvnc.

$ Xvnc -geometry 800x600 -depth 8 -rfbport 5905 -desktop SampleName -localhost &
[#] #####
$ Couldn't open RGB_DB '/usr/X11R6/lib/X11/rgb'
YY/MM/DD hh:mm:ss Xvnc version 3.3.7 - built Dec 30 2006 12:50:35
YY/MM/DD hh:mm:ss Copyright (C) 2002-2003 RealVNC Ltd.
YY/MM/DD hh:mm:ss Copyright (C) 1994-2000 AT&T Laboratories Cambridge.
YY/MM/DD hh:mm:ss All Rights Reserved.
YY/MM/DD hh:mm:ss See for information on VNC
YY/MM/DD hh:mm:ss Desktop name 'SampleName' (hostname:0)
YY/MM/DD hh:mm:ss Protocol version supported 3.3
YY/MM/DD hh:mm:ss Listening for VNC connections on TCP port 5905
Font directory '/usr/share/fonts/X11/Speedo/' not found - ignoring

Note that after the hostname, it showed :0. That means we're using desktop zero. This is important. If you see something other that desktop zero, then adjust the following instructions when specifying the value of the

VNC viewing software

TurboVNC has been known to work with IPv6 better (more successfully, or at least easier) than many other options.

TurboVNC main project page, TurboVNC Projects Page at SourceForge, TurboVNC site at SourceForge

[#ssvnc]: SSL/SSH VNC Viewer (SSVNC)

This software only comes with the ability to view: it is not a VNC server. Made by the author of x11vnc, x11vnc's home page even calls SSVNC “An x11vnc side-project”. The same sentence also calls SSVNC “an Enhanced TightVNC Viewer package”.

The latest downloadable file should be available from SSVNC files download section. Although the page has been known to have a prominent hyperlink to the ssvnc_windows_only-*.zip package, checking the directories named after a version will display a ssvnc_all-*.zip package, and some other smaller packages. (For version 1.0.29, sizes ranged from about 205KB for ssvnc_unix_minimal-* to 9.7MB for ssvnc_no_windows-*.tar.gz and 18.9MB for ssvnc_all-*.zip.)

A README file from the bundle (as quoted by the author's main page) identified the software as “Enhanced TightVNC Viewer (SSVNC: SSL/SSH VNC viewer)”. So, presumably the SS in the program's name refers to “SSL/SSH”.

SSVNC (author's project home page)


TightVNC (or older TightVNC 1.x versions which may be available for platforms that 2.x has not been released for; see also the Mirror Display Driver if using this on WinXP, newer, or Win2K)

TightVNC's download page has software for some platforms including Microsoft Windows and Java, and a free license (via GPL) is available for this software, and it is also available on other operating systems.

Note: although this had been an OpenBSD package, OpenBSD TightVNC package Makefile update notes show that the TightVNC OpenBSD package has since been replaced with SSVNC, despite the fact that SSVNC has a notable limit to its featureset: SSVNC is only a viewer and not a VNC server.

SSVNC was preferred over TightVNC by people maintaining OpenBSD ports (Ian McWilliam noted, “tightvnc can go bye bye”, and earlier noted, “TightVNC has been broken on AMD64 for” a time that has been “so long”, “probably busted on all 64bit architectures”. Stuart had commented, “Broken on big-endian too.” This probably happened between 4.6 and 5.0, based on a forum post.)

The SSVNC package might simply come with a VNC viewer that can be obtained sepearately. For example, OpenBSD TightVNC package Makefile update notes states, “ssvnc-viewer is a significantly improved fork of tightvnc-viewer and basically a drop-in replacement (same filename for the viewer).” The Microsoft Windows version comes with a TightVNC.exe file. The SSVNC distribution also comes with other programs that can help to perform tunneling.

(Information may be in the section about VNC servers.)
(Information may be in the section about VNC servers.)
Some Mac-specific solutions
Chicken of the VNC

Open Source, Mac.

Wow, the gull of the software developers to have a name like that for their product... (Perhaps it was meant to be a parady of “chicken of the sea” canned tuna? The product's logo (@ suggests so, and this is claimed by Wikipedia's page for “Chicken of the VNC” as well as the “Popular references” section of Wikipedia's page on the “Chicken of the Sea” product.)'s section for Chicken of the VNC is referred to as “the official homepage!” by software developer's page for Chicken of the VNC. Although the software is often described as being for Mac OSX, “Chicken of the VNC” page on Apple's web site lists this as a universal binary which indicates the software also has compatibility with a pre-OSX version of Mac OS.

Vine now redirects to Testplant's Vine Viewer page (even though the vendor does also have other VNC software: Vine Server). That Vine Viewer page says “Vine Viewer 3 runs on Mac OS X 10.4 (Tiger) through 10.6 (Snow Leopard).”
VNC Core 1.0
Apple's page about VNC Core 1.0 provides some details of this small program.
(See also: Info on supporting TigerVNC in RedHat (rather than TightVNC). An old post shows no one is actively attempting to port it to OpenBSD.) VNC Remote Control Software lists some other options.
Other software
Qemu, which is software used to create a virtual machine, supports VNC as an output method.
[#scrncnct]: “ConnectWise Control” (“formerly ScreenConnect”)

This is software that seems to often be used with “ConnectWise Automate” (“formerly LabTech”).

The author of this text has not set up the software at the time of this writing, so no information is hereby provided about the setup of this software. However, there is some information about using the software.

Beware that the program does support voice chat, so if you have an enabled microphone, you may want to have that be disabled if you expect conversations to not be hearable by a remote user.

Typically, the first thing that will happen is ScreenConnect will open up with all of the user's screens being visible. If the visible screens are being shown too small, increase the size of the entire ScreenConnect window.

If the connection seems to be going slow, hover a rodent over the top menu's magnifying glass icon. In the “Select Quality” section, you can choose another quality level. The default is “High” quality. “Medium” quality results in some slight color loss, but generally extremely usable with the visual impact seeming to be very minor (and sometimes not even very noticeable).

Also, under the magnifying glass, you can choose which display (monitor) you can see.

If you need to press Alt-Ctrl-Delete, you can try simulating that by pressing Alt-Ctrl-Home or by hovering over the “Settings” (gear) icon in the title bar, and then choosing “Send Ctrl-Alt-Del”.

There is an object on the screen that identifies the system as being actively remotely controlled. (This is at the top of the screen.) That object can be moved by using a rodent to drag the object to a new location.

Generally, there is no need to hover over the “Settings” (gear) icon in the title bar, and then choosing “Send Clipboard Keystrokes”, because there is usually nice support for copying and pasting between the host and guest computer. However, that could be usable on the Microsoft Windows login screen which disables pasting. Also, this has been known to be useful in a case where the user's computer is using different localization than the endpoint (particularly when trying to enter a password).

There is a “speech bubble” icon in the title bar that can be used for chatting. Using this will create a window that is visible on the end user's screen. If the remote user interacts with that window, the chat window will not identify the chat as having come from the remote user. So, to continue to chat and to have the text, move the rodent back up to the title bar and hover over the speech bubble again.

The title bar also has some arrows that represent file transfer. Typically, that is the slow way of doing things. The fast way is to just have a copy of Windows File Explorer open. (A visible spot on the desktop is also sufficient.) Then use “drag and drop” to copy a file from one computer's Windows “File Explorer” window to the other computer's Windows “File Explorer” window. (Microsoft Windows components)

The program can operating in a “full screen” mode. This can be used by clicking on the “Maximize” button of the title bar. Once in “full screen” mode, moving the rodent cursor to the top of the screen will show a title bar which can be used to “Restore” (un-maximize), or choose a different display monitor to view.

Connectwise Control logo, ScreenConnect labelled logo (found from PC Magazine page on ScreenConnect), ScreenConnect logo, ConnectWise Control (formerly ScreenConnect) logo, ScreenConnect logo (used at Wikipedia's article on ScreenConnect: “History” section)

Wikipedia's article comparing remote desktop software may show some other protocols in the table's column on support protocols. Examples may include ALP (used by the SoftRay client).
[#rtsvtocl]: Network traffic route from server to client: Matchmaking and/or firewall punching

Most often a remote access client will be on a different system from the remote access server. One will need to make sure that the remote access client and the remote access server can communicate with each other. In other cases, the remote access server is not listening on a non-loopback interface (which may be intentionally done to help secure how the remote access is granted). This can often be worked with by using a tunnel by creating a port forwarding rule with SSH. If the system is being blocked by a firewall, one may be able to use an SSH tunnel if SSH tunnel is not being blocked. Otherwise, another traffic routing techniques, such as creating a tunnel (such as a VPN tunnel), may need to be used for the remote access to work.

There are some other approaches which may be application-specific: this page is about discussing some other approaches when it comes to Remote Access.

Server-to-client connection
e.g., a reverse VNC connection where the VNC client is in listening mode. There is still a requirement for one side to not be having traffic blocked by the firewall, but in this case the requirement to allow an incoming connection is a requirement of the user who will be controlling the remote machine. The user who has a machine that will be remotely controlled, who may be somebody with less experience handling traffic routing, does not need to make an incoming connection.
Contacting a centralized server

Some closed source solutions involve both the machine of the end user (who will be remotely using a machine) and the remotely-controlled machine to use client software to connect to a centralized server which is known to not be blocked by a firewall.


Redirection to LogMeIn add redirected to 728x90 JPG advertisement for “Free remote support for IT Pros” which redirected to LogMeIn Free ad destination.

There are some legal limts: The LogMeIn Free Terms of Service and Conditions require that account creators are “18 years of age or older.” Also, “The Services and their related software are subject to United States Export Administration Regulations. No software or Service may be downloaded, used or exported” by certain people specified by the United States, including certain entire nations.

Other legal terms

People interested in software freedom may object to rights being limited, such as being allowed to “alter, modify, redistribute, sell, auction, decompile, reverse engineer, disassemble or otherwise” alter the “any of the Services to a human-readable form.” People who want to be able to count on the software in the future should notice that LMI Ireland “reserves the right to charge all of its users fees for any future versions of, or premium (i.e., charged for) upgrades to” the service and LMI Ireland “reserves the right to charge all of its users fees for any future versions of, or premium (i.e., charged for) upgrades to, the Services. You understand that LMI may update or modify any of the Services and their related software at any time, but is under no obligation to inform” ... “of any such updates or modifications.” Also, LMI Ireland “reserves the right, in its sole and absolute discretion, to restrict or limit the number of” “free” “or” “basic” “versions of the Services that may be used”. Those who are bound by these terms “are solely responsible for the content of” computers belonging to those who are bound, as well as “any transmissions made when using the Services.” Also, those who are bound “are solely responsible for any and all activity that occurs under” the account. “YOU UNDERSTAND AND AGREE THAT ANY MATERIAL AND/OR DATA DOWNLOADED OR OTHERWISE OBTAINED THROUGH THE USE OF THE SERVICE IS DONE AT YOUR OWN RISK AND THAT YOU WILL BE SOLELY RESPONSIBLE FOR ANY DAMAGE TO ANY COMPUTER SYSTEM OR LOSS OF DATA THAT RESULTS FROM THE DOWNLOAD OF SUCH MATERIAL AND/OR DATA.” Certain features of the agreement “shall survive any termination, expiration or rescission of these Terms.” (Furthermore, earlier it is stated that such features are to “SURVIVE ANY TERMINATION, EXPIRATION OR RESCISSION OF THESE TERMS.”)

Obligations include: those who are bound “shall” ... “not disclose” certain “information to anyone except Your employees, agents, and consultants on a need-to-know basis (and who have been informed of and acknowledge their obligation to be bound by these Confidentiality Terms)”, and shall “not use” LMI Ireland's “confidential information for any purpose other than that for which it is disclosed.” This includes any information that those bound by the agreement “should reasonably believe to be confidential given the circumstances”. “Upon the written request of LMI,” those bound by the agreement “shall return, or certify that You have destroyed, all information disclosed under” Confidentiality terms. “The Services are not fault-tolerant and are not designed, manufactured or intended for use” with “High Risk Activities.”

“Neither party may assign” the agreement, except that LMI Ireland may. The agreement states “You agree that You are responsible for the actions and inactions of Your employees and consultants and will use commercially reasonable efforts to monitor Your employees and consultants.”

This isn't even discussing the requirements, such as approval of auto-renewing, that are related to payment of services (for the services that require payment), or “Customer's responsibility to properly notify all participants in a” ... “meeting that the meeting is being recorded.”

Kaseya software

This software has been briefly mentioned here. Further details may (eventually) be found in the (newer) section about managing networks: Kaseya software.

Kaseya's Virtual Administrator

Using the “video streaming” method of remote access, the person who will be controlling the remote system visits a specific web URL. This user may need to accept a remote access control. That end user will then end up connecting to an ActiveX application which listens to traffic on the end user's system's local loopback interface ( That end user is also provided with a session ID. The server also has a username for this Kaseya software.

When the end user of the machine that is going to be controlled visits a specific different web page, that end user is provided with that same session ID (and perhaps others), and also next to each session ID, this end user sees the username for the Kaseya software. (If there are not many remote access sessions simultaneously waiting to be started, there will not be many session ID's to choose from. Seeing just one is certainly a possibility.) If this end user is told the username to click on, then the right session ID will be selected (unless the same Kaseya username has multiple session IDs open simultaneously). The end user may then need to choose some prompts to Install/Run the ActiveX control, and to tell the firewall software to allow the connection. (Sometimes the remote control session is successfully established, and the end user who is remotely controlling the system already can choose to tell the firewall software to Unblock the connection.)

Neither user needs to be at a centralized location, nor does either user need to allow any sort of incoming connections. Both users need to be able to run the ActiveX control effectively, and elevated permissions may be required. In the case of Windows XP, the end user who is having the system be remotely controlled may need to be logged in as an account which is somehow in that machine's local group called “Administrators” (either by being directly listed as a member of that group, or by being a part of a group which ends up being part of that machine's Administrators group).

This Kaseya software does not actually provide the technology of sharing graphics, but rather it automatically installs, as needed, and runs the needed software on the machines being used by both end users. The user who is going to be controlling the remote access system chooses which software is installed (before visiting the URL that generates the session ID). For example, KVnc or a solution based on Terminal Services may be used.

Kaseya Free page about Kaseya Free notes, “This application has been discontinued.”

Kaseya Free (info from, archived by the Wayback Machine @

Might have been, at some point, somehow related to

Other alternatives contacting a centralized server
Other connection methods
Other connection methods and/or unsorted/misc alternatives for sharing a desktop
Other software may be found by using AlternativeTo.Net and looking up some of the software solutions already mentioned in this section.
Sharing the GUI's clipboard

This is often a feature on remote access.

There have been some instances where the clipboard seemed to not work. Simply re-creating the connection, though, would allow the clipboard to start working. Further research/experience may be needed to clarify this behavior.

Sharing sound

(The following is based on some beliefs/claims/documentation, but may not have been fully tested, and may include inaccuracies.)

Using RDP

Microsoft's RDP client may support transmitting sound. (Perhaps only with clients new enough?) GitHub: FreeRDP, Wiki, Command Line Interface also references a “ /sound ” command line option.

25 Best SSH Commands notes redirecting a local microphone to a remote speaker using:

dd if=/dev/dsp | ssh -c arcfour -C dd of=/dev/dsp

It is expected that the above just works on some operating systems.

Sharing printer objects
There's a few different ways that there may be a desire to be interacting with printers remotely, some of which is described by other sections in more detail. These ways are:
Having software on a remote machine print to a printer which is local to that remote machine
Once the printer works on the remote machine, having the ability to access that remotely is not typically any more difficult than using a method of running programs on that system. The remote access methods that provide command lines, or which allow interaction with a graphical desktop, are solutions to accomplishing this task.
Having remote printers being available to local programs

This is commonly provided using printer sharing methods. Such info is not here, though a hyperlink to a relevant section should be added here.

Another approach, which is probably more complicated in many cases (but is mentioned here for completeness, and because it might be viable if a more straightforward approach isn't working) could be to have the remote machine use a “remote access” program to connect to the local machine, and for the remote system's local printers (local to the remote system) be available to the software on the system which the remote system is remotely accessing.

Having local printers being available to remote programs

This is a bit more complicated, although people who have had this work tend to really like the ability. The ability allows a user to connect to a remote system, open up a document on that remote system, and print from the software on that remote system, and the material is printed on the local printer that is near the user.

This could be done by printer sharing, although, setting that up can be a bit complicated, especially if there are concerns about permissions. For example, if the local printer is a cheap, low quality printer that has a higher cost per page, but is a fairly portable system, a traveling worker might want to print up a single document without having other people in the main office using the traveler's portable system.

However, another method is for a remote access program to share the local printers to the remote desktop that is being connected to, and to automatically add those printers (the printers which the remote access program is sharing) to the list of installed printers on the remote system. These may be “session” printers objects which have a couple of advantages. One is that in the case of a multiplexed system, such as Microsoft Windows Terminal Services, where multiple users have their own “sessions” on the server. In that sort of case, the shared printers might only be accessible to the one session connected to with that remote access program. Other sessions (likley used by other users) may not see the printer in their list, and that is nice. Secondly, when the remote access session is terminated, those session printer objects will disappear, so clean-up is automatic. If the same end user connects from a different computer, the printer(s) previously available might not be available again. Fortunately, in this sort of case, the session-based printer objects won't be visible because they were already cleaned up. (In contrast, using traditional printer sharing may result in a useless printer object which seems to be referencing a printer that, unable to be communicated with, appears to be “Offline”).

So now that the overview discussed the various approaches, only one of those methods involves special support from the remote access programs. Only some software supports this. More details about implementing this feature may be in the section where the software is described (in the section about sharing screens (visual displays).)

[#remotfil]: Accessing remote data storage (e.g. files)

The most common methods of transfering files will generally implement one of two basic approaches: using a protocol that is meant to easily transfer a single specified file, or making a (portion of a) file system on one system to appear to a remote system like it is a (portion of a) file system that is local to that remote system. Note that the primary method of sharing drives like this is convenience. For large scale file transferring, there are protocols that are primarily designed to transfer or share files and/or file systems. Using protocols designed for that task may, in some cases, provide a nicer experience.

See: filesystems provided over networking, transfering files.

Transfering files may also be a feature built into some “remote access” software. (Further details about this specific feature are not yet provided here.) Check the feature list, and/or other documentation, about a specific program to see what may be provided.

Another method sometimes used (and despites by some IT professionals) may be to use another protocol. Examples could includes using E-Mail attachments, or chat programs.

See also: the section about sharing objects.

[#obdvcshr]: Sharing objects

ImDisk and/or devio may provide some options. (Warning: This software hasn't been tested by the author of this text, at the time of this writing. As a standard disclaimer, please determine any sort of security/stability impacts before using it.) see LTR-Data software and/or

Sharing other data
Microsoft has made the ability to share information, and interact with systems (e.g. restarting services) through MMC snap-ins. Some of the most useful snap-ins are accessible in the program called “Computer Management”. e.g. to see a list of services running, reboot computers, and more, there are various programs that are bundled with the operating systems, or perhaps the operating system's support tools, or SysInternals.
[#rnrmtexe]: Running remote executables

If there is an executbale file on the remote machine, you can run it on the local computer. One way is to copy the executable over before running it. Another way is to use filesystems over networks.

Another task, which people may like to do somewhat commonly, is to specify that a remote system should run a command.

Here are some ways to do that.

Starting services

Some operating systems implement the concept of a “service”. A service is basically just an executable file that the operating system can interact with in a certain way. An operating system that implements this concept of a “service” provides a method to perform service management, which means there is a rather consistent and straightforward way to perform certain common actions with a service, like starting and stopping the software.

If the remote command is a “service”, there may be some methods of “service management” which can be useful.

Remote service management in Microsoft Windows

The following documentation sections have information about using sc:

Note: This can be slower. It can be notably slower than interacting with a remote system using services.msc's functionality.

Using services.msc's functionality
Starting/Accessing services.msc

This may be started with:

start services.msc /computer:\\system.example

Or, presumably:

mmc services.msc /computer:\\system.example

This is also part of compmgmt.msc.

Checking that the remote system is used

In the left frame, the remote computer's name should be specified. (The left frame should not say “Services (Local)” unless you are trying to modify the local system. In that case, even if you specify the computer's address (short host name, fuller DNS-style name, IPv6 address, or IPv4 address), the computer may outsmart you and figure out that it is modifying itself.

If you are trying to affect a remote system, but started the software without specifying that remote system, then use the Action menu (or access the context menu of the system, where the words “Services (Local)” show up in the left frame). Then choose “Connect to another computer ...” After specifying the name of the computer, the successful connection is demonstrated by showing that computer name in the left frame (instead of “Services (Local)”.)

Flexible execution

The big downside to using a “service” is that the service needs to be set up ahead of time. Sometimes that is not the convenient way to do things. The options in this section tend to provide more flexibility to allow a user to run any command. (With SSH, there can be restrictions implemented if desired. However, the same software can easily allow a user to flexibly run any command. So software in this section doesn't necessarily always need to provide such maximum flexibility, but doing so is rather straightforward and easy.)


The plus side is that this is free, and widely supported. This can even be done on Microsoft Windows. The less pleasant side is that this may require some effort to set this up in advance. This solution is great for people who have the time to set this up, and can be an excellent way to implemented automated solutions.

Many Unix systems use Portable OpenSSH, reducing the need to get that software installed. Many of the systems that come with that software pre-installed will also have keys being pre-generated. Therefore, the only remaining steps needed might be to ensure that user accounts are created, and enable network connectivity.

Further details about this approach can be found in the section about Running an OpenSSH server.

[#rmtprcal]: Using Microsoft Remote Procedure Call

The following solutions are believed to use Microsoft Remote Procedure Call (“RPC”). Some further discussion about using RPC is currently at: RPC security ports.

One advantage to using RPC is that the support is often built into Microsoft Windows operating systems, so these solutions may work rather easily without advance setup.

Remote Command Executor (RemCom)

Remote Command Executor (RemCom) Project Page at SourceForge identifies this as having a BSD License. RemCom version 1.2 downloads seems to have been the latest version for at least 8 years (from 2006 through at least March of 2015). RemCom Author's Review seems to be written by the author of the program, and notes that this works on NT 4.0, Win2K, and newer (XP and Server 2003, including X64 versions).

C:\> net user remcmusr remcmpwd /ADD
The command completed successfully.

C:\> echo %ERRORLEVEL%

C:\> echo remcmpwd | remcom . /user:remcmusr /pwd:* cmd
C:\> remcom . /user:remcmusr /pwd:* cmd

  Remote Command Executor
  Copyright 2006 The WiseGuyz [ ]
  Author: Talha Tariq []

Enter Password: remcmpwd

Local Admin
Localhost entered for Target Machine .. Going to RunAs Command

Launching Local Process ...

C:\> echo %ERRORLEVEL%

C:\> net user remcmusr /DELETE
The command completed successfully.

C:\> echo %ERRORLEVEL%

  • The period after remcom indicated that the local machine is the one that was intended.
  • RemCom Author's Review notes, “On local machines it is also able to impersonate so can be used as a silent replacement for Runas command.”
  • The program seemed picky about using a username and a password, even in cases where the PsExec (which has been distributed by Microsoft) did not have an issue (without needing to specify the username).
    • This is based on an experience with Windows 10, which is much newer than RemCom 1.2
  • All command line parameters, for the command that gets run remotely, seemed to be ignored. (Trying to surround the command with quotation marks did not seem to help at all.)
  • During some testing, there were times when it didn't seem to work. The program seemed to freeze up. Further attempts to work with the program resulted in the problem seeming to be fixed on its own.
  • When using “ /pwd:* ”, the program did not seem to want to accept standard input that was redirected from another program. So interactive use seemed to be required.

An attempt was made to try to use the remote functionality.

C:\> net localgroup Administrators remcmusr /ADD
The command completed successfully.

C:\> echo %ERRORLEVEL%

C:\> whoami

C:\> remcom \\systemName /user:remcmusr /pwd:* cmd

  Remote Command Executor
  Copyright 2006 The WiseGuyz [ ]
  Author: Talha Tariq []

Enter Password:remcmpwd

Initiating Connection to Remote Service . . .  Failed

Couldn't connect to \\systemName\ADMIN$
Access is denied.

C:\> echo %ERRORLEVEL%

C:\> net user remcmusr /DELETE
The command completed successfully.

C:\> echo %ERRORLEVEL%


A solution which allows re-distribution of the binary files. PowerAdmin Exec. Also, GitHub for PAExec distributes source code. However, the license does have some limitations about things like changing the software.

[#inpsexec]: PSExec

This has the nice option of being able to work with many machines, without needing to pre-install software on that machine. The software was released by SysInternals, which has since been bought out by Microsoft. Now this software is distributed by Microsoft. The software is free, in the sense that financial payment is not required to obtain it directly from Microsoft.

PsExec home page

Executables are also distributed.

In addition to requiring RPC network traffic, PsExec uses the Admin$ share, so network traffic related to SMB file sharing needs to be enabled:

Required communications
SMB File Sharing

SMB file sharing

This is because the Admin$ share is used, as described here:

Within the PsExec executable file, there is another program: “a Windows service named Psexesvc”. Psexesvc is “embedded” within the PsExec program. PsExec obtains the Psexesvc program out of PsExec's “eecutable image”, and then PsExec proceeds by “copying it to the Admin$ share of the remote system.”

(Quoted text came from the last section of PsExec. That section was titled “Inside PsExec”.)


After using the Admin$ share to install the Psexesvc service, “PsExec then uses the Windows Service Control Manager API, which has a remote interface, to start the Psexesvc service on the remote system.”

(This description of actions comes from the last section of PsExec. That section was titled “Inside PsExec”.)

Usage notes

If the system is using user account control (“UAC”), running from an elevated command prompt helped. When trying to work with localhost, using an elevated command prompt prevented an error message that said “Couldn't access localhost:” “Access is denied.

C:\> PsExec \\localhost cmd

PsExec v2.2 - Execute processes remotely
Copyright (C) 2001-2016 Mark Russinovich
Sysinternals -

Microsoft Windows [Version 10.0.10586]
(c) 2015 Microsoft Corporation. All rights reserved. C:\WINDOWS\SYSTEM32\> dir

cmd exited on localhost with error code 0

C:\> echo %ERRORLEVEL%

This works fine. As demonstrated, after running the first command, there was an ability to run another command.

Note that if pressing Ctrl-C, this will not only interrupt a command such as dir, but it will break the remote session.

Since dir is a built-in command, it cannot be run directly. However, the following can work:

C:\> PsExec \\localhost cmd /c dir

The remote session may seem interactive, particularly when running a command like CMD and then running one command, reviewing output, and then typing another command. However, there may be some limits on how much can be interacted. For instance, when running CMD, trying to use that CMD session to run RunAs may result in RunAs being unable to interact with the user to type a password.

(A workaround for this particular problem might be to try running RunAs directly, instead of from CMD?)

At the time of this writing, little research was done exploring these limits. If you want to run a command interactively, try it before getting too excited about using this option.

PsTools name

The “Ps” part of the name refers to the word “Process”. The choice to start the program's name with “Ps” was not really strongly based on a reference to the idea that the program starts processes. After all, PsGetSid has very little to do with processes. The software starts with Ps as a sort of branding technique. A bunch of software released by the same person (“Mark Russinovich”) or group (“Sysinternals”/“Winternals”/“ntinternals”), also including Bryce Cogswell). As noted by PsTools home page,

“The "Ps" prefix in PsList relates to the fact that the standard UNIX process listing command-line tool is named "ps", so I've adopted this prefix for all the tools in order to tie them together into a suite of tools named PsTools.

The name of the Unix tool “ps” is meant to be an abbreviation of the word “process”.

This claim matches the claim made by PsExec:

“Incidentally, the reason that the suite is named PsTools and that all the member tools have Ps as a prefix to their name is that the first tool I developed that satisfied the listed criteria was PsList, a program that lists running processes. I named the tool after the ps utility that performs the same function on UNIX systems.”

What this tells us is that the remote functionality of many fo these tools is not using some sort of secret technology, buried deeply within Windows, that uses a name of “process”. Instead, the remote technology is described by the “Inside PsExec” section at the end of the PsExec article.



WMIC /NODE:remoteSysName /USER:UserName PROCESS CALL CREATE "CMD /C dir C: >> C:\Temp\output.txt"

(Note, C:\Temp\ may not typically exist by default. Perhaps using %TEMP% would be more compatible, although the literal location would likely vary as %USERNAME% varies.)

Be aware that you will not be able to interact with the program. Also, you will not be able to see the program's “standard output” stream. If you need to see that stream, either use redirection to a text file (as shown in the prior example), or use another software solution for running remote commands from the command line.

(Further details are available about using WMIC remotely.)

For similar technologies, perhaps see: Wikipedia article for Distributed Computing Environment / Remote Procedures Calls (“DCE/RPC”): “Alternative versions and implementations” section (and the remaining part of the article).

Redirecting shells
[#shelonnc]: Redirecting shells with netcat

A wonderful piece of software called netcat allows users to do some interesting tasks over network connections, including things like redirecting shells or transferring files. (For information about an implementation of transferring files with netcat, you can see the section on Using dd/nc/ssh with pv.)

Note: This can work. Further details are NOT readily available here at this time. (That should be changed in the future....)

Other solutions

Unless noted otherwise, there is the simple possibility that the specific technologies used (including specific protocols, which may affect compatibility with specific software running on remote machines) may simply be unidentified by the author of this text. Such software may be using different technologies than the software mentioned in the prior sections. Some of the software in this section may move to a prior section (for instance, the section on software using “Microsoft Remote Procedure Call”) once the process has been identified by the maintainer of this text.

[#mtspsexc]: MetaSploit's PSExec

MetaSploit is software that isn't discussed often on this site because much of its functionality has led to the software's usage to be shunned by organizations that want activities to be done in a rather proper fashion. (Relying on a process which requires using known security vulnerabilities can be a less attractive of an option than a course of action that includes fixing known security vulnerabilities.) In brief, MetaSploit's design simplifies the ability to interact with known vulnerabilities that remain.

However, this topic is a known exception where mentioning MetaSploit may be useful, because a quick mention of MetaSploit may help to reduce some potential confusion.

MetaSploit can use modules, and it has a module called PSExec. This may be a bit confusing since there is also a very popular called PSExec (which has been distributed by Microsoft).

Microsoft PowerShell

(Brief reading has suggested and Microsoft PowerShell may have a way to remotely run scripts. Further information is not being provided right here, at this time.)

[#mswrmtex]: Remote.exe

A Remote.exe has been made by Microsoft, and released as part of the Windows Support Tools collection, which might be part of the disc image found on the operating system's official optical media.

TechNet: Remote.exe Overview has additional hyperlinks in the left frame.

xCmd, xCmd an Alternative to PsExec : “We Don't Need No Stickin' PSExec” mentions some other options (smbexec, winexe)

[#bedumtrm]: Interacting as a dumb terminal

The modern method is to use SSH. A less modern approach is to use telnet. Before Internet access was popular, programs to interact with SSH will also support using a serial port.

Multi-platform Dumb Terminals

Note: Before trying to use some of this software for Unix, you may wish to check out the “Dumb terminals for Unix” section for some information about using such software on that type of platform.

The following have been known to be released for Unix and Microsoft Windows platforms.


Qodem may be an option.


SyncTERM may be a nice option. (This is made by the same author as Synchronet (BBS software).)


PuTTY may be a nice option. (For Unix, see: PuTTY for Unix. For Microsoft Windows, see: SSH: PuTTY for Microsoft Windows. Or, more specifically, see SSH: code based on PuTTY for CogWheel's “Customized PuTTY for Prettier TradeWarring”, which is also available as part of Freeexe for ReactOS/Microsoft Windows.)

MysticBBS Downloads has a section for NetRunner, available for Microsoft Windows and both 32-bit and 64-bit Linux

Etherterm may look like a console application, but is graphical. EtherTerm added Zlib License

Dumb Terminals for Unix

Unix program(s) that could do that include:

ports devices

Serial ports might be named /dev/cua?? (e.g., in OpenBSD, and possibly older Linux versions) or /dev/ttyS? (e.g., in more modern Linux versions).

Once the software is known to be installed, before struggling with this software, this guide recomends first ensuring you can access the serial port. For instance, if /etc/cua00 is owned by a group named “dialer”, then make sure you are part of that group. Or, if /etc/ttyS0 is owned by a group named “dialout”, then make sure you are part of that group. (See: groups.)

However, those details likely vary by operating system. (The serial port might be named something different, as well as the group associated with that device.)


This was included in an old operating system release, 4.2BSD, so it may be pre-installed in a number of operating systems. (e.g., OpenBSD)

perhaps cu -- (Omen Technology: “What's NEW” page has/had a note about Unix File Transfer Clients that described software that was “designed to be called from programs such as Kermit, tip, and certain versions of” cu. “The calling program must completely suspend itself when calling this client; some versions of” cu “do not meet this requirement.”)


Wikipedia's article on tip (Unix utility)

This was included in an old operating system release, 4.2BSD, so it may be pre-installed in a number of operating systems.



e.g., to use 9600 bps 8N1 you could use:

env MINICOM="-c on -o -z -l -D /dev/ttyS0 -b 9600 -8" minicom

Minicom's home page looks designed exclusively for developers, and so does not provide documentation for end users. (That might change when the hosting site gets a “Mercurial plugin”?) Some information about the software can be seen by viewing Minicom's “man page” at (The name of that website is not named after the concept of death, but rather the singular version of the word “dice”.)

To quit, use Ctrl-A and then q? (Naturally, if you are using the terminal multiplexor software named “screen with the default prefix key of Ctrl-A, then the sequence to push would be Ctrl-A, then a, and then q.)

Dumb Terminals for Microsoft Windows

Some version of Microsoft Windows came with a version of Hilgraeve's HyperTerminal. This was a nicer option than Microsoft's more simplistic Terminal, which has been known to be bundled with Windows.


For DOS, a shareware gem known as {Commo} provided a nice amount of features with a small size, including a high level of automation. However, it was closed source (shareware) and may have had a bit of a higher learning curve than some other options. TOOGAM's Software Archive: Terminal Software lists this and some other options.

Note: Some further details, related to the reasons why many people may be interested in this software, might be mentioned by communications hardware section. For instance, the sub-section on a dial-up modem: POTS modem has a reference to POTS modem speeds, and the sub-section on Cisco professional level equipment has references like the introduction to using Cisco professional-level equipment and the Cisco IOS basic usage guide.


Chrome Remote Desktop may be useful for people with the Chrome web browser, including those who are using Google's ChromiumOS/ChromeOS.