MKS Toolkit. Connectivity Solutions Guide. MKS Inc.

Transcription

1 MKS Toolkit Connectivity Solutions Guide MKS Inc.

2 MKS Toolkit: Connectivity Solutions Guide 2005 MKS Software Inc.; in Canada copyright owned by MKS Inc. All rights reserved. MKS, MKS Toolkit, and AlertCentre are registered trademarks of MKS Inc. NuTCRACKER is a registered trademark of MKS Software Inc. All other trademarks referenced are the property of their respective owners. MKS Inc Fair Lakes Circle Suite 350 Fairfax, Virginia Phone: Fax: [email protected]

3 Technical Support To request customer support, please contact us by one of the means listed below and in your request include the name and version number of the product, your serial number, and the operating system and version/patch level that you are using. Contact MKS customer support at: Web: Telephone: (9:00am to 7:00pm Eastern, Mon-Fri) Fax: When reporting problems, please provide a test case and test procedure, if possible. If you are following up on a previously reported problem, please include the problem tracking number in your correspondence. Finally, tell us how we can contact you. Please give us your address and telephone number. Connectivity Solutions Guide iii

4 iv MKS Toolkit

5 Table of Contents 1 Introduction Connectivity Basics...3 What is Connectivity?...3 Connectivity in a Windows Environment...3 Connectivity in a Mixed Environment...4 The MKS Toolkit Connectivity Suite...5 Access Remote Systems...5 Graphical Connections...6 Secure Communication...6 Comparing Different Approaches Remote Utilities...9 Remote Shell...9 rsh Basics...10 Specifying a User Name...10 Executing Multiple Commands...10 Connecting as a Domain User...11 Redirection...11 Remote Execution...12 rexec Basics...12 Specifying a Password...13 Specifying a User Name...13 Connecting as a Domain User...14 Redirection...15 Remote File Copying...15 rcp Basics...15 Copying Files Between Two Remote Machines...16 Copying Files to a Directory...17 Copying Directories...17 Copying Files as a Domain User...18 Remote Login...18 rlogin Basics...18 Specifying a User Name...19 Remote Services...20 Starting and Stopping the Services...20 Authentication...21 rshd Authentication...21 Connectivity Solutions Guide v

6 Table of Contents rexecd Authentication...22 rlogind Authentication Secure Utilities...25 Secure Shell Client...26 Secure X Secure Shell Service...27 Authentication Agents...28 Secure FTP...29 Changing the Current Directory...30 Listing Directory Contents...30 Transferring Files...30 Visual SFTP...31 Making a Connection...32 Changing Directories...32 Copying Files...33 Renaming Files...33 Running Files...33 Secure Copy...33 Advanced Options The Telnet Server...35 Initializing the MKS Telnetd Service...35 Initiating a Telnet Session The X Terminal Emulator...37 Using xterm Tasks...41 A Sample Network...41 Choosing a Connectivity Tool...42 Administering Remote Servers and Workstations...44 Deploying Applications Throughout the Enterprise...45 Accessing Remote X11 Applications...46 Performing Distributed Builds and Automated Testing...47 A Configuring the Connectivity Suite...49 Configuring the Remote Utilities...49 From the Control Panel Applet...49 The Authentication Tab...50 The Rexecd/Rshd Tab...51 The Rlogind Service Tab...53 From the Command Line...54 The rconfig Utility...54 vi MKS Toolkit

7 Table of Contents The rsetup Utility...56 Authentication Files...57 The hosts.equiv File...57 The.rhosts File...59 The.netrc File...60 Configuring the Secure Utilities...61 From the Control Panel Applet...61 The Secure Shell Client Tab...62 The Secure Shell Service Tab...68 Authentication Keypairs...74 Generating Keypairs...75 Passwordless Authentication...77 SmartCard Support...78 Problems with Passwordless Authentication...79 Smartcard Solutions...79 Smartcards and Windows...80 Using Smartcards with the Secure Utilities...80 Configuring from the Control Panel Applet...81 Troubleshooting...82 Configuring the Telnet Server...83 Index...87 Connectivity Solutions Guide vii

8 Table of Contents viii MKS Toolkit

9 Introduction 1 Today s enterprise often has a computing environment that consists of many machines running a mix of Windows and legacy operating systems. While these machines may be able to communicate with each other through network connections, it is not always easy to access all the applications and data that exist on this multitude of machines, especially when you need to access a machine running a legacy operating system from one running Windows. Fortunately, there are tools that can make this easier. One such set of tools is the MKS Toolkit Connectivity Suite. Based on industry standards, the MKS Toolkit Connectivity Suite lets you accomplish a variety of tasks from a single machine anywhere in your network. These tasks include: Administering remote servers and workstations Deploying applications throughout the enterprise Distributing data to remote file stores Accessing remote source trees Performing distributed builds and automated testing This document guides you the basic concepts and techniques associated with connectivity, through how to use and configure the tools in the MKS Toolkit Connectivity Suite to examples of how you can use those tools in combination with other MKS Toolkit and Windows utilities to perform the tasks listed above. Chapter 2: Connectivity Basics provides an overview of some of the basic concepts involved with connectivity, describes the contents of the MKS Toolkit Connectivity Suite, and discusses how to choose the right utility to use in various circumstances. Chapter 3: Remote Utilities discusses the various remote utilities and how to use them. Chapter 4: Secure Utilities covers the various secure utilities and how to use them. Connectivity Solutions Guide 1

10 Introduction Chapter 5: The Telnet Server describes the MKS Toolkit telnetd service and how to use standard telnet utilities to connect to it. Chapter 6: The X Terminal Emulator describes how you can use the xterm utility to communicate with graphical X Windows applications on remote machines. Chapter 7: Tasks describes the sample network used throughout this document, advises you on how to choose the right connectivity tool for the job and provides examples of using the MKS Toolkit Connectivity Suite to perform common enterprise connectivity tasks. Appendix A: Configuring the Connectivity Suite provides instructions on configuring the MKS Toolkit Connectivity Suite. 2 MKS Toolkit

11 Connectivity Basics 2 This chapter introduces the concept of connectivity, discusses connectivity in both Windows and mixed environments, and provides an overview of the MKS Toolkit Connectivity Suite. What is Connectivity? What is connectivity? Connectivity is much more than just being able to access files on a different machine. That is a basic capability of most networks. Connectivity, for the purposes of this document, refers to the ability to create a connection (either secure or insecure) from your local machine to a remote machine and use that connection to run commands on the remote machine as though you had actually logged directly into that machine. Connectivity in a Windows Environment When working in a Windows environment, there are many options for connecting between machines. In addition to the tools provided with Windows NT/2000/XP Pro systems, there are many third-party applications dedicated to the task. Many of these solutions work by actually displaying the desktop of the remote machine on your local machine. Windows Terminal Server (now called Remote Desktop on Windows XP) is a classic example of this. Some of these, like PC Anywhere, let you control the remote machine using the displayed desktop, while others merely display the desktop and allow no interaction. While these graphical applications usually do a good job of recreating the remote desktop on your local machine, the large amount of Connectivity Solutions Guide 3

12 Connectivity Basics data that must be transferred to maintain the graphical display can cause any interaction with the remote machine to be slow and inefficient, especially for low bandwidth connections or small simple tasks. In contrast, command-line connectivity tools, like those provided in the MKS Toolkit Connectivity Suite, have a significantly lighter transfer load, and thus, are faster and more efficient, even over low bandwidth connections. With these tools, you can, from your local machine, perform virtually any command-line task on the remote machine that you could you perform if you were logged in directly. This type of connection has been available on legacy systems since their inception and is only more recently available for Windows. You can even choose between interactive and non-interactive sessions as well as secure and insecure versions of the tools depending on your specific preference and the application and environment for the tool. And when you combine the tools of the MKS Toolkit Connectivity Suite with other MKS Toolkit or Windows utilities, you have the building blocks for a complete Windows connectivity solution. Connectivity in a Mixed Environment Many modern computing environments include both Windows and legacy systems, such as UNIX (or Linux). The MKS Toolkit Connectivity Suite is compatible with these operating systems as well as any other supporting the standard protocols of the tools discussed. Note This section focuses on mixed environments consisting of Windows and UNIX systems. However, due to similarity between UNIX and Linux systems, the techniques discussed for connecting to UNIX systems can also be applied to Linux systems. It is important, when working in a mixed computing environment, to utilize tools that conform to industry standards. This ensures that processes and operations behave the same regardless of the client and server operating systems being used. For example, although native Windows file sharing or other network file sharing solutions could be acceptable for internal file copying needs, what if you have to copy these files between remote Windows and systems? Native FTP has been the solution because of its availability on multiple platforms 4 MKS Toolkit

13 The MKS Toolkit Connectivity Suite and because of its ease of use. With the secure utilities, sftp and scp, you get a standards-based cross-platform mechanism to move files securely across insecure networks. The MKS Toolkit Connectivity Suite The connectivity components available in the MKS Toolkit products provide you with the means to interactively access remote Windows, UNIX, and Linux machines. Single connect versions of each of these tools come standard with all MKS Toolkit products (unlimited connect versions are available directly from MKS). Access Remote Systems Graphical Connections Secure Communication Access Remote Systems Most routine tasks that you need to do on a remote system, whether it is a UNIX/Linux or Windows system, can be done via the command line. MKS Toolkit offers a variety of client/server tools and utilities that provide command line access to the systems on your network. Feature Remote Clients Description The rsh and rexec utilities execute commands on a remote machine. The rexec utility is used to execute a single command, while rsh creates a command shell on the remote machine and executes a command in that shell. The rcp (remote copy) command moves files between machines. It uses the same mechanism as rsh, so if you can rsh to another machine, you can easily copy files. You can even do third-party copies where neither the source nor the target files reside on your machine. If you need to do more than execute a command on a remote machine or copy a file to or from it, you should start a login session on it. Using rlogin, you can establish a remote session on any machine that is running an rlogind daemon. Connectivity Solutions Guide 5

14 Connectivity Basics Feature Remote Services Telnet Server Xterm Description The MKS Toolkit Connectivity Suite includes rshd, rexecd, and rlogind services that let your Windows machine respond to rsh, rcp, rexec and rlogin requests from other Windows or legacy machines. This full-featured telnet server (telnetd) for Windows, lets any machine on the network with a telnet client establish a telnet session on the Windows machine. The xterm X terminal emulator allows you to create a graphical command shell on Windows for interactive access to remote UNIX/Linux systems. Graphical Connections Secure Communication MKS offers a full array of X servers for displaying X Window System based graphical applications, including OpenGL and Motif applications, on Windows. A network-capable server can display a graphical application on your Windows workstation from any machine on your network. A local-only server can display only applications that you have migrated to the Windows workstation using one of the MKS Toolkit development products. The MKS Toolkit Connectivity Suite also includes an xterm client for command line access to remote systems. The secure utilities provided with MKS Toolkit are a suite of tools that allow for secure communication between different machines. This suite is a port of OpenSSH and OpenSSL, and, hence, should be completely compatible with UNIX/Linux systems that are running these tools. In addition, the secure tools interoperate with other Windows machines that have an MKS Toolkit product installed. Feature Secure Clients Description For environments requiring secure and encrypted connections to remote machines, MKS Toolkit provides secure counterparts to the remote utilities. secsh (secure shell) and scp (secure copy) provide a secure command shell and secure file copy operations on remote Windows or legacy machines. In addition, the Connectivity Suite provides sftp (secure FTP) an interactive file transfer program, similar to ftp, which performs all file copy operations over the encrypted secsh transport. 6 MKS Toolkit

15 Comparing Different Approaches Feature Secure Services Secure X11 Description The MKS Toolkit Connectivity Suite includes secshd and sftp-server services that let your Windows machine respond to secsh and sftp requests from other Windows or legacy machines. The MKS Toolkit secure utilities can create a secure X11 connection as well as the normal shell window. The X connection (for arbitrary TCP/IP ports) is automatically tunneled through the secure connection and the secure shell client opens the connection to the X server on your client machine. Comparing Different Approaches The following table shows the pros and cons of using the various common connectivity approaches. While there is significant overlap between the approaches, as the table shows, each has its advantages. Approach Pros Cons Windows Terminal Server Useful for displaying graphical Windows applications Windows-only solution Uses extensive memory on the server Poor choice for use over a slow connection Limited cut and paste from server window to desktop windows Requires license for each session Connectivity Solutions Guide 7

16 Connectivity Basics Approach Pros Cons X Windows and xterm Telnet Secure utilities Remote utilities Useful for displaying graphical X Windows applications Offers full cut and paste from remote machine to desktop Good choice for use over a slow connection Full control over fonts Window easily resized dynamically Can be tunneled via secure shell Ubiquitous, with a large choice of clients, including the native Windows client All connections are encrypted. Can tunnel command-line or graphical X Windows connections, as well as FTP Very good solution for scripts that need to cause things to happen on remote machine xterm useful only for command-line, characteroriented input and output Requires an X server on the Windows client Runs on Windows NT/ 2000/XP only. telnet useful only for command-line, characteroriented input and output Insecure Not a good choice on a slow connection Number of incoming connections may be restricted by licensing telnet server (telnetd) runs on Windows NT/2000/ XP only. Secure shell service (secshd) runs on Windows NT/2000/XP only. Useful only for commandline, character-oriented input and output Insecure 8 MKS Toolkit

17 Remote Utilities 3 For more information on the individual utilities, see the appropriate reference pages in the online MKS Toolkit Utilities Reference. The remote utilities provided as part of the MKS Toolkit Connectivity Suite allow communication and interoperability between one machine running a remote client utility and another running the appropriate remote service (or a similar daemon on legacy systems). The remote utilities includes the following client and server components: Component rsh Description remote shell client rshd rexec rexecd rcp rlogin rlogind remote shell service (daemon) remote command execution remote execution service remote file copy remote login remote login service The server components (rshd, rexecd, and rlogind) are supported only on Windows NT/2000/XP systems. The client components (rsh, rexec, rcp, and rlogin) are supported on Windows NT/2000/XP and Windows Me systems. Remote Shell For more information about the rsh utility, see the rsh reference page in the online MKS Toolkit Utilities Reference. The remote shell client is the rsh utility. This utility connects to an rshd service (or daemon) running on a remote system which executes the specified command on that system. Connectivity Solutions Guide 9

18 Remote Utilities rsh Basics For details on the sample network used in these examples, see A Sample Network on page 43. For details on setting up authentication files for the rshd and rexecd services, see Configuring the Remote Utilities on page 51. Specifying a User Name Executing Multiple Commands The basic form of rsh is: rsh remote_system command In this form, the specified command is run on remote_system using the same user name with which you are currently logged into your local system. Or more correctly, the rshd service (or daemon) running on the remote_system actually runs the command. For example, using the sample network described elsewhere in this document, if Sandy is logged into the local machine venus with the user name of Sandy, then the command: rsh zeus pwd runs the pwd utility on the UNIX machine zeus and displays the result on standard output. This example assumes that rshd is running on zeus., the user name Sandy has a valid account on zeus, and that the appropriate authentication files are set up so that Sandy can access zeus from venus. These assumptions (or similar ones) hold for all the examples that follow in this section. However, most situations are not this simple. For example, the user Dale has an account on the local machine mars with the user name of Dale, but Dale s account on zeus has the user name djdowns. This means that Dale needs to specify the zeus user name djdowns when connecting with the rsh utility. There are two ways to do this: rsh zeus -l djdowns ls *.c rsh djdowns@zeus ls *.c This informs rshd on zeus that the specified command is to be run as the user djdowns. When you connect to a remote system using rsh, the specified command is executed in the home directory associated with the user name being used on the remote system. Thus, in this example, the ls *.c command display all files with a.c extension in the home directory associated with the user name djdowns. You can use the rsh utility to execute multiple commands on a remote system. For example, instead of listing all the *.c files in the djdowns home directory on zeus, suppose Dale wanted to list all the *.c files in the /src directory on zeus. It would first be necessary to change to the /src directory and then list the *.c files found there. At first, it would seem that the command: rsh zeus -l djdowns cd c:/src; ls *.c 10 MKS Toolkit

19 Remote Shell should do the trick. However, what actually happens is that the semicolon is interpreted by the local shell and the ls *.c command is executed as a command on the local system. However, by enclosing the commands to be executed in quotes, you can prevent the local shell from interpreting any special shell characters such as the semicolon. Thus, to list all the.c files in the /src directory on zeus, Dale could use: rsh zeus -l djdowns "cd /src; ls *.c" Alternately, the backslash (/) character can be used to "quote" special shell characters and prevent their interpretation by the local shell. For example, Dale could also express the command from the previous example as: rsh zeus -l djdowns cd /src\; ls *.c Connecting as a Domain User This default can be changed to only send the complete user name including domain with an option in the MKS Toolkit control panel applet as described in From the Control Panel Applet on page 51. Redirection So far, the examples shown have dealt with users who log into local systems with user names on that system. However, it is very common for a user to log into a system as a domain user. For example, in the sample network, Robin logs into the local system venus with the domain user name of USERS/ Robin. By default, when Robin uses rsh to connect to a remote system without specifying a user name to use on that system, the full domain user name is sent first (that is, USERS/Robin). If rsh fails to connect using that user name, it tries to connect again using just the user name Robin (that is, the domain portion USERS/ is removed). Similarly, you can specify a domain user name as the user name to use on that system. For example: rsh jupiter -l USERS/guest pwd rsh jupiter -l USERS\\guest pwd rsh USERS/guest@jupiter pwd rsh USER\\guest@jupiter pwd all display the name of the home directory on the Windows system jupiter associated with the domain user name USERS/guest. As previous examples have shown, the standard output from the command executed on the remote system is normally sent to the standard output on your local system. Thus, if Dale runs the following command on mars: rsh zeus -l djdowns ls *.c > listfile.txt the ls *.c command is executed in Dale s home directory on zeus and its output is sent back to mars where it is redirected to the file named listfile.txt. Connectivity Solutions Guide 11

20 Remote Utilities If, however, Dale used the command: rsh zeus -l djdowns "ls *.c > listfile.txt" the output of the command is redirected to listfile.txt in Dale s home directory on zeus. This is because the redirection character > is quoted to protect it from being interpreted by the local system s shell and as a result, it is sent to zeus as part of the command to be executed. Similarly, the command: rsh jupiter -l USERS/guest cat file1 >> local.txt appends the contents of file1 on jupiter to the file named local.txt on the local system, while rsh jupiter -l USERS/guest cat file1 \>\> remote.txt appends the contents of the remote file file1 to remote.txt on jupiter. You can redirect standard error in the same way. For example, suppose Sandy on the local system venus wants to run the script backup.ksh (which backs up the current directory to a tape drive) on the remote system zeus. Sandy can use the following command to accomplish the task: rsh zeus "backup.ksh 2> error.txt" This command displays the standard output of the backup.ksh script on venus while the standard error is redirected to a file named error.txt on zeus. Remote Execution For more information about the rexec utility, see the rexec reference page in the online MKS Toolkit Utilities Reference. rexec Basics The rexec utility is similar to the rsh utility in that it lets you execute a command on a remote system. To do so, it connects to the rexecd service (or daemon) running on the remote system and it is that service which actually runs the command. The basic form of rexec is: rexec remote_system command In this form, the specified command is run on remote_system using the same user name with which you are currently logged into your local system. Or more correctly, the rexecd service (or daemon) running on the remote_system actually runs the command. 12 MKS Toolkit

21 Remote Execution For details on setting up authentication files for the rshd and rexecd services, see Configuring the Remote Utilities on page 51. For details on the sample network used in these examples, see A Sample Network on page 43. Specifying a Password While the rexecd service does use an authentication file similar to those used by the rshd service to authenticate the user issuing an rexec command, it also authenticates any user who can supply the correct password for the user they are connecting as. For example, using the sample network described elsewhere in this document, if Dale is logged into the local machine mars with the user name of Dale, then the command: rexec jupiter pwd runs the pwd utility on the Windows machine jupiter and displays the result on standard output. This works because there is an entry in the.netrc file in Dale s home directory on jupiter specifying that Dale can connect to his account on jupiter from his account on mars. However, if Sandy is logged into the local machine venus with the user name of Sandy, but there is no appropriate.netrc entry in Sandy s home directory on jupiter then the command: rexec jupiter pwd prompts for the password to Sandy s account on jupiter. When the correct password is entered, the command is executed. Alternatively, a password can be specified on the command line with the -p option. For example, Sandy could use the command: rexec jupiter -p passwd pwd where passwd is Sandy s password on jupiter. This would have the same effect as the previous example, except that Sandy would not be prompted for a password. Caution Using the -p option to specify a password is not very secure because the password is displayed on your screen, allowing anyone who can see the screen to read it. Specifying a User Name By default, rexec assumes that you are connecting to a remote account with the same user name as the one with which you are logged onto the local system. However, you can also specify a user name on the command line for those cases where you need to connect with a different user name. Connectivity Solutions Guide 13

22 Remote Utilities For example, Dale s account on the UNIX system zeus has the user name djdowns. As with the rsh utility, there are two ways in which Dale can connect to this account from the local system mars: rexec zeus -l djdowns ls *.c rexec djdowns@zeus ls *.c This tells rexecd on zeus to run the specified command as the user djdowns. As with rshd, the rexecd service executes the specified command in the home directory associated with the user name being used on the remote system. Thus, in the previous example, the ls *.c command displays all files with a.c extension in the home directory associated with the user name djdowns. You can specify both a user name and a password on the rexec command line. For example, in the sample network, there is an account named bldr on the Windows machine named vulcan with a password of bpw999. This account is set up with an environment specifically designed for performing build tasks, in particular, running the build.ksh script which rebuilds the software project that the development team is current working on. By specifying both the user name and the password, the project can be built from any machine in the network with the command: rexec vulcan -l bldr -p bpw999 build.ksh Connecting as a Domain User This default can be changed to only send the complete user name including domain with an option in the MKS Toolkit control panel applet as described in From the Control Panel Applet on page 51. Like rsh, rexec has special handling for domain user names. For example, in our sample network, Robin logs into the local machine venus with the domain user name of USERS/Robin. By default, when Robin uses rexec to connect to a remote system without specifying a user name to use on that system, the full domain user name is sent first (that is, USERS/Robin). If rexec fails to connect using that user name, it tries to connect again using just the user name Robin (that is, the domain portion USERS/ is removed). Again, like rsh, you can specify a domain user name on the command line as the user name to use on the remote system. For example, the following commands all display the name of the home directory associated with USERS/guest on jupiter: rexec jupiter -l USERS/guest pwd rexec jupiter -l USERS\\guest pwd rexec USERS/guest@jupiter pwd rexec USER\\guest@jupiter pwd 14 MKS Toolkit

23 Remote File Copying Redirection For a more detailed description of how redirection works with remote utilities, see Redirection on page 11. The rexec utility handles the standard input, standard output, and standard error streams in the same way as the rsh utility. That is, by default, the standard input for the remote command is read from the standard input of the local system and the standard error and standard output streams of the remote command are sent back to the corresponding streams on the local system. However, by using redirection, the standard output and standard error streams of the remote command can be sent elsewhere. For example, the command: rexec vulcan -l bldr -p bpw999 build.ksh > out.txt places the standard output from the build.ksh script in a file named out.txt in the current directory on the local machine, while the command: rexec vulcan -l bldr -p bpw999 "build.ksh > out.txt" places the standard output from the build.ksh script in a file named out.txt in the home directory of the user bldr on the remote system vulcan. Remote File Copying For more information on rcp, rsh, and rshd, see the rcp, rsh, and rshd reference pages in the online MKS Toolkit Utilities Reference. rcp Basics The rcp utility lets you copy files between machines. This can be between your local machine and a remote machine or between two remote machines. To perform the file copy, rcp uses the rsh utility to connect to a rshd service (or daemon). The basic form of rcp is: rcp source_file destination_file where source_file and destination_file can be either a remote file name of the form: [rname@]rhost:path or a local file name. For remote files, rhost is the name of the remote machine containing the file, rname is the user name on rhost used to perform the file copy, and path is the path name of the file. If the remote user name on rhost is the same as the current local user name, rname can be omitted. Connectivity Solutions Guide 15

24 Remote Utilities For details on setting up authentication files for the rshd and rexecd services, see Configuring the Remote Utilities on page 51. Note Because rcp uses rsh to actually copy the file, the specified user name rname must have a valid account on the remote machine rhost, rhost must be running a rshd service (or daemon) and the appropriate authentication files must be set up on rhost to allow the current user to connect from the local machine. For example, Sandy is logged onto the local system venus with the user name Sandy and wants to copy /usr/scripts/backup.ksh from the UNIX machine zeus to the current directory on venus. Since Sandy s account on zeus also has the user name Sandy, the task can be performed with: rcp zeus:/usr/scripts/backup.ksh backup.ksh However, if Dale, logged on the local system mars as Dale, wanted to perform the same task, the following command would be used: rcp djdowns@zeus:/usr/scripts/backup.ksh backup.ksh Because Dale s user name on zeus (djdowns) differs from the local user name, the remote user name must be included in the remote file name. When the path component of a remote file name is not a full (absolute) path name, it is interpreted relative to the home directory of the specified user rname on rhost. For example, if Dale issues the following command on mars: rcp djdowns@zeus:project.mk project.mk the project.mk file is copied from the home directory associated with the djdowns account on zeus to the current directory on mars. The rcp utility uses a colon (:) to separate the host name and path name. This can create problems when you want to specify file names which contain a colon following a drive letter. To specify such file names on a rcp command line, use an equal sign (=) in place of the colon and prefix the name with a slash (/). For example, to copy the file c:/src/file.c from the local machine venus to /src/file.c on the remote UNIX machine zeus, Sandy would use: rcp zeus:/src/file.c /c=/src/file.c Copying Files Between Two Remote Machines As mentioned earlier, the rcp utility can be used to copy files between remote machines. To do so, you simply specify both the source and destination files as remote files. 16 MKS Toolkit

25 Remote File Copying For example, Dale is logged into the local machine mars as Dale and wants to copy the file c:/src/head.h from the Windows machine jupiter (where Dale has an account also with the user name Dale) to /src/head.h on the UNIX machine zeus. Dale can use the following command to perform the task: rcp jupiter:/c=/src/head.h Copying Files to a Directory Copying Directories You can also use the rcp utility to copy one or more files to a directory. In this case, the rcp command has the form: rcp file1 file2... filen destination_dir where the specified files are either remote or local files and destination_dir is a remote or local directory. For example, Dale could use the command from the local machine mars: rcp djdowns@zeus:/usr/scripts/backup.ksh \ djdowns@zeus:/src/newproject.mk jupiter:/c=/scripts/work.ksh /c=/workdir to copy the /usr/scripts/backup.ksh and /src/newproject.mk files from the UNIX machine zeus and the c:/scripts/work.ksh file from the Windows machine jupiter to c:/workdir directory on mars. You can also use the. and.. specifiers to indicate the current and parent directories, respectively. For example, earlier, Sandy used the command: rcp zeus:/usr/scripts/backup.ksh backup.ksh to copy /usr/scripts/backup.ksh from zeus to the current working directory on venus. This command could also be expressed as: rcp zeus:/usr/scripts/backup.ksh. With the -r option, you can use the rcp utility to copy directories. In this case, the destination must also be a directory. For example, Sandy wants to copy the /src/project directory from the UNIX machine zeus to c:/src directory on the local machine venus. The following command can perform this task: rcp -r zeus:/src/project /c=/src This command also copies any subdirectories under the /src/project directory. Connectivity Solutions Guide 17

26 Remote Utilities When using the -r option, you can copy a combination of individual files and directories to the destination directory. For example, if Sandy also wanted to copy the c:/src/head.h file from jupiter to the c:/src directory on venus, the following command would work: rcp -r zeus:/src/project jupiter:/c=/src/head.h \ /c=/src Copying Files as a Domain User This default can be changed to only send the complete user name including domain with an option in the MKS Toolkit control panel applet as described in From the Control Panel Applet on page 51. Because rcp actually uses rsh to copy files, it handles domain users in the same way as the rsh utility. As seen in earlier sections, Robin logs into the local system venus with the domain user name of USERS/Robin. By default, when Robin uses rcp to copy files to or from a remote system without specifying a user name to use on that system, the full domain user name is sent first (that is, USERS/Robin). If rcp (actually rsh) fails to connect using that user name, it tries to connect again using just the user name Robin (that is, the domain portion USERS/ is removed). Similarly, you can specify a domain user name as the user name to use on that system. For example: rcp USERS/guest@jupiter:file.c. copies the file named file.c in the home directory associated with USERS/ guest on the remote Windows machine jupiter to the current directory on the local machine. Remote Login For more information on the rlogin utility, see the rlogin reference page in the online MKS Toolkit Utilities Reference. rlogin Basics For details on setting up authentication files for rshd and rexecd, see Configuring the Remote Utilities on page 51. The rlogin utility lets you connect to a remote machine running a rlogind service (or daemon) and run a terminal session on that machine. Once connected to the remote machine, you are effectively working directly in a shell or command line interpreter on the remote machine. The basic form of rlogin is: rlogin host where host is the name of the remote machine to which you want to connect. The rlogin utility connects to the remote machine using the current user name (including either your domain name if you are a domain user or your machine name if you are not a domain user). To authenticate this name, the rlogind service or daemon uses the same authentication files as the rshd 18 MKS Toolkit

27 Remote Login service or daemon. If the user name is not authenticated, you are prompted to enter your user name and password for the account on the remote machine to which you want to connect. When rlogin connects to a remote machine, the result is similar to logging into the default shell on that machine directly. The default shell is specified by the value of the SHELL environment variable in the environment associated with the account to which you connected. For example, Sandy wants to run a terminal session on the UNIX machine zeus from the local machine venus. To do so, Sandy enters the command: rlogin zeus Because there is no entry in the authentication files for the combination of Sandy s user name Sandy and the local machine name venus, Sandy is prompted for the user name and password associated with Sandy s account on zeus. Sandy s environment on zeus is set up to use the Korn shell as its shell, so Sandy can now enter Korn shell commands as if logged onto the actual machine zeus. When Sandy exits the Korn shell with the exit command, control is returned to the local machine venus. Specifying a User Name When the account to which you want to connect on the remote machine has a user name that differs from the current user name on the local machine, you can specify the remote user name on the command line. There are two ways to do this: rlogin host -l username rlogin username@host where host is the name of the remote machine and username is the user name associated with the account on host to which you want to connect. Authentication is performed on the specified username rather than the local user name. If no entries for username exist in the appropriate authentication files, you are prompted for a user name and password. For example, Dale is logged into the local machine mars as Dale and wants to connect to the UNIX machine zeus. Dale s account on UNIX has the user name djdowns, so either of the following commands can connect Dale to the djdowns account on zeus: rlogin zeus -l djdowns rlogin djdowns@zeus Connectivity Solutions Guide 19

28 Remote Utilities Because an authentication entry exists for djdowns, Dale is immediately connected to a C Shell session (C Shell is the default shell specified by the SHELL environment variable in Dale s environment on zeus). Dale can now enter C Shell commands as if logged onto the actual machine zeus. When Dale exits the C Shell, control is returned to the local machine mars. Remote Services The MKS Toolkit Connectivity Suite contains three services (rshd, rexecd, and rlogind) that can be run on a Windows NT/2000/XP system to allow remote utilities to connect to that system and run scripts, programs, and utilities as though the user was working directly on the system. These services are designed to allow any standard version of the remote utilities to connect to them. This includes the remote utilities provided in the MKS Toolkit Connectivity Suite and those that are common on legacy systems such as UNIX and Linux. Starting and Stopping the Services For more information on the rshd, rexecd, and rlogind services as well as the service utility, see the rshd, rexecd, rlogind, and service reference pages in the online MKS Toolkit Utilities Reference. The rshd service provides remote execution facilities for the rsh and rcp utilities. The rshd service must be running on a remote machine before rsh or rcp can connect to it. Similarly, the rexecd service provides remote execution facilities for the rexec utility. The rexecd service must be running on a machine before rexec can connect to it. Finally, the rlogind service provides the ability for users to log in to a machine remotely using the rlogin utility. Before a remote utility can connect to a remote service, the remote service must be installed and started. Installing a service means that the service is placed in the list of active services whose status is continually monitored. The command: rshd -install installs and starts the rshd service on the current machine, while: and rexecd -install rlogind -install do the same for the rexecd and rlogind services. For example, entering the commands: rshd -install rexecd -install rlogind -install 20 MKS Toolkit

29 Remote Services on the Windows machine jupiter in the sample network enables users to connect to jupiter with the rsh, rcp, rexec, and rlogin utilities. Similarly, the -remove option to rshd, rexecd, and rlogind stops the service and removes it from the list of the active services. Note The -remove option to rshd, rexecd, and rlogind does not delete the actual program itself (that is, rshd.exe, rexecd.exe, or rlogind.exe) from the machine. It simply removes the service from the list of installed services. The actual program is still there and you can reinstall and restart the service with the -install option. To stop a service without removing it, use: service stop rshd service stop rexecd service stop rlogind You can restart a stopped service (that is, if it has not also been removed) with: service start rshd service start rexecd service start rlogind Note You can also start and stop the remote services from the Manage Services tab of the MKS Toolkit control panel applet. Authentication For details on configuring the rshd service, see Configuring the Remote Utilities on page 51. When you use rsh, rcp, or rexec, or rlogin to execute a specified command on a remote machine running the appropriate MKS Toolkit service, that service must first authenticate that you have permission to do so. rshd Authentication When you issue a rsh or rcp command, four pieces of information are sent to the rshd service on the remote machine: The remote command. This is the command to be executed on the remote machine. The remote user name (remuser). This is your current user name on the local machine. It is called the remote user name, because from the rshd service s point of view, your local machine is remote. Connectivity Solutions Guide 21

30 Remote Utilities For more information on the hosts.equiv and.rhosts files, see Authentication Files on page 59. For details on configuring the rexecd service, see Configuring the Remote Utilities on page 51. For details on the.netrc file, see Authentication Files on page 59. The local user name (locuser). This is the user name to use on the remote machine. It is called the local user name, because from the rshd service s point of view, the remote machine is actually local. This is the user name specified on the rsh or rcp command line, or if no user name was specified on the command line, this is the same as remuser. The name of your local machine. First, rshd checks the LSA database on its machine for an entry matching locuser. If a matching entry is not found, rshd aborts the connection and does not execute the remote command. If a matching entry is found, the entry gives the password associated with locuser. The rshd service then attempts to validate locuser as though you had logged directly into the remote machine using locuser as your user name and the retrieved password as your password. If this validation fails, rshd aborts the connection and does not execute the remote command. Next, rshd checks to see if you have permission to run the remote command when connected as remuser from your local machine. To do so, rshd looks in two files (hosts.equiv in the $ROOTDIR/etc directory and.rhosts in the home directory of locuser) for an entry that matches remuser and the name of your local machine. If neither file exists or contains a matching entry, rshd aborts the connection and does not execute the remote command. Now that rshd has determined that you have permission to run the remote command, it must determine how to run it. To do so, rshd loads the profile associated with locuser and checks to see if the environment variables SHELL, shell, COMSPEC, or ComSpec are set. rshd checks the variables in the order listed and the value of the first one found to be set is used as the shell or command interpreter to execute the remote command. If none of these variables are set, rshd uses cmd.exe to execute the remote command. Finally, the rshd service uses the shell or command interpreter determined in the previous step to execute the remote command in locuser s home directory using the environment set by locuser s profile. rexecd Authentication When you issue a rexec command, a user name, password and the remote command to be executed are sent to the rexecd service running on the remote machine. The user name and password sent are the ones specified on the rexec command line (or in the case of password, provided in answer to a prompt). If no user name was specified, the.netrc file in your home directory is 22 MKS Toolkit

31 Remote Services searched for a user name and password to be used when connecting to the remote machine. If no user name is specified on the command line or found in the.netrc file, your current user name is sent. First, the rexecd service attempts to validate the user name as though you had logged directly into the remote machine using that user name and the password sent. If this validation fails, rexecd aborts the connection and does not execute the remote command. Next, rexecd loads the profile associated with the user name and checks to see if the environment variables SHELL, shell, COMSPEC, or ComSpec are set. rexecd checks the variables in the order listed and the value of the first one found to be set is used as the shell or command interpreter to execute the remote command. If none of these variables are set, rexecd uses cmd.exe to execute the remote command. Finally, the rexecd service uses the shell or command interpreter determined in the previous step to execute the remote command in the home directory associated with the user name using the environment set by the user name s profile. For details on configuring the rlogind service, see Configuring the Remote Utilities on page 51. rlogind Authentication When you issue a rlogin command, three pieces of information are sent to the rlogind service on the remote machine: The remote user name (remuser). This is your current user name on the local machine. It is called the remote user name, because from the rlogind service s point of view, your local machine is remote. The local user name (locuser). This is the user name to use on the remote machine. It is called the local user name, because from the rlogind service s point of view, the remote machine is actually local. This is the user name specified on the rlogin command line, or if no user name was specified on the command line, this is the same as remuser. The name of your local machine. If an entry for local machine exists in both $ROOTDIR/etc/hosts and $ROOTDIR/etc/hosts.equiv, you are not prompted for a password. If there is no corresponding entry for your local machine in $ROOTDIR/ etc/hosts, you are prompted for a password, regardless of whether or not an entry for your local machine is present in $ROOTDIR/etc/ hosts.equiv. rlogind then loads your profile (based on locuser) and runs the command shell specified in the MKS Toolkit control panel applet. Connectivity Solutions Guide 23

32 Remote Utilities 24 MKS Toolkit

33 Secure Utilities 4 For more information on the individual components, see the appropriate reference pages in the MKS Toolkit Utilities Reference. The secure utilities provided in the MKS Toolkit Connectivity Suite are a set of tools that allow for secure communications between different machines. This suite is a port of OpenSSH and OpenSSL, and, hence, should be completely compatible with UNIX/Linux systems that are running these tools. In addition, the secure tools interoperate with other Windows machines that have MKS Toolkit installed. The Connectivity Suite includes the following client and server components: Component Description secsh secshd secsh-add secsh-agent secsh-keygen secsh-keyscan scp sftp sftp-server Visual SFTP secure shell client secure shell service (daemon) add RSA/DSA identities for the authentication agent authentication agent generate, manage, and convert authentication keys gather secure shell public keys secure remote file copy secure file transfer program server subsystem for sftp Windows Explorer extension to The server components (secshd and sftp-server) are supported only on Windows NT/2000/XP systems. The client components (secsh, secshadd, secsh-agent, secsh-keygen, secsh-keyscan, sftp, scp, and Visual SFTP) are supported on Windows NT/2000/XP and Windows Me systems. Connectivity Solutions Guide 25

34 Secure Utilities There are many nuances to the proper use of the Secure Shell protocol, and if you are truly concerned with security, you should familiarize yourself with all of the issues involved. This document points out some of the more obvious issues. It also points out those issues that are specific to the MKS Toolkit secure utilities. Secure Shell Client For more information on the secure shell client, see the secsh reference page in the online MKS Toolkit Utilities Reference. The most basic form of communication is with the secure shell itself. This is invoked with the command: secsh hostname When you are using the MKS Toolkit secure shell client (secsh) on a Windows NT/2000/XP machine, the default user name is of the form domain_name\username. If you are connecting to the secure shell server on another Windows system, this may be exactly what you desire. However, if you are connecting to a UNIX system, you must specify the UNIX user name with the -l option: secsh -l user hostname where user is your user name on the UNIX system. client provided with MKS Toolkit: Caution Using the secure shell client in a command window where the screen buffer width is larger than the window (that is, the command window has a horizontal scrollbar) does not work well. You should only use the secure shell client from command windows where these two widths are the same. For details on configuring the secure utilities from the MKS Toolkit control panel applet, see From the Control Panel Applet on page 63. One of the configuration options for the secure shell client that can be specified is the user name to be used when connecting. You can either create a separate host profile for each host that you wish to connect to, or you may instead create a host profile with a pattern of * to match all hosts. 26 MKS Toolkit

35 Secure X11 Secure X11 For details on configuring the secure utilities from the MKS Toolkit control panel applet, see From the Control Panel Applet on page 63. The MKS Toolkit secure utilities offer the option of creating a secure X11 connection as well as the normal shell window. For this to succeed, the server side must be configured to allow this. If you are using the MKS Toolkit secure shell service (secshd), you can enable this option from the MKS Toolkit control applet. You may also need to enable secure X11 for the secure shell client. If you are using the MKS Toolkit secure shell client (secsh), you can use the MKS Toolkit control panel applet to turn this on by default. Note Even if secure X11 is not enabled for the host that you want to connect to, it is possible to forcibly enable the setting from the secsh command line with the -X option. When you connect to a remote machine, the DISPLAY environment variable is automatically set to a special value. This value is usually something like :10.0. You should not attempt to change this value to point to your client machine. The X connection is automatically tunneled through the secure connection and the secure shell client opens the connection to the X server on your client machine. You must have an X server (such as the XVision X Server that comes with MKS Toolkit for Interoperability and MKS Toolkit for Enterprise Developers) running on your client machine for secure X11 to work. Secure Shell Service For details on configuring the secure utilities from the MKS Toolkit control panel applet, see From the Control Panel Applet on page 63. The MKS Toolkit secure shell service (secshd) runs as a Windows NT/ 2000/XP service. The installer automatically registers this with the system and starts it. You can configure this service from the MKS Toolkit control panel applet. Note The location of the home directory (~/) is somewhat ambiguous and depends upon whether you have actually logged into the server machine itself. If you have logged in, the ~/ directory is your normal HOME directory. If you have not logged in, however, the ~/ directory appears in your user profile directory. Connectivity Solutions Guide 27

36 Secure Utilities Authentication Agents For more information on the secsh-agent authentication agent, see the secsh-agent reference page in the online MKS Toolkit Utilities Reference. For details on public and private keys, see Authentication Keypairs on page 75. For details on passwordless authentication, see Passwordless Authentication on page 78 There are situations where you may need your private key to follow you through as you make connections. For example, if you need to first open up a secure shell connection to a firewall machine, and from there open up a second secure shell to a machine inside the firewall. To use passwordless authentication to connect to the innermost machine, the firewall machine must somehow validate that the public key of the innermost machine matches your private key; however, uploading your private key to the firewall compromises your keys. Alternatively, you might need to use scp or sftp on a public server, and want to use a passwordless form of authentication, but don t want to upload your private key to the public server as this would compromise it. With the authentication agent, you can do all of this, and your private key never leaves your client machine. The authentication agent is essentially used to create another secure channel (similar to that used for secure X11 connections) over which authentication requests can be made. To get started, you need to first launch the agent on your client machine where your private keys are stored. You can do this with a command such as: secsh-agent sh.exe This starts the agent, and the agent launches a shell which prompts you for input. Initially the keyring for the agent is empty, meaning that it has no keypairs on the keyring. Next, you must load the keypairs onto the keyring. Here is an example that demonstrates how to do this: $ secsh-agent sh.exe $ secsh-add ~/.ssh/id_dsa Identity added: Z:\user1/.ssh/id_dsa (Z:\user1/.ssh/ id_dsa) $ secsh-add ~/.ssh/id_rsa Identity added: Z:\user1/.ssh/id_rsa (Z:\user1/.ssh/id_rsa) $ secsh-add ~/.ssh/identity Identity added: Z:\user1/.ssh/identity (OURDOMAIN\User1) 28 MKS Toolkit

37 Secure FTP For details on the secsh-add utility, see the secsh-add reference page in the online MKS Toolkit Utilities Reference. For details on configuring the secure utilities from the MKS Toolkit control panel applet, see From the Control Panel Applet on page 63. You may also use the secsh-add utility to enumerate the keys that are currently on the keyring. $ secsh-add -l 1024 e9:17:08:ee:3e:2a:29:2b:67:2d:a8:64:46:a3:6a:07 OURDOMAIN\User1 (RSA1) :69:23:b9:1e:7a:5a:5c:b5:98:ab:fe:cc:c0:72:e8 Z:\user1/.ssh/id_dsa (DSA) d:2f:35:28:e2:c4:d3:01:ed:ca:37:24:9f:3f:59:82 Z:\user1/.ssh/id_rsa (RSA) Once you have done this, you can connect to another host with the secure shell client, and an authentication channel is created to the remote secure shell service. On the remote end, you can once again use secsh-add -l to display the keys on the keyring, and you should once again see the keys listed. The secure shell client can be configured as to whether the authentication agent connection is forwarded or not. The MKS Toolkit control panel applet can be used to configure the settings for specific hosts. Note Even if the channel to the authentication agent is not enabled for the host to which you want to connect, it is possible to override the setting from the command line with the -a option. The authentication agent only works when connecting to secure shell servers that are based upon OpenSSH. The agent does not work when using the secsh client to connect to ssh.com-based servers. Secure FTP For more information on secure ftp, see the sftp and sftpserver reference pages in the online MKS Toolkit Utilities Reference. The secure ftp client is an ftp-like application that provides file transfer capabilities. Using the secure ftp client is generally fairly easy. Typically you launch it with a command line: sftp host or sftp user@host Connectivity Solutions Guide 29

38 Secure Utilities For more information on connecting to UNIX system from a Windows NT/2000/XP client, see Secure Shell Client on page 26. Changing the Current Directory Listing Directory Contents Transferring Files When connecting to a UNIX system from a Windows NT/2000/XP client, you may need to override the user name as the default may be of the domain_name\username form. sftp enters into an ftp-like interactive command mode. Typing help lists the available commands. When you first open a sftp connection, all commands are executed in the current directory on your local machine and in your login directory on the remote machine. It is often useful, however, to be able to change directories on one end or the other when you are setting up a file transfer. The cd command changes the current directory on the remote machine. This command is similar to the MKS Toolkit utility of the same name. For example, to go to the subdirectory named mks, type: sftp> cd mks And to go up to the parent of the current directory, type: sftp> cd.. The lcd command change the directory on the local machine. The lcd command is similar to cd, but it acts on the local machine instead of the remote host. To see what files are in your current directory on the remote machine, use the ls or directory command. Generally, the ls command gives a short directory listing, and the dir command gives a more detailed listing. If you type: sftp> ls the server on the remote machine creates a list of files and ships it back to be displayed on your screen. To list files in your local machine directory, type: sftp>! ls The exclamation point (!) is not an sftp command, but rather an escape that executes the ls command on your local machine. The put command is used to send a file from the local machine to the remote computer. For example: sftp> put localfile 30 MKS Toolkit

39 Visual SFTP copies the file named localfile on the local machine to a file of the same name on the remote machine. If you need to use a different name on the remote machine because of special naming conventions, add a second file name to the command line: sftp> put localfile remotefile The get command is used to copy a file from the remote machine to the local computer. For example: sftp> get remotefile copies the file named remotefile on the remote machine to a file of the same name on the local machine. As with the put command, you can add a second file name to the command line to assign a different name for the target file. Note The MKS Toolkit version of the sftp utility does not have a text file transfer mode. All files are transferred in binary mode. Also, the MKS Toolkit sftp utility does not support wildcards in file names. Thus, ls *.tar does not succeed, unless, for some unusual reason, you have actually created a file named *.tar. Visual SFTP While no initial configuration is required, you may find your experience to be richer by first reading Configuring the Secure Utilities on page 63. Visual SFTP is a tool to integrate Secure FTP connections with Windows Explorer. Automatically registered with the system during installation, this Explorer Namespace Extension lets you access and manage files on hosts with Secure FTP servers. You can find the SFTP Connection manager in the MKS Toolkit Start menu, or under My Network Places. Alternatively, you can open an Internet Explorer or Explorer window and type sftp://user@hostname/path in the address bar (or even perhaps wstart sftp://user@host/home/user/ from the command line). All connections to hosts are integrated with the MKS Secure utilities and are configured using the MKS Toolkit control panel applet. No initial configuration is required. Connectivity Solutions Guide 31

40 Secure Utilities Making a Connection From My Network Places or the Secure FTP Connections window you can connect to an SFTP server by right clicking and choosing Add Host from the context menu. Input the name of the server (or a pseudo server name as set up in the Secure Shell Client configuration) or a string formatted as user@hostname. If you have not configured this host as a passwordless connection, a dialog appears prompting for a password. Once the password has been entered (or immediately for passwordless authentication), a file system directory appears, listing files and directories found in the specified server directory. If you have never connected to this server, you may see prompts about host signatures as you would see from the secsh or sftp command line utilities. Changing Directories To change directories, click on the folders on the left pane, double click on the folders in right pane, or simply type a new name in the address bar. You can change the way you view the folders by selecting view from the context menu. This shows you the file and folder properties for everything in the directory. 32 MKS Toolkit

41 Secure Copy You can view the properties of a file or folder by right clicking and choosing properties just as you would with any other explorer window. Copying Files Renaming Files Running Files To copy files between your computer and other systems, simply bring up an explorer window with the files you want to copy. Use Copy and Paste like you do for Windows explorer. You can drag a file from an explorer window to your SFTP window. You may not copy or paste to or from UNIX special files such as sockets, devices or FIFOS although you may rename and view their properties. To rename a file over a Visual SFTP connection, simply right click on the file name and select Rename from the context menu just like you would for any other file using Windows Explorer. You cannot use Visual SFTP to run files on the server to which you are connected. You can, however, run a file from a SFTP server on your local system. To do, so, double-click on the file to be run. This downloads the file and runs it on the local system. Secure Copy For more information on secure copy, see the scp reference page in the online MKS Toolkit Utilities Reference. The secure copy client (scp) is a simplified file transfer utility. When used with passwordless authentication, it is almost a direct cp replacement. Typical usage is something like: or scp foo.bar [email protected]:/home/user3/foo3.bar scp foo.bar host.myisp.com:/home/user3/foo3.bar Note The MKS Toolkit version of secure copy only works when connecting to a machine that is running an OpenSSH derived secure shell service. The ssh.com version of the scp command is instead based upon the sftp protocol. When using machines running the ssh.com version of the service, the sftp client is your only file transfer option. Additionally, like the MKS Toolkit sftp utility, the secure copy client does not handle wildcards. You must copy multiple files individually. Connectivity Solutions Guide 33

42 Secure Utilities Advanced Options For more information on xterm, see The X Terminal Emulator on page 39 and the xterm reference page in the MKS Toolkit Utilities Reference. There are many options to the secure tools, and they can be used in a number of ways. A few examples are provided to give an idea of the sorts of options that you have open to you. For example, you might want to have an icon on your Windows desktop which opens up an xterm on a remote machine. Such a shortcut can be created with the command: shortcut -f %ROOTDIR%\bin\secsh.exe \ -a "-f -X myhost xterm" -D rexterm.lnk This shortcut tells the secure shell client to go into the background (after password authentication, if required), to make sure that the secure X11 channel is created, and then on the remote end launch an xterm to be displayed on your client machine. A more sophisticated example might have the shortcut run the authentication agent and specify a shell script to be run. The shell script in turn might load keys onto the keyring, and then in turn launch the xterm on the remote host. 34 MKS Toolkit

43 The Telnet Server 5 For information on configuring the MKS Toolkit telnetd server, see Configuring the Telnet Server on page 83. Telnet is a utility program that enables you to connect to other computers over the Internet. Specifically, telnet lets you log in and set up an interactive session with a remote computer almost as if you were on a local terminal; the network between you and the remote system is normally invisible. The telnet utility is a terminal emulation program only; it has no file transfer capabilities like the rcp, scp, and sftp utilities that were discussed previously. For telnet to be able to connect to a remote machine, that machine must be running a telnet daemon. telnet daemons are an integral part of most legacy operating systems. The MKS telnetd service brings that level of interactive command line access to the Windows environment. The telnetd command is a Windows NT/2000/XP service that supports the DARPA standard TELNET virtual terminal protocol. Once started, it allows users with compatible telnet client software to create an interactive session with that Windows machine. Initializing the MKS Telnetd Service The MKS Toolkit telnetd service, once installed, is set to autostart each time the system is booted. You can manually start and stop the service using the MKS Toolkit service command: service stop MKSTelnetd service start MKSTelnetd To see what state the service is currently in use the query keyword to the service command: service query MKSTelnetd The resulting display looks similar to the following: Connectivity Solutions Guide 35

44 The Telnet Server [E:/] service query MKSTelnetd Name: MKS Telnetd Service Type: WIN32_OWN_PROCESS Current State: RUNNING Controls Accepted: ACCEPT_STOP Check Point: 0 Wait Hint: 0 Start Type: AUTO_START Error Control: IGNORE Path: E:\WINNT\System32\telnetd.exe Dependency: NuTCRACKERService Dependency: LanmanServer Dependency: LanmanWorkstation Service Start Name: LocalSystem Initiating a Telnet Session Please refer to the associated documentation for instructions on how to initiate a telnet connection using that software. There are two ways to begin a telnet session. The usual method is to type telnet followed by the name of the system you wish to reach from a command shell. For example: telnet hostname.domain.com Alternatively, you can open a telnet session from the MKS Toolkit Start Menu by selecting Remote Connectivity > Windows Telnet Connection. A command window is displayed and you can then type an open command to access a specific host: Microsoft Telnet> open hostname.domain.com The effect is the same as if you had initiated the telnet session from the command line. The shortcut within the MKS Toolkit program group is provided for convenience and the Microsoft Telnet client can also be run from the Start > Run dialog. You may also use a third party telnet client to connect to the MKS Toolkit telnetd service. Assuming that it conforms to the industry standards you should have no problems connecting to the MKS telnetd service. 36 MKS Toolkit

45 The X Terminal Emulator 6 For more information about xterm, see the xterm reference page in the online MKS Toolkit Utilities Reference, the xterm chapter in the X Window System User s Guide Volume 3, published by O Reilly & Associates, and Thomas Dickey s xterm home page at dickey.his.com/xterm/ xterm.html. For more information about telnet, rlogin, and secsh, see The Telnet Server on page 35. Remote Login on page 18, and Secure Shell Client on page 26 as well as the appropriate reference pages in the online MKS Toolkit Utilities Reference. For more information on using xterm with the secure shell, see Secure X11 on page 27. The xterm utility is an industry standard terminal emulator that is available on nearly every UNIX system shipped today. The MKS Toolkit Connectivity Suite provides a version of this utility for Windows NT/2000/XP systems. On UNIX systems, xterm has two main uses: providing a shell window on the current machine and providing a remote login window on a remote on a remote machine. On Windows, there are many ways to get a shell window and it is certainly not necessary to use xterm, unless that is how you are accustomed to working. If all you need is a shell window, select one of the shell shortcuts from the MKS Toolkit Start menu (either C Shell or KornShell). The xterm utility, however, is well suited to working in a networked environment where you need access to remote machines, especially if you are working in a mixed environment of UNIX and Windows machines. While there are other options for working remotely in this manner, such as Windows Terminal Server, telnet, rlogin, and secure shell (secsh), xterm offers several advantages: xterm requires no additional licenses, such as are needed for Windows Terminal Server. xterm provides display and editing features not found in other solutions, such as excellent control over fonts and colors, dynamic window resizing, and seamless cut-and-paste. xterm uses the very lightweight X protocol. Explicitly designed for remote access, the use of this protocol makes xterm an ideal choice when working over a slow connection. For a more secure connection, you can tunnel xterm through the secure shell. Like all X clients, xterm requires an X server to be running on the local machine to display and manage its windows. Despite the name, an X server runs locally on what would be the client or desktop machine in a client- Connectivity Solutions Guide 37

46 The X Terminal Emulator server model. MKS Toolkit for Interoperability and MKS Toolkit for Enterprise Developers contain X servers. In addition, there are other thirdparty servers on the market. Using xterm For details on using the secure shell to create an encrypted connection for xterm, see Secure X11 on page 27. Before using xterm, make sure that your X server is running. If you are using the XVision server supplied with MKS Toolkit for Interoperability or MKS Toolkit for Enterprise Developers, you can start it from Start > Programs > Vision > Vision Server. If you are using another server, follow the instructions that came with it. The DISPLAY environment variable must also be set correctly. This variable tells X applications, like xterm, which X server to connect to. If you are using xterm with secure shell to establish an encrypted connection, follow the instructions in Chapter 4: Secure Utilities. In other cases, DISPLAY should usually be set to local_machine:0.0, where local_machine is the name of your local system. For example, Sandy wants to connect to the remote UNIX machine zeus from the local machine venus. Before launching xterm, Sandy should make sure that the DISPLAY environment is set to venus:0.0. In some networks, you many need to specify a fully-qualified domain name (for example, venus.myth.net:0.0) or IP address (for example, :0.0) to identify your local machine. Note For best results in using the MKS Toolkit version of xterm, leave your TERM environment variable set to ansi or nutc. You can launch xterm on your local machine from Start menu with Start > Programs > MKS Toolkit > Xterm, or from a shell window with : xterm & 38 MKS Toolkit

47 Using xterm For more information on the rlogin utility, see the rlogin reference page in the online MKS Toolkit Utility Reference. To launch xterm connected to a remote machine, combine xterm with rlogin: xterm -e rlogin remote_host & Note For this example to work, an rlogind service (or daemon) must be running on remote_host. MKS Toolkit does not currently include an rlogind service. Most UNIX systems include an rlogind daemon. Connectivity Solutions Guide 39

48 The X Terminal Emulator 40 MKS Toolkit

49 Tasks 7 This chapter describes the sample network referred to throughout this document, advice on choosing the right connectivity tool for the job, and a selection of tasks that show how you can use the MKS Toolkit Connectivity Suite in combination with other MKS Toolkit and Windows utilities to create connectivity-based solutions. A Sample Network Throughout this document, the examples have referred to the same users working on the same sample network. The following tables show the machines in this network and the users with accounts on each machine: Machine: zeus Operating System: UNIX Services Running: rshd, rexecd User Dale Sandy Robin User Name djdowns Sandy Robin Machine: jupiter Operating System: Windows XP Pro Services Running: rshd, rexecd User Dale Sandy Guest User Name Dale Sandy USERS\Guest Connectivity Solutions Guide 41

50 Tasks Machine: venus Operating System: Windows 98 Services Running: none User Sandy Robin User Name Sandy USERS\Robin Machine: mars Operating System: Windows Me Services Running: none User Dale User Name Dale Machine: vulcan Operating System: Windows 2000 Services Running: rshd, rexecd User Build Account User Name bldr Note Like many networks, this sample network uses a theme in its machine names. In this one, all machines are named after mythological gods; UNIX machines are named for Greek gods and Windows machines are named for Roman gods. Choosing a Connectivity Tool Choosing the right connectivity tool for you is not a difficult task, you simply have to understand the nature of the job you need to perform on, and some details about, that remote system. To get started, ask yourself the following questions: 42 MKS Toolkit

51 Choosing a Connectivity Tool For full details on any of the utilities mentioned in this section, see the appropriate reference page in the online MKS Toolkit Utilities Reference. For more information on the secsh utility, see Secure Shell Client on page 26 For more information on the telnet server, see The Telnet Server on page 35. For more information on rlogin, see Remote Login on page 18. For more information on the rexec utility, see Remote Execution on page 12. For more information on rsh, see Remote Shell on page 9. For more information on system backups, see the MKS Toolkit Backup Solutions Guide. For more information on the rcp utility, see Remote File Copying on page 15. For more information on the scp utility, see Visual SFTP on page 31. For more information on the sftp utility, see Secure FTP on page Do you require a secure connection or are both the local and remote systems contained within a secure environment? If you require a secure connection, you should use the tools discussed in Chapter 4: Secure Utilities which provide either a secure command line environment or secure X11 tunneling for graphical connectivity. If a secure connection is not a necessity, any of the tools discussed in this document should serve your connectivity needs. 2. Do you require access to graphical X-based applications on the remote system? You need to use an X server to display graphical UNIX, Linux, or MKS Toolkit for Enterprise Developer ported Windows applications on your local machine. An X server is included with every installation of MKS Toolkit for Interoperability or MKS Toolkit for Enterprise Developers. If you already have an X server on your machine, you can use the secure X11 feature of the secsh utility to encrypt that communication should you be working in an insecure environment. 3. Do you require an interactive environment on the remote system? If you need to interact with the remote system rather then simply launch a command or script, you need to use a tool that provides you with this type of interactive environment. The MKS Toolkit Connectivity Suite offers tools such as a telnet service which works with any standard telnet utility, rlogin, and secsh; all of which give you an interactive shell environment on the remote system. If you simply need to launch a program or script on the remote system, rexec, rsh, or providing a command string to secsh can easily handle this task. These tools can be invaluable when automating processes, such as software builds, application testing, or system backups where strict interaction is neither needed nor desired. 4. Do you need to copy files to, from, or between remote systems? The MKS Toolkit Connectivity Suite contains rcp, scp, and sftp for moving files and data between systems. They can easily be integrated into software deployment, application testing, and system initialization and administration processes to further automate jobs and increase productivity. Connectivity Solutions Guide 43

52 Tasks Administering Remote Servers and Workstations For more information on the userinfo and member utilities, see the userinfo and member reference pages in the online MKS Toolkit Utilities Reference. See the MKS Web site ( for more details on these and other such solutions as well as a complete list of Windows specific commands and utilities that help ease the administrative burden of these environments. Administering a network server/router or remote workstation without needing it to have its own screen/keyboard, or without needing to go near it to do so can dramatically increase the productivity of your IT staff. Consider a small adjustment (like adding a new user perhaps) needs to be made and it would take longer to reach the server's location than to telnet your way in, do the job and log out again. When the systems are located at opposite ends of a large building, or in multiple locations throughout the country or the world, it is obvious how this ability can save time. Let s take a look at the example mentioned above, adding a user to a remote server, using the MKS Toolkit Connectivity Suite and other tools and utilities. Using an interactive connection: 1. Log on to the remote machine with one of the following commands: rlogin zeus l djdowns telnet zeus secsh l djdowns zeus 2. Use the MKS Toolkit utilities userinfo and member to add a new user to the machine: userinfo a jdoe member u jdoe a Accounting Using a non-interactive connection: 1. Invoke the command on the remote machine: rexec zeus l djdowns "userinfo a jdoe; \ member u jdoe a Accounting" There are many such simple administrative tasks that can easily be done from the command line either on local or remote systems. Add users and groups. Control services. Perform complex file searches. Copy permissions. Perform system backups. Move data and files between machines. Clone a system file tree or document tree. 44 MKS Toolkit

53 Deploying Applications Throughout the Enterprise Copy a standard user set-up to a new user account. Use automated scripts to: Improve manageability of Windows in large installations by populating and managing registry entries en masse. Administer user accounts in batch (for example, after a reorganization or a merger), instead of one-by-one. Perform repetitive tasks on large numbers of machines. Manage Windows environments with standardized tools and scripts that also work in legacy environments. Deploying Applications Throughout the Enterprise With the speed at which applications are being updated, the task of installing new versions on each desktop within your organization can quickly become overwhelming. Automating these deployments would greatly increase the productivity of your IT staff but how can it be done? The MKS Toolkit Connectivity Suite can help address the problems with application deployment and free your staff to concentrate on the real issues facing IT. For example, in order to deploy an application to a number of desktops throughout your organization, you could follow these steps: Note These instructions assume that MKS Toolkit is installed on your target machines. They could be trivially modified to operate without this assumption and used to deploy the MKS Toolkit product or other applications. MKS Toolkit must be installed on your local system in order to use the commands listed. 1. Copy the installation image to a known location. For example, here the install source is located on the local CD drive (D:) and we want to put it in the install directory on the network machine zeus: rcp r /D=/*.* zeus:/install 2. Compile a list of target machine names to which you want to deploy the software and store the names in a text file (for example, targetmachines.txt). Connectivity Solutions Guide 45

54 Tasks For more information on the registry utility, see the registry reference page in the online MKS Toolkit Utilities Reference. For more information on the shutdown utility, see the shutdown reference page in the online MKS Toolkit Utilities Reference. 3. Map the network drive on each of the target machines. For example, here the network machine zeus has a shared directory called install where the image is placed which is mapped to the local drive letter x:. for machine in `cat targetmachines.txt` do rsh $machine "mount o pe //zeus/install x:" done 4. Use the registry command to place the installation setup file in the Windows Registry to run the next time the system is rebooted. for machine in `cat targetmachines.txt` do registry -S $machine -s k \ HKLM/Software/Microsoft/Windows\ /CurrentVersion/RunOnce \ -n "MKS Toolkit Installation -v \ X:\setup.exe done 5. Use the shutdown command to reboot the remote machines. for machine in `cat targetmachines.txt` do shutdown S $machine r done Accessing Remote X11 Applications Suppose you need to run X or Motif applications from UNIX or Linux machines or run Motif applications ported with MKS Toolkit for Enterprise Developers from remote Windows machines. Using the MKS Toolkit Connectivity Suite, you can easily perform this task regardless of the X technology used. 1. Start your X server on your local system. 2. Find out the value of the DISPLAY environment variable associated with your local system by typing the following in a KornShell window: echo $DISPLAY This displays a value in the form :X.0 (for example, :0.0) which you is used later in this procedure. If DISPLAY is not set, using :0.0 should work in this instance. 46 MKS Toolkit

55 Performing Distributed Builds and Automated Testing 3. Use rsh to set DISPLAY accordingly on the remote system and launch the X11 application: rsh zeus l djdowns "export DISPLAY=IP_Addr:X.0; \ X11_Application" where X11_Application is the name of the X11 application that you want to run and IP_Addr is IP address or machine name of the workstation where you want the X11 application to be displayed. Note These instructions assume that the remote machine has a KornShell available for the remote connection. Performing Distributed Builds and Automated Testing In today s world of multiple operating systems and remote development teams, the ability to perform distributed builds and automated testing becomes more and more important. A distributed build can involve the execution of separate builds across multiple machines at the same time. It could even involve the compilation and testing of platform-specific components across multiple operating systems. For example, an application may have a Windows client, while the server side components are built on UNIX. Alternatively you could have an application that is available to the market on different operating systems but uses the same source base (that is, those applications ported to Windows with MKS Toolkit for Enterprise Developers). In this case, the application is completely recompiled for differing operating systems. Whatever the case, by integrating the connectivity tools discussed in this document into your build, you can easily streamline the process and distribute the load of compiling and testing large and complex systems. Further, by using standards-based tools, there becomes little difference between the local and remote file and operating systems. Connectivity Solutions Guide 47

56 Tasks 48 MKS Toolkit

57 Configuring the Connectivity Suite A This appendix discusses how to configure the various components of the MKS Toolkit Connectivity Suite. This includes the various settings available from the MKS Toolkit control panel applet, the creation of the files which control authentication for the remote utilities, the creation of keypairs required for authentication with the secure utilities, and other steps necessary for setting up these utilities. Configuring the Remote Utilities You can configure the remote utilities from either the MKS Toolkit control panel applet or from the command line. Additionally, you can use any text editor (such as MKS Toolkit s vi editor) to set up the authentication files used by rexecd and rshd. From the Control Panel Applet To launch the MKS Toolkit control panel applet, select Configuration > Configuration Information from the MKS Toolkit Start menu or from the command line, type: grconfig Three tabs on the MKS Toolkit control panel applet deal with the configuration of the remote utilities: Authentication, Rexecd/Rshd, and Rlogind Service. Backup Solutions Guide 49

58 Configuring the Connectivity Suite For details on the mksauth authentication service, see the mksauth reference page in the online MKS Toolkit Utilities Reference. For information about the MKS Toolkit Scheduling Suite, see the MKS Toolkit Scheduling Solutions Guide available from the Start menu. The Authentication Tab The Authentication tab allows you to set the password associated with your current user name in the LSA database. This is the password by the mksauth authentication service when validating passwords for the rshd service when running commands on this machine and also by the MKS Toolkit Scheduling Suite. If the LSA database contains a password for your current user name, this tab shows in the Rsh Remote Access section, that your access is currently Enabled. It also shows in the Scheduler section, that the ability for the MKS Toolkit Scheduling Suite to run tasks using your current user name is Enabled. The Password section and the Enable button are greyed out. Clicking the Disable button deletes the password in the LSA database and shows the two options described above as Disabled. 50 MKS Toolkit

59 Configuring the Remote Utilities For more information on passwd, mksauth, and rshd, see the appropriate reference pages in the online MKS Toolkit Utilities Reference. Note You should only delete the password in the LSA database if you have changed your password using a method other the MKS Toolkit passwd utility (such as the standard Windows method) or if you used the MKS Toolkit passwd utility when neither the mksauth service nor the rshd service were running. When you change your password with passwd and mksauth or rshd is running, the password in the LSA database is also updated. If the LSA database does not contain a password for your current user name, this tab shows these two options as Disabled and the Disable button is greyed out. To enable both these options, enter the password associated with your current user name on this machine in the Password field and click Enable. The Rexecd/Rshd Tab The Rexecd/Rshd tab allows you to turn on and off features of the rshd and rexecd services. Backup Solutions Guide 51

60 Configuring the Connectivity Suite The two areas of this tab, Rexecd and Rshd, let you turn the following features for the appropriate service on or off by checking or unchecking the check boxes next to them: Allow multiple concurrent connections When this option is checked (as it is by default), the service allows multiple connections to it at the same time. For the rexecd service, this is rexec commands. For the rshd service, this is rsh and rcp commands. When it is unchecked, only a single command can connect to the service. Log all accesses in the system in the system event log When this option is unchecked (as it is by default), the service only logs errors to in the system event log. When it is checked, the service logs all connections in the system event log. Fallback to a domain user if the local user does not exist When this option is unchecked (as it is by default), the service aborts the connection if the local user (that is, the user name to use when running remote commands on this machine) does not exist. When this option is checked and the local user does not exist, the service checks for a domain user with that user name. If one exists, that domain user name is used. If not, the service aborts the connection. 52 MKS Toolkit

61 Configuring the Remote Utilities The Rlogind Service Tab The Rlogind Service tab allows you to configure features of the rlogind service. The following settings can be configured from this tab: Fallback to a domain user if the local user does not exist When this option is unchecked (as it is by default), the service aborts the connection if the local user (that is, the user name to use when running remote commands on this machine) does not exist. When this option is checked and the local user does not exist, the service checks for a domain user with that user name. If one exists, that domain user name is used. If not, the service aborts the connection. Log Level This dropdown list specifies the level of verbosity for logging of events in the application event log. Backup Solutions Guide 53

62 Configuring the Connectivity Suite TCP/IP Port This field specifies the port rlogind uses to listen for connections. The default is port 513. Command Shell This area of the tab specifies the command interpreter to use for rlogin sessions. You can choose $SHELL, cmd.exe, or Other. When $SHELL is chosen, the value of the SHELL environment variable is used as the command interpreter. When cmd.exe is chosen the standard Windows command interpreter (cmd.exe) is used. Finally, when Other is chosen, you can specify the command to run to launch the command interpreter in the Other field while specifying the argument to that command in the Arguments field. By default, $SHELL is chosen. Include/Exclude These are the Include and Exclude lists for the rlogind service. The Include list shows addresses which are explicitly allowed to connect to the service while the Exclude list shows those addresses which are denied access and cannot rlogin into the machine. Each list can show single, multiple, or a range of IP addresses to either include or exclude from the service. From the Command Line For more information about the rconfig utility, see the rconfig reference page in the online MKS Toolkit Utilities Reference. For more information, see Starting and Stopping the Services on page 22 as well as the rshd and rexecd reference pages in the MKS Toolkit Utilities Reference. As mentioned earlier, you can use grconfig to launch the MKS Toolkit control panel applet from the command line. However, you can also directly configure the rshd and rexecd services from the command line with the rconfig and rsetup utilities. The rconfig Utility The basic form of rconfig is: rconfig service operation options where service is the name of the service (either rshd or rexecd), operation is the operation to perform on that service (start, stop, or status), and the options argument indicates the configuration options to either set (with start or stop) or to report the status of (with status). The start operation attempts to install and start the specified service in the same manner as the rshd -install or rexecd -install commands. Note If the service is already installed, rconfig displays a message saying that the service already exists, but it still restarts the service if it was stopped. 54 MKS Toolkit

63 Configuring the Remote Utilities The stop operation stops the specified service in the same manner as the following commands: service stop rshd service stop rexecd The stop operation does not attempt to remove the service. With either the start or stop operation, you can specify any of the following options to turn configuration options on or off: +f The service aborts the connection if the local user (that is, the user name to use when running remote commands on this machine) does not exist. This is the default behavior. -f When the local user does not exist, the service checks for a domain user with that user name. If one exists, that domain user name is used. If not, the service aborts the connection. Note Specifying the +f or -f option is the same as checking or unchecking, respectively, the Fallback to a domain user if the local user does not exist option on the Rshd and Rexecd tabs of the MKS Toolkit control panel applet. +s The service can accept multiple connections at the same time. -s The service can accept only one connection at a time. Note Specifying the +s or -s option is the same as checking or unchecking, respectively, the Allow multiple concurrent connections option on the Rshd and Rexecd tabs of the MKS Toolkit control panel applet. +v The service only logs errors to in the system event log. This is the default behavior. -v The service also logs all connections in the system event log. Note Specifying the +v or -v option is the same as checking or unchecking, respectively, the Log all accesses in the system in the system event log option on the Rshd and Rexecd tabs of the MKS Toolkit control panel applet. With the status operation, you can specify any of the following options to report the current configuration of the service: -f Reports how the service responds when the local user does not exist. If it aborts the connection immediately, -f displays Backup Solutions Guide 55

64 Configuring the Connectivity Suite NoFallbackToDomainUser. If it checks for a domain user with that user name, -f displays FallbackToDomainUser. -r Reports whether or not the service is currently running. When the service is running, -r displays RUNNING. When the service is not running, -r displays STOPPED. -s Reports how many concurrent connections the service can accept. It displays Single when the service accepts only a single connection and Multiple when the service accepts multiple connections. -v displays the status of event logging. If all connections are being logged, -v displays Logging; if only errors are being logged, -v displays NoLogging.] If you specify the status operation without any options, rconfig behaves as if all four of the above options were specify (that is, rconfig service status -frsv). For more information on the rsetup utility, see the rsetup reference page in the MKS Toolkit Utilities Reference. For details on the sample network used in these examples, see A Sample Network on page 43. The rsetup Utility The rsetup manages user name and password entries for the current user in the Windows NT/2000/XP LSA database. These entries are for use by the rshd service running on that machine and one must exist for each user name that is to be used with rsh or rcp requests. You can add, delete, and query entries in the database. When neither the -d (delete) nor -q (query) options are specified, rsetup adds an entry for the current user. The current user name and password is verified when adding and deleting entries. For example, using the sample network, Sandy is logged on the Windows machine jupiter as Sandy. The command: rsetup prompts for Sandy s password on jupiter, validates that it s correct, and creates an entry containing that password in the LSA database. Sandy s account on jupiter can now be used by rsh and rcp commands on remote machines to run commands on jupiter. The command: rsetup -d deletes the LSA database entry for the current user. This is useful if you decide that you no longer want your account to be used remotely or if you need to enter a new password. 56 MKS Toolkit

65 Configuring the Remote Utilities For more information on the passwd utility, see the passwd reference page in the MKS Toolkit Utilities Reference. Note When you change your password with the MKS Toolkit passwd utility and have a valid entry in the LSA database, this entry is automatically updated to contain the new password. If you change your password using standard Windows methods, use rsetup -d to delete your old LSA database entry and then rsetup to create an entry with the new password. The command: rsetup -q queries the LSA database and reports whether or not you have a valid entry in the LSA database. Authentication Files For details on using the vi utility to edit text files, see the vi reference page in the MKS Toolkit Utilities Reference. As mentioned throughout this document, the rshd service in the MKS Toolkit Connectivity Suite uses authentication files to help authenticate who connect to those services to execute commands. The rshd and rlogind services use the hosts.equiv file in the $ROOTDIR/etc directory and the.rhosts file in the home directory on rshd s machine of the user name being used to execute the command. Similarly, rexec itself uses a.netrc file in the home directory (on the machine where the rexec command is issued) of the user issuing the rexec command. This file is used to indicate the user name and password to be used by rexecd when executing commands. All three of these files are plain text files that can be edited using any text editor, such as MKS Toolkit s vi utility or the Windows Notepad application. Caution Because the hosts.equiv,.rhosts, and.netrc files are plain text files that can be easily edited, you should carefully control the permissions on these files. This is particularly important for the.netrc file which contains passwords in plain text. For this reason, the.netrc file should only be readable and writable by the user in whose home directory it resides. For more information on the hosts.equiv file, see the hosts.equiv reference page in the online MKS Toolkit Utilities Reference. The hosts.equiv File The hosts.equiv file resides in the $ROOTDIR/etc directory of the machine running the rshd or rlogind service. It lists which machines and which users on those machines may connect to rshd or rlogind. Each line of this file has the format: machine [username] Backup Solutions Guide 57

66 Configuring the Connectivity Suite For information on creating LSA database entries, see The rsetup Utility on page 56. where machine may be given as a host name (typically, a fully qualified host name in a DNS environment), an IP address, or a + character indicating that all machines have permission to connect to rshd or rlogind, and username, if specified, may be given as either a user name on machine or a + character indicating all users on machine. The users indicated by the $ROOTDIR/etc/hosts.equiv file can connect to rshd and run commands as any user on the machine running rshd. For example, the following entry in the $ROOTDIR/etc/hosts.equiv file on the Windows machine jupiter: venus sandy allows Sandy to connect to jupiter from venus using rsh or rcp and run commands on that machine as any user on that machine (providing that the user has a valid LSA database entry). It also lets Sandy use rlogin to connect to jupiter. Since Dale has an account on jupiter with the user name Dale and has a valid LSA database entry on that machine, Sandy can issue the command: rsh jupiter -l Dale ls to list the contents of Dale s home directory on jupiter. The ls command is run as though Dale had run the command directly on jupiter. An entry in the $ROOTDIR/etc/host.equiv file on jupiter of: venus + lets any user on venus run commands on jupiter using any account with a valid entry in the LSA database, while an entry of: + Sandy would allow any user named Sandy on any machine to do the same, and an entry of: + + gives the same access to any user on any machine. Finally, if a machine name is specified without a user name, any user on the specified machine can use rsh or rcp to run commands (or rlogin to log in) if the user has the same user name on both machines (and, of course, there is an appropriate entry in the LSA database). For example, the entry: venus 58 MKS Toolkit

67 Configuring the Remote Utilities lets both Sandy (with accounts named Sandy on venus and jupiter) and Robin (with accounts named USERS/Robin on both machines) run commands on jupiter from their accounts on venus. Caution Because users listed in this file can run commands on the system as any user with a aid entry in the LSA database, careful thought should be given to what entries appear in the file. Particular care should be given to any entry that uses + to indicate any user name or machine. For more information on the.rhosts file, see the rhosts reference page in the online MKS Toolkit Utilities Reference. The.rhosts File The.rhosts file has the same format as the hosts.equiv file, but it resides in a user s directory. This file determines who can connect to the rshd service on the machine and run commands using that user s accounts or log in with rlogin as that user, provided that the user has a valid entry in the LSA database. For example, using the sample network, the entry: mars dale in the.rhosts file of Sandy s home directory on jupiter means that Dale has permission to connect to jupiter and run commands as Sandy. Similarly, consider the entries: mars + + dale + + Each of these specifies a group of users that has been granted permission to run commands on jupiter as Sandy. The first entry grants this permission to any user on mars; the second grants it to anyone with the user name Dale on any machine; and the third (and most dangerous) grants it to any user on any machine. Finally, there are the entries: venus + The first gives permission for Sandy to run commands from venus when logged in as Sandy on that machine, while the second lets any user logged in as Sandy on any machine run commands on jupiter. Backup Solutions Guide 59

68 Configuring the Connectivity Suite In all of these cases, the commands are run as if Sandy had logged into jupiter directly and issued the commands. Caution While this file offers slightly more security than the $ROOTDIR/ etc/hosts.equiv file because it only grants permission for remote users to run commands as the user in whose home directory it resides, careful thought should be given to what entries appear in the file. Particular care should be given to any entry that uses + to indicate any user name or machine. For more information on the.netrc file, see the netrc reference page in the online MKS Toolkit Utilities Reference. The.netrc File When you issue a rexec command to connect to a remote machine, and don t specify a user name and password, the rexec utility looks for an entry for that machine in the.netrc file in your home directory on the local machine. If a match is found, the matched entry gives the user name and password to send to rexecd on the remote machine. The format of entries in the.netrc file is: machine remote_machine login remote_username password passwd where remote_machine is the name of a remote machine, and remote_username and passwd are the user name and password that are to be used when connecting to the remote machine. For example, Dale s home directory on mars contains a.netrc file with the following entry: machine zeus login djdowns password fdsaqwer7 When Dale issues the following command on mars: rexec zeus ls -l the rexec utility looks in the.netrc file in Dale s home directory and finds the entry for the remote machine zeus containing the user name (djdowns) and password (fdsaqwer7) for Dale s account on zeus. It then sends this user name and password to the rexecd service on zeus, which uses them to execute the ls -l command. Caution As mentioned earlier, this method of storing remote user names and passwords is very insecure. To minimize the risk of other user reading the plain text passwords in the.netrc file, you should limit both the read and write permissions on the file to only the user in whose home directory it resides. 60 MKS Toolkit

69 Configuring the Secure Utilities Configuring the Secure Utilities Configuring the secure utilities provided in the MKS Toolkit Connectivity Suite can involve several separate steps: Configuring secure utilities settings in the MKS Toolkit control panel applet. Setting up keypairs Setting up passwordless authentication The following sections describe each of these steps in detail. From the Control Panel Applet To launch the MKS Toolkit control panel applet, select Configuration > Configuration Information from the MKS Toolkit Start menu or from the command line, type: grconfig Two tabs on the MKS Toolkit control panel applet deal with the configuration of the secure utilities: Secure Shell Client and Secure Shell Service. Backup Solutions Guide 61

70 Configuring the Connectivity Suite The Secure Shell Client Tab The Secure Shell Client tab configures the two host patterns lists used by the secure shell: System host Patterns and User host Patterns. Both of these lists consist of host patterns that are compared to the name of the host to which you are attempting to connect. The patterns are examined in the order listed, and those patterns that match the host name have the associated settings applied. System host Patterns apply to all users using this machine. User host Patterns are specific to each user. You can add a new host pattern by entering the pattern in the New Host Pattern: edit box and clicking the appropriate Add button to add it to either System host Patterns or User host Patterns. You can use the * and? characters as wildcards in the patterns. A single * as a pattern indicates global defaults for all hosts. The host is the host name argument given on the command line (that is, the name is not converted to a canonicalized host name before matching). 62 MKS Toolkit

71 Configuring the Secure Utilities You can change the order of the host patterns in either list by selecting a host pattern and click either the Move Down or Move Up to move the host pattern down or up in the list. Remember that the order listed is the order in which the patterns are examined. To edit the associated settings for a host pattern, select the host pattern and click the Configure button. The Secure Shell Client Host Configuration dialog appears. This dialog has five tabs: Authentication, Identity, Forwarding, Encryption, and TCP/IP. Note You do not need to set all settings associated with each host pattern. Any settings that you leave blank are unchanged. For more information about the options, fields, and buttons on this tab, click the? icon in the upper right corner of the tab then the name of the option or field. The Authentication Tab The Authentication tab features several options dealing with password and passphrase authentication. Backup Solutions Guide 63

72 Configuring the Connectivity Suite For more information about the options, fields, and buttons on this tab, click the? icon in the upper right corner of the tab then the name of the option or field. The Identity Tab The Identity tab lets you specify the files from.which the user's RSA or DSA authentication identity is read (the default is the $HOME/.ssh/identity in the user's home directory). Additionally, any identities represented by the authentication agent are used for authentication. You can also specify to user to log in as in the Username field. This is useful when a different user name is used on different machines and saves the trouble of having to remember to give the user name on the command line. 64 MKS Toolkit

73 Configuring the Secure Utilities For more information about the options, fields, and buttons on this tab, click the? icon in the upper right corner of the tab then the name of the option or field. The Forwarding Tab The Forwarding tab lets you set up TCP/IP ports to be forwarded over the secure channel. Backup Solutions Guide 65

74 Configuring the Connectivity Suite The Encryption Tab The Encryption tab features several options that configure how the secure shell client deals with encryption. This includes the protocols, ciphers, and known host files used by the client. 66 MKS Toolkit

75 Configuring the Secure Utilities For more information about the options, fields, and buttons on this tab, click the? icon in the upper right corner of the tab then the name of the option or field. The TCP/IP Tab The TCP/IP tab features several options that configure how the secure shell client deals with TCP/IP. Backup Solutions Guide 67

76 Configuring the Connectivity Suite For more information about the options, fields, and buttons on this tab, click the? icon in the upper right corner of the tab then the name of the option or field. The Secure Shell Service Tab The Secure Shell Service tab configures the basic features of the secure shell service (secshd) provided in the MKS Toolkit Connectivity Suite. Clicking the Configure Passwordless button displays the Configure Passwordless dialog. Using this dialog, you can manage the keys that are used to determine who is allowed access to this machine. 68 MKS Toolkit

77 Configuring the Secure Utilities For more information about the options, fields, and buttons on this dialog, click the? icon in the upper right corner of the tab then the name of the option or field. Clicking the Advanced button displays the Secure Shell Server Configuration dialog. This dialog has five tabs: Access Control, Encryption, TCP/IP, Authentication, and Login. For more information about the service utility, see the service reference page in the online MKS Toolkit Utilities Reference. Note You can start and stop the secure shell service (secshd) from the Manage Services tab of the MKS Toolkit control panel applet or with the service utility. Backup Solutions Guide 69

78 Configuring the Connectivity Suite For more information about the options, fields, and buttons on this tab, click the? icon in the upper right corner of the tab then the name of the option or field. The Access Control Tab The Access Control tab lets you set up of users and groups who are allowed or denied access to the secure shell server. 70 MKS Toolkit

79 Configuring the Secure Utilities For more information about the options, fields, and buttons on this tab, click the? icon in the upper right corner of the tab then the name of the option or field. The Encryption Tab The Encryption tab features several options that configure how the secure shell server deals with encryption. Backup Solutions Guide 71

80 Configuring the Connectivity Suite For more information about the options, fields, and buttons on this tab, click the? icon in the upper right corner of the tab then the name of the option or field. The TCP/IP Tab The TCP/IP tab sets up the ports and addresses that the secure shell listens on. It is also from this tab that you can enable the use of IPv6 addresses. To do so, add a listening address of ::0. This will let you use IPv6 addresses with all secure utilities. 72 MKS Toolkit

81 Configuring the Secure Utilities For more information about the options, fields, and buttons on this tab, click the? icon in the upper right corner of the tab then the name of the option or field. The Authentication Tab The Authentication tab features various checkbox options that configure how the secure shell service handles authentication. Backup Solutions Guide 73

82 Configuring the Connectivity Suite For more information about the options, fields, and buttons on this tab, click the? icon in the upper right corner of the tab then the name of the option or field. The Login Tab The Login tab features various options that deal with logging into the secure shell service. Authentication Keypairs The underlying technology and some of the following discussion involves the use of public key cryptography and the use of public/private key pairs. Public/private keypairs are primarily used for authentication purposes, and other more efficient encryption algorithms are used for encrypting traffic once authentication is complete. A very crude analogy is that the keypairs are like the two halves of a playing card that was cut in half and used by spies in old movies to authenticate that they have met the correct individual. In this case, however, the keys are mathematical, and it is generally believed that for keys of sufficient length (1024 bits is currently the standard) that reconstructing the private key from the public key is not feasible given the computational technology that exists today. Public and private keys are not interchangeable, however. It cannot be stressed enough that keeping your private keys secure at all times is vital. For this reason, it is generally considered to be a bad idea to store private keys on public servers where other people might examine the 74 MKS Toolkit

83 Configuring the Secure Utilities For more information about smartcards, see SmartCard Support on page 78. For more information on the secsh-keygen utility, see the secsh-keygen reference page in the online MKS Toolkit Utilities Reference. contents (consider that even servers that are believed to be secure might be compromised in some way). On the other hand, the public key can be handed out quite freely, and it is believed that there is no risk in allowing other people to see the public half of your key. Individuals who are especially concerned about keeping their private keys secure should consider using a smartcard for passwordless authentication. If your private key is compromised, you should discard the keypair, generate a new one, and take whatever steps you feel are necessary to keep the new key from being compromised. The secure utilities in the MKS Toolkit Connectivity Suite support several different authentication mechanisms. The simplest involves prompting for a password. Other mechanisms might involve establishing trust relationships such that a user on machine A is considered to be equivalent to that same user name on machine B (a Windows NT/2000/XP domain environment essentially provides this same type of authentication). When you install MKS Toolkit on a Windows NT/2000/XP system, the installer creates keypairs for the machine itself. These keypairs are used in some of the supported authentication schemes where you want to indicate that a user from a specific machine is granted access to your machine. The installer does not however create per-user keypairs, although the tools are present should you want to do this. The assumption here is that you might have previously generated a keypair that you would like to use, or perhaps the machine is only intended to be used as a server, in which case a generated set of user keys is not useful. Generating Keypairs Keypairs are generated with the secsh-keygen utility. It is quite easy to use. The only tricky thing is that there are several different types of keys which can be used. You can generate RSA authentication identities for either version 1 or 2 of the SSH protocol or DSA authentication identities for version 2 of the SSH protocol. Normally, each user runs this utility once to generate their authentication identity. When invoked without any arguments, secsh-keygen generates an identity file, which is the version 1 RSA authentication identity of the user. The command: secsh-keygen -t dsa generates a protocol version 2 DSA authentication identity for the user. Finally, the command: secsh-keygen -t rsa Backup Solutions Guide 75

84 Configuring the Connectivity Suite generates a protocol version 2 RSA authentication identity for the user. You may create any or all of these keypairs for use. It only takes one matching keypair to successfully authenticate. Note however that protocol 1 lacks a strong mechanism for ensuring the integrity of the connection. Some authentication mechanisms only apply to protocol versions 1 or 2. All these keypairs can be protected with a passphrase for extra security. In addition, secsh-keygen offers a default installation directory into which the keys are written. It is possible that this might be on a network share point, and you might want to store the keys locally instead. In this case, you can supply an alternative directory. Note Generating DSA keys can take up to a minute or so. secsh-keygen, by default, creates the private half of the key with permissions such that only you have access. The public half of the key is generated with permissions such that everyone has read access. When generating keypairs for use with the secure utilities in the MKS Toolkit Connectivity Suite, it is important to keep the following factors in mind Typically the home directory (~/) in a Windows domain environment resides on a server, and is not local to the machine. This might not be a desirable location to store private keys from a key management and security point of view. Files on a FAT file system have no security, and thus storing private keys on a FAT file system is a bad idea. The NTFS file system supports full file security, including ACL lists, and thus it is inherently more secure, although anyone with administrative access can generally gain access to any file. Note If you are using the secure utilities on a Windows Me machine such as a laptop, you do not have the option of storing the files on a more secure type of file system. In these instances you must rely upon the physical security of the laptop itself to keep your private key secure. It might also be advisable to use a passphrase in conjunction with private keys stored on a FAT file system. Another alternative is to store your private keys on a floppy disk or better yet a smartcard, in which case you only need to keep the floppy (or smartcard) physically secure. 76 MKS Toolkit

85 Configuring the Secure Utilities Passwordless Authentication For more detailed information about the recommended security settings for the keypair files and the uploaded public keys, please see the relevant reference pages in the MKS Toolkit Utilities Reference. You can also configure the secure utilities to use passwordless authentication. Once you have set up passwordless authentication, you can open secure connections to other machines without having to supply your password. You can set up passwordless authentication by copying your public key to the machine to which you want to connect. Where precisely you copy your key depends upon the specifics of the secure shell service or daemon running on the remote machine. If you are connecting to a secure shell service or daemon that is derived from the OpenSSH version of secure shell (such as the secure shell service (secshd) in the MKS Toolkit Connectivity Suite), the procedure is as follows. You should append protocol version 1 RSA keys to: ~/.ssh/authorized_keys and protocol version 2 RSA and DSA keys to: ~/.ssh/authorized_keys2 Note ~/ is the home directory of the account on the remote machine to which you want to connect. While there is no great security risk in allowing other people to see your public keys, it is essential that your ~/.ssh directory not be writable by anyone other than yourself, and it is good practice that the files within this directory not be readable by anyone other than yourself or an administrator. If you are connecting to a secure shell service or daemon that is derived from the ssh.com version of secure shell, the procedure is somewhat different. The first thing you must be aware of is that the format of the public key files that are used by these secure shell daemons is different than the format that is used by the OpenSSH derived versions. Fortunately secsh-keygen is capable of converting these for you with a command like: secsh-keygen e f ~/.ssh/id_dsa > dsa2.pub In this example, the file dsa2.pub is the file that contains the public key and should be installed on the remote server. Typically this is done by simply copying the file to ~/.ssh2/dsa2.pub the ssh.com versions of the service keep each public key in a separate file. Finally you need to append a single line to the file ~/.ssh2/authorization: Key dsa2.pub Once you have done this, then passwordless authentication should be enabled. Backup Solutions Guide 77

86 Configuring the Connectivity Suite For details on the rsetup utility, see The rsetup Utility on page 56 and the rsetup reference page in the online MKS Toolkit Utilities Reference. The Rsh/Scheduler tab of the MKS Toolkit control panel applet is described on page 50. For details on using the MKS Toolkit control applet to configure the secure shell service, see From the Control Panel Applet on page 61. SmartCard Support Improper security settings for keys may result in secure shell or the secure shell service ignoring the keys. Normally, you receive a warning when this happens. When using passwordless authentication with the secure utilities in the MKS Toolkit Connectivity Suite, keep the following in mind: To enable passwordless access to a Windows NT/2000/XP machine, you must enable your account for rhosts access. You can do this with the rsetup utility or on the Rsh/Scheduler tab of the MKS Toolkit control panel applet. Thee rhosts or rshd service does not need to be running; the only requirement is that you enable your account. If your password expires, the passwordless authentication fails and you are prompted for a password. There have been reported instances where the secure shell service has been compromised to record the passwords used with password authentication. For this reason, it has been suggested that disabling password authentication is inherently more secure. You can configure the secure shell service through the MKS Toolkit control panel applet to disable password authentication. Straight rhosts authentication, while supported by OpenSSH, is not supported by the MKS Toolkit Connectivity Suite. From a security perspective, using rhosts authentication is dangerous, since it is quite easy to use packet sniffers to monitor your activities, or even to impersonate you. The MKS Toolkit secure utilities also feature support for smartcards. But before discussing how to use a smartcard with these utilities, it is important to understand exactly what a smartcard is and what it isn't. A smartcard is a small microprocessor with some memory, and it is usually mounted on a plastic card the same size and shape a credit card. One face of the card has a small number of electrical contacts that serve as the sole means for the smartcard to communicate with the external world. In the PC world, a smartcard reader is also required which acts as an interface between the smartcard and PC. Smartcards are sometimes compared to the magnetic strip on the back of a credit card because both are capable of storing information, but this is not a good analogy for several reasons. First, the entire magnetic stripe can be read by anyone who possesses a reader. This makes it relatively easy for someone to clone the card. Second, it is possible to rewrite or erase the magnetic striped. Finally, the stripe is dumb in the sense that it is incapable of making decisions on it's own. 78 MKS Toolkit

87 Configuring the Secure Utilities On the other hand, a smartcard can, by virtue of the onboard processor, control access to the data on the card and even perform cryptographic calculations such as digitally signing a block of data. Smartcards are beginning to appear much more frequently in other applications. For example, the SIM card in a GSM cellular telephone is a smartcard. Decoder boxes for satellite TV use smartcards. Credit card issuers are starting to use smartcards to provide better security, and as time goes on the list will become even more extensive. Possession of the smartcard by itself is not sufficient for someone to impersonate you. Smartcards typically have a PIN number associated with them that you can configure. For details, see Passwordless Authentication on page 77. Problems with Passwordless Authentication The earlier discussion of passwordless authentication covered the proper usage of both public and private keys and listed several points to keep in mind about proper key management. Remember that anyone who obtains your private key can use it to impersonate you. If you keep your private key on disk, someone might be able to copy the file, especially if it resides on a public server. If the key is stored on the local machine, it is still impossible to guarantee complete safety of the key. And even if you stored the key on a floppy disk and always maintained control over the floppy, you still cannot guarantee complete safety of the key as a malicious user might have made a duplicate copy of the key while you had it inserted in your floppy drive. Smartcard Solutions A smartcard can address these weaknesses in passwordless authentications. To begin with, the private key is written to the smartcard in a manner such that it cannot be read back from the card. The card can, of course, use the key itself for cryptographic calculations, but the card never gives back the key itself. During secure shell passwordless authentication, the remote server uses the public keys for allowed users to digitally sign a block of data. It passes this block of data to the secure shell client, which in turn passes this block of data to the smartcard. The smartcard digitally signs the data with the private key, and the result is passed back to the remote server. The server can compare the blocks of data and verify that the correct private key was used to sign the data, and if this succeeds, the user is allowed access. During this process, the private key never leaves the smartcard. In fact, even if a malicious user or a virus has thoroughly compromised the client machine, your private key can still not be obtained from the smartcard. Backup Solutions Guide 79

88 Configuring the Connectivity Suite Smartcards and Windows With Windows, a smartcard can do much more than just authenticate secure shell. On Windows 2000/XP systems, it is possible to log in simply by inserting a smartcard into the smartcard reader (instead of typing a username and password). It is also possible to use a smartcard to log in when opening a VPN connection, and it is also possible to digitally sign messages with digital certificates stored on a smartcard. Using Smartcards with the Secure Utilities To use smartcards with the MKS Toolkit secure utilities, you need several items. First, you must have a smartcard reader and a PC/SC driver for this reader (typically supplied by the manufacturer of the reader). Next, you need a smartcard and the associated driver (known as a Cryptographic Service Provider, or CSP for short). With Windows 2000/XP, basic smartcard support is included with the system, along with CSPs for some popular smartcards. With Windows Me and Windows NT, basic smartcard support is often bundled with the driver that accompanies the smartcard reader. The CSP itself typically obtained from the smartcard manufacturer. Bundles from Gemplus or Schlumberger may well contain all of the software components that you need. Note Gemplus no longer manufactures the smartcards that are compatible with the CSP that ships with Windows Schlumberger does continue to manufacture smartcards compatible with Windows For more information on plugand-play readers, see windows2000/techinfo/ planning/security/ smartcard.asp. This Web page also enumerates those smartcards which are also plug-and-play on Windows 2000 (meaning that the CSP comes with the system). Smartcard readers for Windows are generally fairly universal in that a card from one manufacturer should work in a reader from any manufacturer. With Windows 2000/XP there are several smartcard readers which are plug-andplay, and for obvious reasons Microsoft recommends their use. Not all smartcards are suitable for use with the MKS Toolkit secure utilities. Some smartcards are designed for use in other applications such as GSM cellular telephones or satellite TV decoders. Others are designed for use with prepaid services (such as prepaid phone cards), and others are designed for use with the next generation of credit cards. The only cards supported for use with the secure utilities are those for which a cryptographic service provider (CSP) is installed on your computer. The smartcard reader and CSP need only be installed on machines where you intend to use the secure shell client. The requirements for machines on which you only run the secure shell service have not changed. 80 MKS Toolkit

89 Configuring the Secure Utilities For more information on the secsh-keygen utility, see the secsh-keygen reference page in the online MKS Toolkit Utilities Reference. Once you have a smartcard reader, CSP, and smartcard, you are ready to begin using them with the MKS Toolkit secure utilities. To create a private key for a smartcard, you do not upload the key from a disk file, but rather you instruct the smartcard itself to generate the keypair. You can then download the public key to a disk file, and from this point forward, the public key is used in the usual way to enable passwordless authentication. To instruct the smartcard to generate a keypair, use a command something like: secsh-keygen -G 0 -t rsa -b f mykey where 0 is the reader number (if you have only one reader, the number will always be 0). After issuing this command, you are prompted for the smartcard s PIN number. The smartcard generates the keypair and the public key generated is stored in the file mykey.pub. Note At this time, only RSA keys are supported with smartcards.this is because the onboard key generating capabilities of most smartcards only support RSA keys. Should you already have a smartcard set up for Windows login, adding a secure shell keypair does not interfere with the ability to log into Windows. However, if you were to have your system administrator rewrite your smartcard with a new certificate, it is likely that your secure shell keypair would be erased at that time. To open a secure shell connection using the smartcard, use the command: secsh -I 0 myhost -l myusername The secsh-agent utility can also use keypairs stored on a smartcard. For more details on configuring the secure shell client with the MKS Toolkit control applet, see From the Control Panel Applet on page 49. Configuring from the Control Panel Applet From the MKS Toolkit control panel applet, you can configure the secure shell client to automatically use a smartcard. On the Secure Shell Client tab, configure the desired machine pattern, and select the Identity tab. A control is available that lets you select which one of the installed smartcard readers is to be used by default. You cannot specify a smartcard reader in per-user configurations. In a Windows domain, these settings are used for all machines within the domain that you might be connecting from, and hence it does not make sense to select a smartcard reader which is specific to the client machine. Backup Solutions Guide 81

90 Configuring the Connectivity Suite Troubleshooting In the event that you are having difficulties with your smartcard and the MKS Toolkit secure utilities, there are several steps that you can take to try and isolate the problem. First, you should verify that your smartcard reader has been properly installed. To do this, launch the MKS Toolkit control panel applet and check the client configuration (as discussed in the previous section) for a machine pattern. If there are no smartcard readers installed on your system, the control that allows you to select the default reader is disabled. If the reader is properly installed you should be able to pull down the list and see the reader displayed. However, the reader s appearance in the list does not guarantee that it is currently powered up. If you are having difficulty with the smartcard itself, you can use secshkeygen -v to test the smartcard. If you believe you already have a key on the card, you can attempt to download the public key from the card with a command like: secsh-keygen -v -v -v -D 0 -f mykey This command displays logging information (in the console window) that describes what it is trying to do, and in the event of a failure it should display a message that explains the nature of the failure. If this is your first attempt to use the smartcard, the most likely problem is that you do not yet have a CSP installed which recognizes the smartcard that you are using. If you have used the smartcard in the past, and it no longer functions, the most likely problem is one of the following: The smartcard reader has been inadvertently disconnected. The smartcard is not properly inserted in the reader. You have incorrectly entered the PIN number. Many smartcards block access to the card after three attempts to use the card with the wrong PIN. In such a case, you must use an administrative tool to unlock the card. 82 MKS Toolkit

91 Configuring the Telnet Server Configuring the Telnet Server The telnetd service is normally started by Windows NT/2000/XP service control manager when the system boots and can be configured on the Telnet Server tab of the MKS Toolkit control panel applet. This applet can by selecting Configuration > Configuration Information from the MKS Start menu or with the grconfig utility. From this tab, you can configure the display text for many of the logon and initialization processes, such as the Login, Password, and Domain prompts, as well as customize the timeout value and error logging level. For example, to modify the string displayed when you first connect to the telnetd service by changing the information in the Banner field and click the Apply button. To view the effects of this modification, open a shell window and type: telnet localhost Backup Solutions Guide 83

92 Configuring the Connectivity Suite You should see something similar to: Welcome to MKS Telnet Server Version login: with the Welcome to MKS message replaced with the text you entered in the Banner field. From the Telnet Server configuration tab you can also set advanced settings for the telnetd service by clicking Advanced Settings. A new dialog appears: From this dialog, you can set the following: TCP/IP Port This field specifies the port that the telnetd service uses to listen for connections. The default is port 23. Command Shell This area of the tab specifies the command interpreter to use for telnet sessions. You can choose $SHELL, cmd.exe, or Other. When $SHELL is chosen, the value of the SHELL environment variable is used as the command interpreter. When cmd.exe is chosen the standard Windows command interpreter (cmd.exe) is used. Finally, when Other is chosen, 84 MKS Toolkit

93 Configuring the Telnet Server you can specify the command to run to launch the command interpreter in the Other field while specifying the argument to that command in the Arguments field. By default, $SHELL is chosen. Include/Exclude These are the Include and Exclude lists for the telnetd service. The Include list shows addresses which are explicitly allowed to connect to the service while the Exclude list shows those addresses which are denied access and cannot telnet into the machine. Each list can show single, multiple, or a range of IP addresses to either include or exclude from the service. The include/exclude lists works as follows: Upon initialization, telnetd checks the incoming IP address against all patterns in the include list if there is a match the user is allowed access. If no match is found, the exclude list is then examined, if the incoming IP address is found the user is denied access to the telnetd service. If there is no match in either list, the default action is to allow all incoming IP addresses access to the service. To change this default policy, simply add the IP range > to the exclude list and individually specify authorized IP addresses in the include list. For more information about the service utility, see the service reference page in the online MKS Toolkit Utilities Reference. Note You can start and stop the telnetd service from the Manage Services tab of the MKS Toolkit control panel applet or with the service utility. Backup Solutions Guide 85

94 Configuring the Connectivity Suite 86 MKS Toolkit

95 Index Symbols.netrc authentication file 13, 22 23, 57, 60.rhosts authentication file 22, 57, 59 60, 78 A accessing remote systems 5 6 accessing remote X11 applications administering remote servers administering remote workstations authentication rexecd rlogind 23 rshd authentication agents 25, 28 29, 34, 64 authentication file.netrc 13, 22 23, 57, 60.rhosts 22, 57, 59 60, 78 hosts.equiv 22, authentication files 10, 13, 16, 18 19, 49 automated testing, performing 47 B basics of rcp basics of rexec basics of rlogin basics of rsh 10 C choosing a connectivity tool configuring remote utilities configuring secure shell client (secsh) configuring secure shell service (secshd) 68 configuring secure utilities configuring telnetd connectivity tool, choosing connectivity, description 3 connectivity, different approaches to 7 8 contents of MKS Toolkit Connectivity Suite 5 7 control panel applet, MKS Toolkit 27, 29, 31, 49, 54 55, 61, 69, 78, 81 83, 85 copy files between two remote machines with rcp 16 copying directories with rcp 17 copying files to a directory with rcp 17 D deploying applications description of connectivity 3 different approaches to connectivity 7 8 distributed builds, performing 47 domain users and rcp 18 domain users and rexec 14 domain users and rsh 11 E executing multiple commands with rsh 10 G generating keypairs graphical connections 6 grconfig utility 49, 54, 61, 83 H hosts.equiv authentication file 22, Backup Solutions Guide 87

96 Index I IPv6 addresses 72 K keypairs 49, 61, keypairs, generating L LSA database 22, 50 51, M mixed environment 4, 37 MKS Toolkit Connectivity Suite contents 5 7 MKS Toolkit control panel applet 27, 29, 31, 49, 54 55, 61, 69, 78, 81 83, 85 mksauth utility 51 Motif 6 O OpenGL 6 OpenSSH 6, 25, 29, 33, OpenSSL 6, 25 P passwd utility 51, 57 passwordless authentication 28, 33, 61, 77 passwords 13 14, 19, 22 23, 34, 50 51, 56 57, 60 61, 75, 77 78, 83 PC Anywhere 3 performing automated testing 47 performing distributed builds 47 private keys 28, 74 76, 79, 81 public keys 25, 28, 74 75, 77, 79, Q querying telnetd R rconfig utility 54, 56 rcp and domain users 18 basics copy files between two remote machines 16 copy files to a directory 17 copying directories 17 redirection with rexec 15 redirection with rsh remote copy (rcp) 6 Remote Desktop 3 remote execution (rexec) 5 6, 9, 12 15, 20 22, 43 44, 52, 57, 60 remote execution service (rexecd) 6, 9, 12 14, 20 23, 49, 51 52, 54 55, 57, 60 remote file copy (rcp) 5, 9, 15 18, 20 22, 35, 43, 45, 52, 56, 58 remote login (rlogin) 5 6, 9, 18 21, 23, 37, 39, remote login daemon (rlogind) 5 remote login service (rlogind) 6, 9, 18, 20 21, 23, 39, 53 54, remote servers, administering remote services 6, remote shell (rsh) 5 6, 9 12, 14 16, 18, 20 22, 43, 47, 52, 56, 58 remote shell service (rshd) 6, 9 10, 13 16, 18, 20 23, 49 52, 54 59, 78 remote systems, accessing 5 6 remote utilities 5, 8 23 remote utilities, configuring remote workstations, administering remote X11 applications, accessing rexec and domain users 14 basics redirection 15 specifying a password 13 specifying a user name 13 rexecd authentication concurrent connections 56 event logging handling domain users 55 starting and stopping 20, 55 status rlogin basics specifying a user 19 rlogind 88 MKS Toolkit

97 Index authentication 23 rsetup utility 54, 56 57, 78 rsh and domain users 11 basics 10 executing multiple commands 10 redirection specifying a user name 10 rshd authentication concurrent connections 52, 56 event logging 52, handling domain users 52 53, 55 starting and stopping 20, 55 status S sample network scheduling utilities 50 secsh-add utility 25, secsh-agent utility 25, secsh-keygen utility 25, 75 77, secsh-keyscan utility 25 secure communications 6 7 secure copy (scp) 5 6, 25, 28, 33, 35, 43 secure ftp (sftp) 5 7, 25, 28 31, 33, 35, 43 secure services 7, secure sftp server (sftp-server) 7, 25 secure shell client (secsh) 6 8, 25 27, 29, 34, 37, secure shell client (secsh), configuring secure shell service (secshd) 7 8, 25, 27, 29, 33, 68, 75, secure shell service (secshd), configuring 68 secure utilities 6, 8, secure utilities, configuring secure X11 7, 27 28, 34 sftp changing directory 30 listing directory contents 30 transferring files smartcards specifying a password with rexec 13 specifying a user name with rexec 13 specifying a user name with rlogin 19 specifying a user name with rsh 10 SSH protocols 26, ssh.com 29, 33, 77 starting and stopping rexecd 20 starting and stopping rshd 20 starting and stopping telnetd 35 T telnet server (telnetd) 6, 8, 35 36, telnet utility 35 37, telnetd querying starting and stopping 35 telnetd, configuring V Visual SFTP W Windows environment 3 5 Windows Terminal Server 3, 7 X X server 6 8, 27, 37 38, 43, 46 X terminal emulator (xtem) 6, 8, 34, Backup Solutions Guide 89