Senin, 22 Agustus 2005

Windows Remote Administration Options

This morning I worked with several remote administration tools on my Windows Server 2003 system. First I enabled the native Remote Desktop (aka Terminal Services) capability via My Computer -> Properties -> Remote

At this point I am only letting administrator connect remotely. Since administrator can connect remotely by default once the service is activated, I didn't need to make any other changes. Once Remote Desktop is listening, it will appear active on port 3389 TCP.

To access the Windows server remotely from Unix using the RDP protocol, I use Rdesktop. It's available in the FreeBSD ports tree as net/rdesktop. I like the option to change screen geometry, e.g., 'rdesktop -g 80% 192.168.2.2'.

To access the RDP server from my Windows 2000 laptop, I installed the MSRDPCLI.EXE package.

Next I tried RealVNC. This program has client and server components. I installed the entire package on the Windows server. Setup is fairly simple, and the server should be configured to accept clients that enter a pre-defined password. RealVNC starts two listening services. One can access a Web page with a Java-enabled VNC service on port 5800 TCP. The default native VNC server listens on port 5900 TCP.

To access the Windows server remotely from Unix using the VNC protocol, I use vncviewer, packaged with RealVNC. It's available in the FreeBSD ports tree as net/vnc. To send ctrl-alt-delete through VNC, I like to hit the F8 key to bring up a VNC menu, through which I select "Send ctrl-alt-del".

There is an importance difference between using RDP and VNC on Windows Server 2003. RDP is a Terminal Services application, which allows multiple users to remotely interact with the server. VNC takes control of the physical desktop. For example, I was able to run one RDP instance and then use VNC to connect to the server. Neither session was interrupted by the other. Also, RDP seems to be more efficient and responsive, although I have not sought to tweak VNC.

Note that (thanks to comments from Blog readers), I found Rdesktop allows one to "attach to console" if passed the -0 command, like this:


rdesktop -0 192.168.2.2

This eliminates the need to use VNC, in my opinion.

I noticed that I could not get VMWare to start a guest OS when I was logged in to the Windows Server 2003 box using RDP (not attached to the console). I could start a guest when logged in using VNC. I typically set a screen geometry because VNC doesn't appear to have a menu option for it, e.g. 'vncviewer geometry="1024X768"'.

With rdesktop -O, I can attach to the console and hence start VMs properly over RDP.

inally I installed OpenSSH. I considered installing the SSH for Windows package, which is a stripped-down Cygwin version. Since that program had not been updated in over a year (i.e., 3.8.1), I decided to use the complete Cygwin version. Nicholas Fong's guide was extremely helpful.

I followed all of his instructions. Remember to add a new environment variable where 'variable name' is CYGWIN and 'variable value' is ntsec tty. Also add ';c:\cygwin\bin' to the PATH.

I noticed a different set of prompts when I ran 'ssh-host-config', so here is how I proceeded.

$ ssh-host-config
Generating /etc/ssh_host_key
Generating /etc/ssh_host_rsa_key
Generating /etc/ssh_host_dsa_key
Generating /etc/ssh_config file
Privilege separation is set to yes by default since OpenSSH 3.3.
However, this requires a non-privileged account called 'sshd'.
For more info on privilege separation read /usr/share/doc/openssh/README.privsep.

Should privilege separation be used? (yes/no) yes
Warning: The following function requires administrator privileges!
Should this script create a local user 'sshd' on this machine? (yes/no) yes
Generating /etc/sshd_config file

Warning: The following functions require administrator privileges!

Do you want to install sshd as service?
(Say "no" if it's already installed as service) (yes/no) yes

You appear to be running Windows 2003 Server or later. On 2003 and
later systems, it's not possible to use the LocalSystem account
if sshd should allow passwordless logon (e. g. public key authentication).
If you want to enable that functionality, it's required to create a new
account 'sshd_server' with special privileges, which is then used to run
the sshd service under.

Should this script create a new local account 'sshd_server' which has
the required privileges? (yes/no) yes

Please enter a password for new user 'sshd_server'. Please be sure that
this password matches the password rules given on your system.
Entering no password will exit the configuration. PASSWORD=obscured

User 'sshd_server' has been created with password 'obscured'.
If you change the password, please keep in mind to change the password
for the sshd service, too.

Also keep in mind that the user sshd_server needs read permissions on all
users' .ssh/authorized_keys file to allow public key authentication for
these users!. (Re-)running ssh-user-config for each user will set the
required permissions correctly.

Which value should the environment variable CYGWIN have when
sshd starts? It's recommended to set at least "ntsec" to be
able to change user context without password.
Default is "ntsec". CYGWIN=

The service has been installed under sshd_server account.
To start the service, call `net start sshd' or `cygrunsrv -S sshd'.

Host configuration finished. Have fun!

Administrator@moog ~
$ net start sshd
The CYGWIN sshd service is starting.
The CYGWIN sshd service was started successfully.

Using SSH to access Windows is the most bandwidth-efficient remote access system possible.

ssh administrator@192.168.2.2
administrator@192.168.2.2's password:
Last login: Mon Aug 22 06:20:58 2005 from 192.168.2.5

Administrator@moog ~
$ df -h
Filesystem Size Used Avail Use% Mounted on
C:\cygwin\bin 9.8G 5.1G 4.7G 53% /usr/bin
C:\cygwin\lib 9.8G 5.1G 4.7G 53% /usr/lib
C:\cygwin 9.8G 5.1G 4.7G 53% /
c: 9.8G 5.1G 4.7G 53% /cygdrive/c
g: 60G 53G 7.3G 88% /cygdrive/g
h: 70G 50G 20G 73% /cygdrive/h

Administrator@moog ~
$ who
sshd_server tty0 Aug 22 06:20 (MOOG)
Administrator tty1 Aug 22 06:56 (192.168.2.5)

It appears the 'who' command is not aware of an existing RDP session.

I was hoping I would find an easy way to configure Windows through a serial port. Unfortunately, Windows is not Unix. The closest approximation I found was Emergency Management Services (EMS), which requires motherboard support. EMS is definitely not as simple as modifying /etc/ttys.

I'm concerned with remote administration because this Windows server is in my lab. Also, I am trying to imagine the best way to change the system's IP address remotely, or at least in a headless situation. For example: I bring my Shuttle Windows server to class. The box has no monitor. I decide I need to change the system's IP address to use DHCP in a classroom setting, or to set a new static IP address. Using my laptop, I connect to the server (using on of these methods) and change the IP.

I plan to use one or more of these netsh commands. I can run these as a batch file or through the scheduler.

netsh interface ip show config

netsh interface ip set address name="Local Area Connection" static 192.168.0.100
255.255.255.0 192.168.0.1 1

netsh -c interface dump > c:\location1.txt

netsh -f c:\location1.txt

netsh interface ip set address "Local Area Connection" dhcp

netsh interface ip set dns "Local Area Connection" static 192.168.0.200

netsh interface ip set dns "Local Area Connection" dhcp

These are not the actual commands I would run, only examples of what is possible.

From a Windows system, one other option exists: PsExec. For example:

C:\Program Files\pstools>psexec \\192.168.2.2 -u administrator -p "password"
cmd.exe /c cmd.exe

PsExec v1.58 - Execute processes remotely
Copyright (C) 2001-2005 Mark Russinovich
Sysinternals - www.sysinternals.com

Microsoft Windows [Version 5.2.3790]
(C) Copyright 1985-2003 Microsoft Corp.

C:\WINDOWS\system32>cd
C:\>ipconfig

Windows IP Configuration

Ethernet adapter Local Area Connection:

Connection-specific DNS Suffix . :
IP Address. . . . . . . . . . . . : 192.168.2.2
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 192.168.2.1


Does anyone have any suggestions?

0 komentar:

Posting Komentar