This section provides instructions for administering an FTP Server and for accessing remote systems in the Solaris environment.
This section includes information on working with remote files.
The FTP Server is based on wu-ftpd. Originally developed by Washington University in Saint Louis, wu-ftpd is widely used for distribution of bulk data over the Internet and is the preferred standard for large FTP sites. For information on the licensing terms, refer to the materials that are incorporated at /var/sadm/pkg/SUNWftpu/install/copyright.
For the purpose of this chapter, a remote system is a workstation or server that is connected to the local system with any type of physical network and configured for TCP/IP communication.
On systems running a Solaris release, TCP/IP configuration is established automatically during startup. For more information, see System Administration Guide: IP Services.
The Solaris 10 release includes several changes to the FTP service. The changes include enhancements to the FTP server, and changes to the ftpcount, ftpwho and ftp commands.
The enhancements to the FTP server improve scalability and transfer logging. These options are covered in Configuration Help for Busy Sites and in the ftpaccess(4) man page. In specific:
The sendfile() function is used for binary downloads
New capabilities supported in the ftpaccess file
flush-wait controls the behavior at the end of a download or directory listing
ipcos sets the IP Class of Service for either the control or data connection
passive ports can be configured so that the kernel selects the TCP port to listen on
quota-info enables retrieval of quota information
recvbuf sets the receive (upload) buffer size used for binary transfers
rhostlookup allows or disallows the lookup of the remote hosts name
sendbuf sets the send (download) buffer size used for binary transfers
xferlog format customizes the format of the transfer log entry
-4 option which makes the FTP server only listen for connections on an IPv4 socket when running in standalone mode
In addition, ftpcount and ftpwho now support the -v option, which displays user counts and process information for FTP server classes defined in virtual host ftpaccess files. See the ftpcount(1) and ftpwho(1) man pages for more information.
The FTP client and server now support Kerberos. For more information refer to the ftp(4) man page and to Kerberos User Commands in System Administration Guide: Security Services.
The ftp command has been changed. By default, a Solaris FTP client connected to a Solaris FTP server lists both directories as well as plain files when the ls command is issued to the client. If the FTP server is not running in the Solaris OS, directories may not be listed. To allow for the default Solaris behavior when connecting to non-Solaris FTP servers, the /etc/default/ftp file can be edited appropriately on each Solaris client. To make the change for individual users, the FTP_LS_SENDS_NLST environment variable can be set to yes. For more information see the ftp(4) man page.
The ftpd daemon is managed by the Service Management Facility. Administrative actions on this service, such as enabling, disabling, or restarting, can be performed using the svcadm command. The service's status for all daemons can be queried using the svcs command. For an overview of the Service Management Facility, refer to Chapter 18, Managing Services (Overview), in System Administration Guide: Basic Administration.
Significant changes were made to the FTP Server in the Solaris 9 release, so this section has been retained for the Solaris 10 release. The FTP Server is compatible with Solaris 8 FTP software, yet offers new capability with improved performance for Solaris 9 users.
Table 27–1 What's New for the Solaris 9 FTP Server
Feature |
Description |
For Information |
---|---|---|
User classification by type and location |
Permits you to define a class of users, based on type and address | |
Limits per class |
Controls the number of users from a certain class who are allowed simultaneous login, based on limits that are set in the ftpaccess file | |
System-wide and directory-related messages |
Displays the messages that you specify for particular events | |
Upload permissions per directory |
Allows you to control uploads to the FTP Server, including file and directory creation and permissions | |
File name filter |
Enables you to specify which characters, in what sequence, are acceptable in the name of an uploaded file | |
Virtual host support |
Permits you to configure the FTP server to support multiple domains on a single machine | |
Command logging |
Allows logging of commands that are executed by real, guest, and anonymous FTP users | |
Transfer logging |
Allows logging of transfers for real, guest, and anonymous FTP users | |
As-needed compression and archiving |
Allows as-needed compression and archiving by using conversions that are specified in the ftpconversions file |
The following list shows the Solaris 8 features that are not supported in later releases.
The Solaris 8 /etc/default/ftpd is not supported in later releases. During upgrade, BANNER and UMASK entries are converted to their wu-ftpd equivalents. However, the system administrator might need to manually convert some BANNER lines for the equivalent ftpaccess greeting capability. For further information, see ftpaccess(4).
The sublogin feature that is provided by the Solaris 8 FTP Server is not supported by the Solaris 9 FTP Server.
This chapter includes tasks that are described in the following table to set up and administer an FTP server.
Task |
Description |
For Instructions |
---|---|---|
Configure access to the FTP server |
Use the ftpaccess, ftpusers, and the ftphosts files in the /etc/ftpd directory to establish or restrict access to the FTP server. |
How to Control the Number of Invalid Login Attempts How to Disallow FTP Server Access to Particular Users |
Set up FTP server logins |
Establish login accounts for real, guest and anonymous users. | |
Customize message files |
Edit the /etc/ftpd/ftpaccess file to configure the FTP server to return messages to the FTP client related to specific events. |
How to Customize Message Files |
Configure access to files on the FTP server |
Use the /etc/ftpd/ftpaccess file to specify classes of users who are allowed to execute certain commands or to download and upload files to the FTP server. | |
Enable limited or complete virtual hosting |
Use the /etc/ftpd/ftpaccess file to configure the FTP server to support multiple domains on the same machine. | |
Start the FTP server |
Change the service properties to start the FTP server in nowait, standalone mode or foreground mode. |
How to Start an FTP Server Using SMF |
Shut down the FTP server |
Use the /etc/ftpd/ftpaccess file and run the ftpshut to shut down the FTP server. | |
Troubleshoot some common FTP server problems |
Check syslogd and use greeting text and log commands to debug problems on the FTP server. |
How to Check syslogd for FTP Server Messages |
You can use the following configuration files in the /etc/ftpd directory to control access to the FTP server.
ftpusers is used to list users who are denied access to the FTP server.
ftphosts is used to allow or deny login from various hosts to various accounts on the FTP server.
ftpaccess is the main FTP configuration file. The FTP server only reads the /etc/ftpd/ftpaccess file if called with the -a option. When the ftpaccess file is used, all users must be members of a class to be allowed access to the FTP server. You can specify many ftpaccess directives that apply only to a particular class.
For further information, see ftpusers(4), ftphosts(4), and ftpaccess(4).
In all FTP server configuration files, lines beginning with # signs are treated as comments.
To log in to the FTP server, users must be members of a class when the ftpaccess file is used. To add the class directive to the ftpaccess file, you specify the class name, typelist of users who are permitted access from a particular host.
Become superuser or assume an equivalent role.
Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.
Add entries for anonymous, guest, and real users in the ftpaccess file.
class class typelist addrglob[addrglob...] |
Keyword that is used to define FTP users.
A name that is defined by the class keyword. Each login is compared against a list of defined classes. The logged in user is considered a member of the first class matched.
A comma-separated list of the keywords that match the three types of users: anonymous, guest, and real.
A globbed domain name or a globbed numeric address. The addrglob can also be the name of a file, starting with a slash (`/`), which contains additional address globs: address:netmask or address/cidr.
Here are some examples of globbed addresses:
Numeric IPv4 address: 10.1.2.3
Globbed domain name *.provider.com
Globbed numeric IPv4 address 10.1.2.*
Numeric IPv4 address:netmask 10.1.2.0:255.255.255.0
Numeric IPv4 address/CIDR 10.1.2.0/24
Numeric IPv6 address: 2000::56:789:21ff:fe8f:ba98
Numeric IPv6 address/CIDR: 2000::56:789:21ff:fe8f:ba98/120
class local real,guest,anonymous *.provider.com class remote real,guest,anonymous * |
The previous example defines the local class as any user of the type real, guest, or anonymous who logs in from *.provider.com. The last line defines remote as any user who logs in from anywhere other than *.provider.com.
You can limit the number of simultaneous logins by users of a certain class with directives that are set in the ftpaccess file. Each login limit contains the name of a class, a UUCP-style days-of-week list, and a message file to display if the limit is exceeded.
To set user login limits, follow the steps in the next procedure.
Become superuser or assume an equivalent role.
Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.
Add the following entries to the ftpaccess file:
limit class n times [message-file] |
Keyword that is used to restrict simultaneous logins by the specified number of users of a defined class at certain connection times.
A name that is defined by the class keyword. Each login is compared against a list of defined classes. The logged-in user is considered a member of the first class matched.
Number of users.
Day-of-week and time-of-day when the class can connect. Use Any for any day.
Message file that is displayed if a user is denied access.
limit anon 50 Wk0800-1800 /etc/ftpd/ftpmsg.deny limit anon 100 Any /etc/ftpd/ftpmsg.deny limit guest 100 Any /etc/ftpd/ftpmsg.deny |
The first line of the preceding example shows a limit of 50 simultaneous logins that are allowed to users of class anon during weekly work hours. The second line limits anon users to 100 simultaneous logins outside of working hours. The last line shows a limit of 100 guest logins that are allowed at any time. For information on how to specify day and time parameters, see ftpaccess(4).
The example further indicates that the content of the file /etc/ftpd/ftpmsg.deny is returned when a specified login limit is reached, assuming ftpmsg.deny exists. For information on using the /usr/sbin/ftpcount command to view the number and login limit for each class of user who is logged in at a particular time, see ftpcount(1).
Users are allowed login to the FTP server unless a specified limit is reached. Anonymous users are logged in as the user ftp. Real users are logged in as themselves, and guests are logged in as real users with a chroot environment to limit access privileges.
For information on using the /usr/sbin/ftpwho command to check the identities of the users logged into the FTP server, see ftpwho(1).
If a login to the FTP server fails because of a problem such as misspelling required information, login is usually repeated. The user is allowed a specific number of consecutive login attempts before a message is logged to the syslog file. At that point, the user is disconnected. You can set a failure limit on the number of login attempts by following steps in the next procedure.
Become superuser or assume an equivalent role.
Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.
Add the following entries to the ftpaccess file.
loginfails n |
Keyword that is used to assign the number of login failures that are permitted before the FTP connection is terminated
Number of times a login can fail
loginfails 10 |
The preceding example states that the user is disconnected from the FTP server after 10 failed login attempts.
The /etc/ftpd/ftpusers file lists names of users who are not allowed to log in to the FTP server. When login is attempted, the FTP server checks the /etc/ftpd/ftpusers file to determine whether the user should be denied access. If the user's name is not found in that file, the server then searches the /etc/ftpusers file.
If the user's name is matched in /etc/ftpusers, a syslogd message is written with a statement that the match was found in a deprecated file. The message also recommends the use of /etc/ftpd/ftpusers instead of /etc/ftpusers.
Support for the /etc/ftpusers file has been deprecated in this release. If the /etc/ftpusers file exists when the FTP server is installed, the file is moved to /etc/ftpd/ftpusers.
For additional information, see syslogd(1M), in.ftpd(1M), and ftpusers(4)
Become superuser or assume an equivalent role.
Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.
Add entries to the /etc/ftpd/ftpusers file for users who are not allowed to log in to the FTP server.
root daemon bin sys adm lp uccp nuucp listen nobody noaccess nobody4 |
The previous example lists the typical entries in the ftpusers file. User names match entries in the /etc/passwd. The list generally includes the root and other administrative and system application identities.
The root entry is included in the ftpusers file as a security measure. The default security policy is to disallow remote logins for root. The policy is also followed for the default value that is set as the CONSOLE entry in the /etc/default/loginfile. See login(1).
In addition to the controls mentioned previously, you can add explicit statements to the ftpaccess file to restrict access to the FTP server.
Become superuser or assume an equivalent role.
Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.
Add the following entries to the ftpaccess file.
By default, all users are allowed access to the default (non-virtual) FTP server. To deny access for specific users (other than anonymous), add the following entry:
defaultserver deny username [username...] |
Keyword that is used to identify the non-virtual server to which access can be denied or allowed
Login name of a user with restricted access to the defaultserver
To allow access for users who are not listed on the deny line, add the following line:
defaultserver allow username [username...] |
To prevent access by anonymous users, add the entry:
defaultserver private |
defaultserver deny * defaultserver allow username |
The previous example states that the FTP server denies access to all users except anon users and those users who are listed on the allow line.
You can also use the ftphosts file to deny access to particular login accounts from various hosts. See ftphosts(4) for additional information.
To access an FTP server, you must first log in. The FTP server supports three types of user login accounts for real, guests, and anonymous users.
Real users have accounts that allow them to establish terminal sessions on systems that run the FTP server. Subject to directory and file access permissions, the entire disk structure is visible to real users.
Guest users also need accounts to log in to the FTP server. Each guest account is set up with a user name and password. Functioning login shells are not assigned to guests to prevent users from establishing terminal sessions. At login, the FTP server performs a chroot(2) operation to restrict a guest's view of the server's disk structure.
Login shells for real and guest users must be listed in the /etc/shells file to allow access to the FTP server.
Anonymous users log in to the FTP server by using the either ftp or anonymous as a user name. By convention, anonymous users supply an email address when prompted for a password.
At login, the FTP server performs a chroot(2) operation that restricts the anonymous user's view of the server's disk structure. A single file area is shared by all anonymous users, unlike the separate areas that can be created for each guest user.
Real and guest users log in by using individual accounts with passwords that are known only to one person. Anonymous users log in to a well-known account that is potentially available to anyone. Most large-scale file distribution is created by using the anonymous account.
To enable access for real users to the FTP server, follow these instructions:
Verify that the user has an account that is set up with a user name and password that can be used to establish a terminal session.
For more information, see Chapter 4, Managing User Accounts and Groups (Overview), in System Administration Guide: Basic Administration.
Confirm that the real user is a member of a class in the ftpaccess file.
For information on the user classes that are defined in the ftpaccess file, see How to Define FTP Server Classes.
Verify that the user's login shell is listed in the /etc/shells file.
The ftpconfig script is used to copy all necessary system files to the home directory. When the guest user and the guest's home directory already exist, the ftpconfig script updates the area with the current system files.
For more information, see ftpconfig(1M)
Unlike the user name (anonymous or ftp) that is set for anonymous users, user names for FTP guests are not fixed. Any name that would work as a real user name can be selected.
To enable access by a guest user to the FTP server, do the following:
Use the useradd script to create a guest user account with a login shell of /bin/true and a home directory of /root-dir/./home-dir.
For more information, see useradd(1M) and Chapter 4, Managing User Accounts and Groups (Overview), in System Administration Guide: Basic Administration.
In this procedure, /home/guests/./guest1 is used as the home directory name for a user who is called guest1.
# /usr/sbin/useradd -m -c "Guest FTP" -d \ /home/guests/./guest1 -s /bin/true guest1 |
Assign a password to the guest account.
Add a guestuser entry to the ftpaccess file.
guestuser guest1 |
You can also use the guestgroup capability in the ftpaccess file to specify guest users. The guest-root capability in ftpaccess eliminates the need for the /./ in the guest user's home directory path.
Confirm that the guest user is a member of a class in the ftpaccess file. See How to Define FTP Server Classes for further information.
Use the ftpconfig script to create the required files in the chroot area.
/usr/sbin/ftpconfig -d /home/guests |
Confirm that /bin/true is listed in the /etc/shells file. See How to Create the /etc/shells file.
In this example, the FTP area is set up in the /home/guests directory.
# /usr/sbin/ftpconfig -d /home/guests Updating directory /home/guests |
The ftpconfig script creates the anonymous user account and populates the home directory with the required files.
For more information, see ftpconfig(1M).
To enable access by an anonymous user to the FTP server, follow these instructions:
Use the ftpconfig script to create the anonymous user account.
/usr/sbin/ftpconfig anonymous-ftp-directory |
Confirm that the anonymous user is assigned to a class in the ftpaccess file.
See How to Define FTP Server Classes for further information.
In this example, the FTP area is set up in the /home/ftp directory.
# /usr/sbin/ftpconfig /home/ftp Creating user ftp Updating directory /home/ftp |
Become superuser or assume an equivalent role.
Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.
Create the /etc/shells file.
Edit /etc/shells. Add the full path to each shell on a single line.
The following is an example of an /etc/shells file with a /bin/true listed for FTP guest users:
/sbin/sh /bin/csh /bin/jsh /bin/ksh /bin/remsh /bin/rksh /bin/rsh /bin/sh /usr/bin/csh /usr/bin/ksh /usr/bin/bash /usr/bin/tcsh /usr/bin/zsh /bin/true |
You can configure the FTP server to return messages that are related to specific events to the FTP client. A welcome message might be set to display when a user logs in to the FTP server. Another message could appear when the user makes a directory change.
In addition to plain text, message files can contain one or more magic cookies. A magic cookie is composed of a % (percent sign), followed by a single character. When you embed a cookie in message text, information that is associated with the cookie appears on screen at the point the message file is called.
For example, message text might contain the cookie %L:
Welcome to %L! |
When the message is displayed, the magic cookie %L is replaced with the name of the server as defined by the hostname statement in the ftpaccess file. For a complete list of supported message cookies, see ftpaccess(4).
If the host name is not defined in the ftpaccess file, the default host name for the local machine is used.
Become superuser or assume an equivalent role.
Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.
Edit your message file to include magic cookies as appropriate.
See ftpaccess(4) for a list of cookies you can use.
The following is an example of a message file that includes magic cookies:
Welcome to %L -- local time is %T. You are number %N out of a maximum of %M. All transfers are logged. If your FTP client crashes or hangs shortly after login please try using a dash (-) as the first character of your password. This will turn off the informational messages that may be confusing your FTP client. Please send any comments to %E. |
After the user is logged in, system-related or application-related messages are displayed on screen. The ftpaccess file lists the events that trigger associated message statements.
Become superuser or assume an equivalent role.
Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.
Add the following entries to the ftpaccess file:
message message-file [when [class ...]] |
Keyword that is used to specify the message file to be displayed when a user logs in or executes the command to change the working directory.
Name of the message file to be displayed.
Parameter that is set as login or cwd=dir. See the following example.
The class specification allows the message to be displayed only to members of a particular class.
message /etc/ftpd/Welcome login anon guest message .message cwd=* |
The preceding example states that the file /etc/ftpd/Welcome is displayed at login for users of the class anon or guest. The second line states that the .message file in the current working directory is displayed for all users.
Message files are created relative to the chroot directory for guest and anonymous users.
The first time a directory is visited, README files can be listed. To configure the README option, add the following entries to the ftpaccess file.
Become superuser or assume an equivalent role.
Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.
Add the following entries to the ftpaccess file.
readme message-file [when [class...]] |
Keyword that is used to specify a message file to be checked when a user logs in or changes the working directory. If the message file exists, the user is notified and is given the date the file was modified.
Name of the message file to be checked.
Parameter that is set as login or cwd=dir. See the following example.
The class specification allows the message to be displayed only to members of a particular class.
The greeting and banner keywords can also be used to send messages to users. See ftpaccess(4).
readme README* login readme README* cwd=* |
The previous example states that any files that match README* are listed at login or when a directory is changed. Here is a sample login that is based on the settings that are used in that example.
% ftp earth Connected to earth. 220 earth FTP server ready. Name (earth:rimmer): ftp 331 Guest login ok, send your complete e-mail address as password. Password: 230- 230-Welcome to earth -- local time is Thu Jul 15 16:13:24 1999. 230- 230-You are number 1 out of a maximum of 10. 230-All transfers are logged. 230- 230-If your FTP client crashes or hangs shortly after login please try 230-using a dash (-) as the first character of your password. This will 230-turn off the informational messages that may be confusing your FTP 230-client. 230- 230-Please send any comments to ftpadmin@earth. 230- 230 Guest login ok, access restrictions apply. ftp> cd pub 250-Please read the file README 250- it was last modified on Thu Jul 15 16:12:25 1999 - 0 days ago 250 CWD command successful. ftp> get README /tmp/README 200 PORT command successful. 150 Opening ASCII mode data connection for README (0 bytes). 226 ASCII Transfer complete. ftp> quit 221 Goodbye. |
The FTP server access controls in this section supplement the standard file and directory access controls available with the Solaris release. Use the standard Solaris commands to restrict who can access, change, or upload files. See chmod(1), chown(1), and chgrp(1).
To use the permission capabilities in ftpaccess to specify what type of user is allowed to perform which commands, do the following:
Become superuser or assume an equivalent role.
Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.
Add the following entries to the ftpaccess:
command yes|no typelist |
The commands chmod, delete, overwrite, rename, or umask
Allows or disallows a user to issue a command
A comma-separated list of any of the keywords anonymous, guest, and real
The following are examples of permissions that are set for file access functions on FTP server.
chmod no anonymous, guest delete no anonymous overwrite no anonymous rename no anonymous umask no guest, anonymous |
The preceding example states the following:
Anonymous users are not allowed to delete, overwrite, or rename files.
Guests and anonymous users are both prevented from changing access modes and resetting the umask.
You can control uploads and downloads that are started to and from the FTP server by setting permissions on directories on the server. By default, uploads are not allowed for anonymous users. Be very careful when enabling anonymous uploads.
Add the directives to the ftpaccess file to specify upload permissions and error messages for upload failures.
Become superuser or assume an equivalent role.
Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.
Add the following entries to the ftpaccess file.
To enable users to upload files, add the following entry:
upload [absolute|relative] [class=<classname>]... [-] root-dir \ dirglob yes|no owner group mode [dirs|nodirs] [<d_mode>] path-filter typelist mesg allowed-charset {disallowed regexp...} |
Keyword that is applied to users who have a home directory (the argument to chroot()) of the root-dir. The root-dir can be specified as “*” to match any home directory.
Parameter that specifies whether the root-dir directory paths are interpreted as absolute or relative to the current chroot directory.
Keyword that is used to specify any number of class=<classname> restrictions. If restrictions are specified, the upload clause only becomes effective if the current user is a member of one of the specified classes.
User's root directory and the home directory for anonymous users.
A pattern to match a directory name. An asterisk can be used in any place or alone to signify any directory.
Variable that allows or disallows upload to the FTP server.
Owner of files that are uploaded into dirnames.
Group that is associated with files that are uploaded into dirnames.
Parameter that is used to specify access permissions for uploaded files. The default mode 0440 prevents the anonymous account from reading uploaded files.
Keyword that allows or disallows users to create subdirectories in a directory that is listed in dirnames.
Optional mode that determines the permissions for a newly created directory.
Keyword that controls the names of uploaded files.
A comma-separated list of any of the keywords anonymous, guest, and real.
Message file that is displayed fails to match the regexp criteria.
Alphanumeric characters allowed or disallowed in file names.
upload /export/home/ftp /incoming yes ftpadm ftpadmin 0440 nodirs path-filter anonymous /etc/ftpd/filename.msg ^[-A-Za-z0-9._]*$ ^[.-] |
The preceding example states the following:
FTP user accounts that use chroot to /export/home/ftp can upload to the /incoming directory. Uploaded files are owned by user ftpadm and the group ftpadmin. The mode is set to 0440 with the nodirs keyword to prevent anonymous users from creating subdirectories.
For anonymous users, a file name is any sequence of A-Z, a-z, 0-9, . (dot), - (dash), or _ (underline). File names cannot start with a . (dot) or - (dash). If a file name fails this filter, the /etc/ftpd/filename.msg message is displayed if the FTP Administrator has created the message file. This message is followed by an FTP server error message.
Ownership and permissions on a directory into which anonymous uploads are allowed should be tightly controlled. The FTP Administrator should be the owner of all files uploaded to the FTP server. You need to create an FTP Administrator when anonymous users are allowed to upload files. The directory should be owned by the user ftpadm and group ftpadm with permissions set to 3773.
The access mode for files uploaded to the FTP server should be 0440. The 0440 mode prevents the anonymous account from reading uploaded files. This restriction protects your server from becoming a staging area for third-party file distribution.
To make uploaded files available for distribution, the FTP Administrator can move files to a public directory.
Become superuser or assume an equivalent role.
Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.
Add the following entries to the ftpaccess file to prevent users from retrieving files.
noretrieve [absolute|relative] [class=classname]... [-] filename ... |
Keyword that is used to deny retrieval of a particular file or files
Parameter that specifies whether the root-dir directory paths are interpreted as absolute or relative to the current chroot directory
Keyword that is used to specify class=<classname> of users to which noretrieve restrictions apply
Name of file the user is not permitted to retrieve
noretrieve /etc/passwd |
The preceding example states that all users are prevented from retrieving the /etc/passwd file.
Virtual hosting allows the FTP server to support multiple domains on the same machine. Each virtual host requires a separate logical interface and IP address.
The FTP server supports two types of virtual hosting: limited and complete. With limited virtual hosting, the same configuration files are used for all virtual hosts. With complete virtual hosting, separate configuration files can be used for each virtual host.
By default, real and guest users are not allowed to log in to virtual hosts. You can set the following ftpaccess directives to override the default.
To allow access to specific users: virtual address allow username To deny access to anonymous users: virtual address private username |
See ftpaccess(4) for further information.
Limited virtual hosting provides partial support for virtual FTP servers. You can enable support for limited virtual hosting by specifying the virtual root directory. If required, you can also set the following parameters for the virtual host in the ftpaccess file:
banner
logfile
hostname
All directives in the ftpaccess file are shared globally across all virtual servers.
Become superuser or assume an equivalent role.
Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.
Add the following entries to the ftpaccess file.
virtual address root|banner|logfile path virtual address hostname|email string |
Keyword that is used to enable virtual server capabilities
IP address of the virtual server
The root directory of the virtual server
Banner file that is displayed when a connection is made to the virtual server
Record of file transfers that are made to and from the virtual server
Variable that is used to specify the location of directories and files on the virtual server
Email address that is used in message files and in the HELP command
Name of the host that is shown in the greeting message or status command
Variable that is used to specify email or hostname parameters
While it is possible to use hostname as the address of the virtual server, you are strongly encouraged to use the IPv4 address instead. DNS must be available when the FTP connection is received in order for hostname to be matched. For an IPv6 host, use the host name rather than the IPv6 address.
virtual 10.1.2.3 root /var/ftp/virtual/ftp-serv virtual 10.1.2.3 banner /var/ftp/virtual/ftp-serv/banner.msg virtual 10.1.2.3 logfile /var/log/ftp/virtual/ftp-serv/xferlog |
The preceding example sets the location of the root directory, banner, and logfile on a virtual FTP server.
The ftpaddhost(1M) script with the -l option is provided to configure limited virtual hosts.
In the following example, ftpaddhost is run with -l -b -x options to configure limited virtual hosting with a test banner and the logfile /var/ftp/virtual/10.1.2.3/xferlog under a virtual root /var/ftp/virtual/10.1.2.3.
# ftpaddhost -l -b -x /var/ftp/virtual/10.1.2.3/xferlog \ /var/ftp/virtual/10.1.2.3 |
Complete virtual hosting allows separate configuration files for each virtual domain. To enable complete support for virtual hosting on the FTP server, you can create or modify the following FTP configuration files for specific domains:
ftpaccess
ftpusers
ftpgroups
ftphosts
ftpconversions
For further information, see ftpaccess(4), ftpusers(4), ftpgroups(4), ftphosts(4), and ftpconversions(4).
If separate versions of the configuration files are unavailable, master versions of the files in the /etc/ftpd directory are used.
Become superuser or assume an equivalent role.
Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.
Add the following entry to the /etc/ftpd/ftpservers file.
address /config-file-dir |
IP address of the virtual server
Directory that contains the configuration files that are customized for the virtual host
While it is possible to use hostname as the address of the virtual server, you are strongly encouraged to use the IPv4 address instead. DNS must be available when the FTP connection is received in order for hostname to be matched. For an IPv6 host, use the host name rather than the IPv6 address.
To create a customized version of an FTP server configuration file for the virtual host, copy the master version of the file from /etc/ftpd to the /config-file-dir directory.
For further information, see ftpservers(4).
# # FTP Server virtual hosting configuration file # 10.1.2.3 /net/inet/virtual/somedomain/ 10.1.2.4 /net/inet/virtual/anotherdomain/ |
The preceding example specifies the IP addresses for two different domains on the virtual server.
The ftpaddhost(1M) script with the -c option is provided to configure complete virtual hosts.
In the following example, ftpaddhost is run with -c -b -x options to configure complete virtual hosting with a test banner and the logfile /var/ftp/virtual/10.1.2.3/xferlog under a virtual root /var/ftp/virtual/10.1.2.3.
# ftpaddhost -c -b -x /var/ftp/virtual/10.1.2.3/xferlog \ /var/ftp/virtual/10.1.2.3 |
The FTP server can be started in one of three ways:
As a standalone server run in the background
As a standalone server run in the foreground from the inittab file
A standalone server always has the quickest possible response time, and is intended for large servers that are dedicated to providing FTP service. The standalone server provides low connection latency for dedicated servers because the standalone system never has to be restarted. The standalone server is always running, even during off-peak hours, waiting indefinitely for connections.
By default, the SMF service is configured to start the FTP server using the nowait mode. If the site handles many connections, the FTP server can also be run in standalone mode. See the in.ftpd(1M) man page for information on additional command-line options.
Become superuser or assume an equivalent role.
Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.
Verify the wait property for the FTP server.
The line reporting that wait=FALSE indicates that the server is started in nowait mode.
# inetadm -l network/ftp SCOPE NAME=VALUE name="ftp" endpoint_type="stream" proto="tcp6" isrpc=FALSE wait=FALSE exec="/usr/sbin/in.ftpd -a" user="root" default bind_addr="" default bind_fail_max=-1 default bind_fail_interval=-1 default max_con_rate=-1 default max_copies=-1 default con_rate_offline=-1 default failrate_cnt=40 default failrate_interval=60 default inherit_env=TRUE default tcp_trace=FALSE default tcp_wrappers=FALSE |
Start the FTP server.
# svcadm enable network/ftp |
Become superuser or assume an equivalent role.
Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.
Disable the FTP server.
# svcadm disable network/ftp |
Start the standalone FTP server.
# /usr/sbin/in.ftpd -a -S |
Add the line to an FTP server startup script. See Using Run Control Scripts in System Administration Guide: Basic Administration for information on creating a system startup script.
Become superuser or assume an equivalent role.
Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.
Disable the FTP server.
# svcadm disable network/ftp |
Add an entry to the inittab file to start the service.
The new entry in /etc/inittab should look something like the following:
ftpd:3:respawn:/usr/sbin/in.ftpd -a -s |
Tell init to re-examine /etc/inittab.
This command should start the FTP service.
# init q |
The ftpshut(1M) command closes down the FTP server at a particular time.
When you run ftpshut, a file is generated from command-line options that specify when shutdown occurs, the point at which new connections are refused, and when existing connections are dropped. Users are notified of a server shutdown based on this information. The location of the file that is created by ftpshut is specified by the shutdown directive in the ftpaccess file.
Follow the steps in this procedure to run ftpshut and to add the shutdown directive to the ftpaccess file.
Become superuser or assume an equivalent role.
Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.
Add the following entries to the ftpaccess file.
shutdown path |
Keyword that is used to specify the path to a file that is checked regularly for whether the FTP server is scheduled to be shut down
Location of the file that was created by ftpshut command
Run the ftpshut command.
ftpshut [ -V ] [ -l min] [ -d min] time [warning-message...] |
Command that provides a procedure for notifying users that the FTP server is shutting down.
Option that is specified to display copyright and version information, then terminate
Flag that is used to adjust the time that new connections to the FTP server are denied
Flag that is used to adjust the time that existing connections to the FTP server are disconnected.
Shutdown time that is specified by the word now for immediate shutdown, or in one of two formats (+ number or HHMM) for a future shutdown
Shutdown notification message
Use the ftprestart command to restart the FTP server after shutdown.
For further information, see ftpshut(1M), ftpaccess(4), and ftprestart(1M).
This section describes some of the ways to debug problems with the FTP server.
The FTP server writes messages that are useful for debugging to the location that is specified for daemon messages in the /etc/syslog.conf file. If a problem occurs with the FTP server, check this file first for such messages.
The FTP server messages are controlled by facility daemon and level information. To send messages from the FTP server to /var/adm/message and have syslogd reread its configuration file, follow these instructions:
Add an entry such as the following to the /etc/syslog.conf file.
daemon.info /var/adm/message |
Signal syslogd to reread its configuration.
# svcadm refresh system/system-log |
This action causes informational messages from the FTP Sever to be written to /var/adm/messages.
To use the greeting text capability to check that the correct ftpaccess file is being used, do the following:
Add the following directive to the ftpaccess file.
greeting text message |
Connect to the FTP server.
If the message fails to appear, do the following:
Confirm that the ftpaccess file is in the correct location. Use the strings(1) command to obtain the location of the file from the FTP server binary.
# strings /usr/sbin/in.ftpd | grep "^/.*ftpaccess" |
Check the ftpservers file to see if virtual hosting has been configured.
For further information, see ftpaccess(4), ftpservers(4), strings(1), syslog.conf(4), and pgrep(1).
To see what commands are being executed by FTP users, use the log commands logging capability in ftpaccess.
Add the following directive to the ftpaccess file to log individual commands by users who are specified in typelist.
log commands typelist |
Check messages that are written to the location specified in the /etc/syslog.conf.
The following list includes some suggestions to improve performance on busy FTP sites.
Sites which typically support many simultaneous connections should run the FTP server in standalone mode, see Starting the FTP Server Automatically.
Use vmstat and other system utilities to monitor the system hosting the FTP server. If the system runs low on resources place a limit on the number of simultaneous connections, see How to Set User Login Limits. For more information on system monitoring, see Chapter 13, Monitoring System Performance (Tasks), in System Administration Guide: Advanced Administration.
If you impose a connection limit, consider using the limit-time and timeout idle capabilities in the ftpaccess file to stop users from hogging connections. If you don't impose a connection limit, specify the -Q option to in.ftpd.
If you don't need ftp login and logout records in /var/adm/wtmpx, specify the -W option to in.ftpd.
To reduce the load on the system hosting the FTP server, increase the transfer buffer sizes using the recvbuf and sendbuf capabilities in the ftpaccess file. If large buffer sizes are selected it may be necessary to increase the data activity timeout using the timeout data capability in the ftpaccess file.
The FTP server reads from various databases including the hosts, passwd, group and services. Slow lookups may cause a significant delay logging into the FTP server, configuring the files source first in nsswitch.conf minimizes the lookup times. For more information, see the nsswitch.conf(4) man page.
By default the FTP server attempts to lookup the remote host's name, which can be slow causing a significant delay logging in. The rhostlookup capability in the ftpaccess file can be used to stop this lookup. However be aware that if the remote host's name is not looked up, only its IP address is matched when using other capabilities in the ftpaccess file and when matching entries in the ftphosts file. Also the remote host's IP address will be used in messages and in place of the %R magic cookie. See the description of the rhostlookup capability in the ftpaccess(4) man page for more details.
Retrieving quota information may also cause a significant delay when logging into the FTP server, so only use the quota-info capability in the ftpaccess file if you make use of the quota magic cookies. See the ftpaccess(4) man page for a list of the quota magic cookies.
This chapter describes all the tasks that are required to log in to remote systems and work with their files. This is a list of the step-by-step instructions in this chapter.
This chapter provides tasks that are described in the following table to log in and copy files from remote systems.
Table 29–1 Task Map: Accessing Remote Systems
Task |
Description |
For Instructions |
---|---|---|
Log in to a remote system (rlogin) |
|
How to Search for and Remove .rhosts Files How to Find Out If a Remote System Is Operating How to Find Who Is Logged In to a Remote System |
Log in to a remote system (ftp) |
|
How to Open an ftp Connection to a Remote System How to Close an ftp Connection to a Remote System |
Copy remote files with rcp |
Use the rcp command to copy files to and from a remote system. |
The rlogin command enables you to log in to a remote system. After you are logged in, you can navigate through the remote file system and manipulate its contents (subject to authorization), copy files, or execute remote commands.
If the system you are logging in to is in a remote domain, be sure to append the domain name to the system name. In this example, SOLAR is the name of the remote domain:
rlogin pluto.SOLAR
Also, you can interrupt a remote login operation at any time by typing Control-d.
Authentication (establishing who you are) for rlogin operations can be performed either by the remote system or by the network environment.
The main difference between these forms of authentication lies in the type of interaction they require from you and the way they are established. If a remote system tries to authenticate you, you are prompted for a password, unless you set up the /etc/hosts.equiv or .rhosts file. If the network tries to authenticate you, you are not asked for a password, because the network already knows who you are.
When the remote system attempts to authenticate you, it relies on information in its local files, specifically if one of the following is true:
Your system name and user name appear in the remote system's /etc/hosts.equiv file.
Your system name and user name appear in the remote user's .rhosts file, under the remote user's home directory.
Network authentication relies on one of these two methods:
A “trusting network environment” that has been set up with your local network information service and the automounter.
One of the network information services that is pointed to by the remote system's /etc/nsswitch.conf file contains information about you.
Network authentication generally supersedes system authentication.
The /etc/hosts.equiv file contains a list of trusted hosts for a remote system, one per line. If a user attempts to log in remotely (using rlogin) from one of the hosts that is listed in this file, and if the remote system can access the user's password entry, the remote system allows the user to log in without a password.
A typical hosts.equiv file has the following structure:
host1 host2 user_a +@group1 -@group2 |
When a simple entry for a host is made in hosts.equiv, such as the previous entry for host1, it means that the host is trusted, and so is any user at that machine.
If the user name is also mentioned, as in the second entry in the example, then the host is trusted only if the specified user is attempting access.
A group name that is preceded by a plus sign (+) means that all the machines in that netgroup are considered trusted.
A group name that is preceded by a minus sign (–) means that none of the machines in that netgroup is considered trusted.
The /etc/hosts.equiv file presents a security risk. If you maintain a /etc/hosts.equiv file on your system, you should include only trusted hosts in your network. The file should not include any host that belongs to a different network, or any machines that are in public areas. For example, do not include a host that is located in a terminal room.
The use of hosts that are not trusted can create a serious security problem. Either replace the /etc/hosts.equiv file with a correctly configured one, or remove the file altogether.
A single line of + in the /etc/hosts.equiv file indicates that every known host is trusted.
The .rhosts file is the user equivalent of the /etc/hosts.equiv file. This file contains a list of host-user combinations, rather than hosts in general. If a host-user combination is listed in this file, the specified user is granted permission to log in remotely from the specified host without having to supply a password.
Note that a .rhosts file must reside at the top level of a user's home directory. .rhost files that are located in subdirectories are not consulted.
Users can create .rhosts files in their home directories. Using the .rhosts file is another way to allow trusted access between users' own accounts on different systems without using the /etc/hosts.equiv file.
Unfortunately, the .rhosts file presents a major security problem. While the /etc/hosts.equiv file is under the system administrator's control and can be managed effectively, any user can create a .rhosts file that grants access to whomever the user chooses without the system administrator's knowledge.
In a situation in which all of the users' home directories are on a single server and only certain people have superuser access on that server, a good way to prevent a user from using a .rhosts file is to create an empty file as superuser in their home directory. You would then change the permissions in this file to 000 so that it would be difficult to change it, even as superuser. This change would effectively prevent a user from risking system security by using a .rhosts file irresponsibly. The change would not, however, solve anything if the user is able to change the effective path to his or her home directory.
The only secure way to manage .rhosts files is to completely disallow them. See How to Search for and Remove .rhosts Files for detailed instructions. As system administrator, you can check the system often for violations of this policy. One possible exception to this policy is for the root account; you might need to have a .rhosts file to perform network backups and other remote services.
If your system is configured properly, you can link remote logins. For example, a user on earth logs in to jupiter, and from there decides to log in to pluto.
The user could have logged out of jupiter and then logged in directly to pluto, but this type of linking can be more convenient.
To link remote logins without having to supply a password, you must have the /etc/hosts.equiv or .rhosts file set up correctly.
The rlogin command allows you to log in to a remote system directly or indirectly.
A direct remote login is attempted with the default user name, that is, the user name of the individual who is currently logged in to the local system. This is the most common form of remote login.
An indirect remote login is attempted with a different user name, which is supplied during the remote login operation. This is the type of remote login you might attempt from a workstation that you borrowed temporarily. For instance, if you were in a coworker's office and needed to examine files in your home directory, you might log in to your system remotely, from your coworker's system. However, you would perform an indirect remote login, supplying your own user name.
The dependencies between direct and indirect logins and authentication methods are summarized in the following table.
Table 29–2 Dependencies Between Login Method and Authentication Method (rlogin)
Type of Login |
User Name Supplied By |
Authentication |
Password |
---|---|---|---|
Direct |
System |
Network |
None |
|
|
System |
Required |
Indirect |
User |
Network |
None |
|
|
System |
Required |
When you log in to a remote system, the rlogin command attempts to find your home directory. If the rlogin command can't find your home directory, it assigns you to the remote system's root (/) directory. For example:
Unable to find home directory, logging in with / |
However, if the rlogin command finds your home directory, it sources both your .cshrc and .login files. Therefore, after a remote login, your prompt is your standard login prompt, and the current directory is the same as when you log in locally.
For example, if your usual prompt displays your system name and working directory, and when you log in, your working directory is your home directory, your login prompt resembles the following:
earth(/home/smith): |
Then when you log in to a remote system, you see a similar prompt and your working directory is your home directory, regardless of the directory from which you entered the rlogin command:
earth(/home/smith): rlogin pluto . . . pluto(/home/smith): |
The only difference is that the name of the remote system would substitute for your local system at the beginning of the prompt. The remote file system is parallel to your home directory.
Effectively, if you change directory to /home and then run ls, you see the following:
earth(home/smith): cd .. earth(/home): ls smith jones |
Become superuser or assume an equivalent role.
Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.
Search for and remove .rhosts files by using the find(1) command.
# find home-directories -name .rhosts -print -exec rm {} \; |
Identifies the path to a directory where users' home directories are located. Note that you can enter multiple paths to search more than one home directory at a time.
Identifies the file name.
Prints the current path name.
Tells the find command to apply the rm command to all files that are identified by using the matching file name.
The find command starts at the designated directory and searches for any file that is named .rhosts. If it finds such as file, find prints the path on the screen and removes it.
The following example searches and removes .rhosts files in all the user's home directories that are located in the /export/home directory.
# find /export/home -name .rhosts -print | xargs -i -t rm {} \; |
Find out if a remote system is operating by using the ping command.
$ ping system-name | ip-address |
The name of the remote system
The IP address of the remote system
The ping command returns one of three messages:
Status Message |
Explanation |
---|---|
system-name is alive |
The system can be accessed over the network. |
ping: unknown host system-name |
The system name is unknown. |
The system is known, but is not currently operating. |
If the system you “ping” is located in a different domain, the return message can also contain routing information, which you can ignore.
The ping command has a timeout of 20 seconds. Effectively, if it does not receive a response within 20 seconds, it returns the third message. You can force ping to wait longer (or less) by typing a time-out value, in seconds:
$ ping system-name | ip-address time-out |
For more information, see ping(1M).
Find who is logged in to a remote system by using the rusers(1) command.
$ rusers [-l] remote-system-name |
(No options) Displays the name of the system, followed by the name of users who are currently logged in to it, including root
Displays additional information about each user: the user's login window, login time and date, amount of time logged in, and the name of the remote system from which the user logged on
The following example shows the short output of rusers.
$ rusers pluto pluto smith jones |
In the following example, the long version of rusers shows that two users are logged in to the remote system starbug. The first user logged in from the system console on September 10 and has been logged on for 137 hours and 15 minutes. The second user logged in from a remote system, mars, on September 14.
$rusers -l starbug root starbug:console Sep 10 16:13 137:15 rimmer starbug:pts/0 Sep 14 14:37 (mars) |
Log in to a remote system by using the rlogin(1) command.
$ rlogin [-l user-name] system-name |
(No options) Logs you in to the remote system directly, effectively, with your current user name
Logs you into the remote system indirectly, effectively, with the user name you supply
If the network attempts to authenticate you, you are not prompted for a password. If the remote system attempts to authenticate you, you are asked to provide a password.
If the operation succeeds, the rlogin command displays brief information about your latest remote login to that system, the version of the operating system that is running on the remote system, and whether you have mail waiting for you in your home directory.
The following example shows the output of a direct remote login to pluto. The user has been authenticated by the network.
$ rlogin starbug Last login: Mon Jul 12 09:28:39 from venus Sun Microsystems Inc. SunOS 5.8 February 2000 starbug: |
The following example shows the output of an indirect remote login to pluto, with the user being authenticated by the remote system.
$ rlogin -l smith pluto password: user-password Last login: Mon Jul 12 11:51:58 from venus Sun Microsystems Inc. SunOS 5.8 February 2000 starbug: |
Log out from a remote system by using the exit(1) command.
$ exit |
This example shows the user smith logging out from the system pluto.
$ exit pluto% logout Connection closed. earth% |
The ftp command opens the user interface to the Internet's File Transfer Protocol. This user interface, called the command interpreter, enables you to log in to a remote system and perform a variety of operations with its file system. The principal operations are summarized in the following table.
The main benefit of ftp over rlogin and rcp is that ftp does not require the remote system to be running UNIX. The remote system does, however, need to be configured for TCP/IP communications. However, rlogin provides access to a richer set of file manipulation commands than ftp provides.
Authentication for ftp remote login operations can be established by one of the following methods:
Including your password entry in the remote system's /etc/passwd file or equivalent network information service map or table
Command |
Description |
---|---|
ftp |
Accesses the ftp command interpreter. |
ftp remote-system |
Establishes an ftp connection to a remote system. For instructions, see How to Open an ftp Connection to a Remote System. |
open |
Logs in to the remote system from the command interpreter. |
close |
Logs out of the remote system and returns to the command interpreter. |
bye |
Quits the ftp command interpreter. |
help |
Lists all ftp commands or, if a command name is supplied, briefly describes what the command does. |
reset |
Re-synchronizes the command-reply sequencing with the remote ftp server. |
ls |
Lists the contents of the remote working directory. |
pwd |
Displays the name of the remote working directory. |
cd |
Changes the remote working directory. |
lcd |
Changes the local working directory. |
mkdir |
Creates a directory on the remote system. |
rmdir |
Deletes a directory on the remote system. |
get, mget |
Copies a file (or multiple files) from the remote working directory to the local working directory. |
put, mput |
Copies a file (or multiple files) from the local working directory to the remote working directory. |
delete, mdelete |
Deletes a file (or multiple files) from the remote working directory. |
For more information, see ftp(1).
Ensure that you have ftp authentication.
You must have ftp authentication, as described in Authentication for Remote Logins (ftp).
Open a connection to a remote system by using the ftp command.
$ ftp remote-system |
If the connection succeeds, a confirmation message and prompt are displayed.
Type your user name.
Name (remote-system:user-name): user-name |
If prompted, type your password.
331 Password required for user-name: Password: password |
If the system you are accessing has an established anonymous ftp account, you are prompted for an email address for the password. If the ftp interface accepts your password, it displays a confirmation message and the (ftp>) prompt.
You can now use any of the commands that are supplied by the ftp interface, including help. The principal commands are summarized in Table 29–3.
This ftp session was established by the user smith on the remote system pluto:
$ ftp pluto Connected to pluto. 220 pluto FTP server ready. Name (pluto:smith): smith 331 Password required for smith: Password: password 230 User smith logged in. ftp> |
Close an ftp connection to a remote system by using the bye command.
ftp> bye 221-You have transferred 0 bytes in 0 files. 221-Total traffic for this sessions was 172 bytes in 0 transfers. 221-Thanks you for using the FTP service on spdev. 221 Goodbye. |
A goodbye message appears, followed by your usual shell prompt.
Change to a directory on the local system where you want the files from the remote system to be copied.
$ cd target-directory |
Change to the source directory.
ftp> cd source-directory |
If your system is using the automounter, the home directory of the remote system's user appears parallel to yours, under /home.
Ensure that you have read permission for the source files.
ftp> ls -l |
Set the transfer type to binary.
ftp> binary |
To copy a single file, use the get command.
ftp> get filename |
To copy multiple files at once, use the mget command.
ftp> mget filename [filename ...] |
You can supply a series of individual file names and you can use wildcard characters. The mget command copies each file individually, asking you for confirmation each time.
Close the ftp connections.
ftp> bye |
In this example, the user kryten opens an ftp connection to the system pluto, and uses the get command to copy a single file from the /tmp directory.
$ cd $HOME ftp pluto Connected to pluto. 220 pluto FTP server (SunOS 5.8) ready. Name (pluto:kryten): kryten 331 Password required for kryten. Password: xxx 230 User kryten logged in. ftp> cd /tmp 250 CWD command successful. ftp> ls 200 PORT command successful. 150 ASCII data connection for /bin/ls (129.152.221.238,34344) (0 bytes). dtdbcache_:0 filea files ps_data speckeysd.lock 226 ASCII Transfer complete. 53 bytes received in 0.022 seconds (2.39 Kbytes/s) ftp> get filea 200 PORT command successful. 150 ASCII data connection for filea (129.152.221.238,34331) (0 bytes). 221 Goodbye. |
In this example, the same user kryten uses the mget command to copy a set of files from the /tmp directory to his home directory. Note that kryten can accept or reject individual files in the set.
$ ftp> cd /tmp 250 CWD command successful. ftp> ls files 200 PORT command successful. 150 ASCII data connection for /bin/ls (129.152.221.238,34345) (0 bytes). fileb filec filed remote: files 21 bytes received in 0.015 seconds (1.36 Kbytes/s) ftp> cd files 250 CWD command successful. ftp> mget file* mget fileb? y 200 PORT command successful. 150 ASCII data connection for fileb (129.152.221.238,34347) (0 bytes). 226 ASCII Transfer complete. mget filec? y 200 PORT command successful. 150 ASCII data connection for filec (129.152.221.238,34348) (0 bytes). 226 ASCII Transfer complete. mget filed? y 200 PORT command successful. 150 ASCII data connection for filed (129.152.221.238,34351) (0 bytes). 226 ASCII Transfer complete.200 PORT command successful. ftp> bye 221 Goodbye. |
Change to the source directory on the local system.
The directory from which you type the ftp command is the local working directory, and thus the source directory for this operation.
Establish an ftp connection.
Change to the target directory.
ftp> cd target-directory |
Remember, if your system is using the automounter, the home directory of the remote system's user appears parallel to yours, under /home.
Ensure that you have write permission to the target directory.
ftp> ls -l target-directory |
Set the transfer type to binary.
ftp> binary |
To copy a single file, use the put command.
ftp> put filename |
To copy multiple files at once, use the mput command.
ftp> mput filename [filename ...] |
You can supply a series of individual file names and you can use wildcard characters. The mput command copies each file individually, asking you for confirmation each time.
To close the ftp connection, type bye.
ftp> bye |
In this example, the user kryten opens an ftp connection to the system pluto, and uses the put command to copy a file from his or her system to the /tmp directory on system pluto.
$ cd /tmp ftp pluto Connected to pluto. 220 pluto FTP server (SunOS 5.8) ready. Name (pluto:kryten): kryten 331 Password required for kryten. Password: xxx 230 User kryten logged in. ftp> cd /tmp 250 CWD command successful. ftp> put filef 200 PORT command successful. 150 ASCII data connection for filef (129.152.221.238,34356). 226 Transfer complete. ftp> ls 200 PORT command successful. 150 ASCII data connection for /bin/ls (129.152.221.238,34357) (0 bytes). dtdbcache_:0 filea filef files ps_data speckeysd.lock 226 ASCII Transfer complete. 60 bytes received in 0.058 seconds (1.01 Kbytes/s) ftp> bye 221 Goodbye. |
In this example, the same user kryten uses the mput command to copy a set of files from his or her home directory to pluto's /tmp directory. Note that kryten can accept or reject individual files in the set.
$ cd $HOME/testdir $ ls test1 test2 test3 $ ftp pluto Connected to pluto. 220 pluto FTP server (SunOS 5.8) ready. Name (pluto:kryten): kryten 331 Password required for kryten. Password: xxx 230 User kryten logged in. ftp> cd /tmp 250 CWD command successful. ftp> mput test* mput test1? y 200 PORT command successful. 150 ASCII data connection for test1 (129.152.221.238,34365). 226 Transfer complete. mput test2? y 200 PORT command successful. 150 ASCII data connection for test2 (129.152.221.238,34366). 226 Transfer complete. mput test3? y 200 PORT command successful. 150 ASCII data connection for filef (129.152.221.238,34356). 226 Transfer complete. ftp> bye 221 Goodbye. |
The rcp command copies files or directories between a local and a remote system or between two remote systems. You can use this command from a remote system (after logging in with the rlogin command) or from the local system (without logging in to a remote system).
With rcp, you can perform the following remote copy operations:
Copy a file or directory from your system to a remote system
Copy a file or directory from a remote system to your local system
Copy a file or directory between remote systems from your local system
If you have the automounter running, you can perform these remote operations with the cp command. However, the range of cp is constrained to the virtual file system that is created by the automounter and to operations relative to a user's home directory. Because rcp performs the same operations without these constraints, this section describes only the rcp versions of these tasks.
To copy files or directories between systems, you must have permission to log in and copy files.
Both the cp and rcp commands can overwrite files without warning. Ensure that file names are correct before executing the command.
With the rcp command in the C shell, you can specify source (the file or directory you want to copy) and target (the location into which you will copy the file or directory) with either absolute or abbreviated path names.
|
Absolute Path Names |
Abbreviated Path Names |
---|---|---|
From Local System |
mars:/home/jones/myfile.txt |
~jones/myfile.txt |
After Remote Login |
/home/jones/myfile.txt |
~jones/myfile.txt |
Absolute path names identify files or directories that are mounted on a particular system. In the previous example, the first absolute path name identifies a file (myfile.txt) on the mars system. Abbreviated path names identify files or directories relative to a user's home directory, wherever it might reside. In the previous first example, the abbreviated path name identifies the same file, myfile.txt, but uses “~” symbol to indicate the jones home directory:
~ = mars:/home/jones
The examples on the second line demonstrate the user of absolute and abbreviated path names after a remote login. No difference is evident for the abbreviated path name. However, because the remote login operation mounted the jones home directory onto the local system (parallel to the local user's home directory), the absolute path name no longer requires the system name mars. For more information about how a remote login operation mounts another user's home directory, see What Happens After You Log In Remotely.
The following table provides a sample of absolute and abbreviated path names that are recognized by the C shell. The sample uses the following terminology:
Working directory – The directory from which the rcp command is entered. Can be remote or local.
Current user – The user name under which the rcp command is entered.
Logged in to |
Syntax |
Description |
---|---|---|
Local system |
. |
The local working directory |
|
path/filename |
The path and filename in the local working directory |
|
~ |
The current user's home directory |
|
~/path/filename |
The path and filename beneath the current user's home directory |
|
~user |
The home directory of user |
|
~user/path/filename |
The path and filename beneath the home directory of user |
|
remote-system:path/filename |
The path and filename in the remote working directory |
Remote system |
. |
The remote working directory |
|
filename |
The filename in the remote working directory |
|
path/filename |
The path and filename in the remote working directory |
|
~ |
The current user's home directory |
|
~/path/filename |
The path and filename in the current user's home directory |
|
~user |
The home directory of user |
|
~/user/path/filename |
The path and filename beneath the home directory of user |
|
local-system:path/filename |
The path and filename in the local working directory |
Ensure that you have permission to copy.
You should at least have read permission on the source system and write permission on the target system.
Determine the location of the source and target.
If you don't know the path of the source or target, you can first log in to the remote system with the rlogin command, as described in How to Log In to a Remote System (rlogin). Then, navigate through the remote system until you find the location. You can then perform the next step without logging out.
Copy the file or directory.
$ rcp [-r] source-file|directory target-file|directory |
(No options) Copies a single file from the source to the target.
Copies a directory from the source to the target.
This syntax applies whether you are logged in to the remote system or in to the local system. Only the path name of the file or directory changes, as described in Table 29–4 and as illustrated in the following examples.
You can use the “~” and “.” characters to specify the path portions of the local file or directory names. Note, however, that “~” applies to the current user, not the remote system, and that “.” applies to system you are logged in to. For explanations of these symbols, see Table 29–4.
In this example, rcp is used to copy the file letter.doc from the /home/jones directory of the remote system pluto to the working directory (/home/smith) on the local system, earth:
earth(/home/smith): rcp pluto:/home/jones/letter.doc . |
In this instance, the rcp operation is performed without a remote login. Here, the “.” symbol at the end of the command line refers to the local system, not the remote system.
The target directory is the also local user's home directory, so it can also be specified with the “~” symbol.
In this example, the rcp operation is run after the rlogin command is executed to copy a file from a remote to a local system. Although the flow of the operation is the same as that of the previous example, the paths change to allow for the remote login:
earth(/home/smith): rlogin pluto . . . pluto(/home/jones): rcp letter.doc ~ |
Using the “.” symbol at the end of the command line would be inappropriate in this instance. Because of the remote login, the symbol would simply refer to the remote system; essentially directing rcp to create a duplicate file. The “~” symbol, however, refers to the current user's home directory, even when the login is to a remote system.
In this example, rcp is used to copy the file notice.doc from the home directory (/home/smith) of the local system earth to the /home/jones directory of the remote system, pluto:
earth(/home/smith): rcp notice.doc pluto:/home/jones |
Because no remote file name is provided, the file notice.doc is copied into the /home/jones directory with the same name.
In this instance, the rcp operation from the previous example is repeated, but rcp is entered from a different working directory on the local system (/tmp). Note the use of the “~” symbol to refer to the current user's home directory:
earth(/tmp): rcp ~/notice.doc pluto:/home/jones |
In this example, the rcp operation is run after the rlogin command is executed to copy a local file to a remote directory. Although the flow of the operation is the same as that of the previous example, the paths change to allow for the remote login.
earth(/home/smith): rlogin pluto . . . pluto(/home/jones): rcp ~/notice.doc . |
In this instance, the “~” symbol can be used to denote the current user's home directory, even though it is on the local system. The “.” symbol refers to the working directory on the remote system because the user is logged in to the remote system. Here is an alternative syntax that performs the same operation:
pluto(/home/jones): rcp earth:/home/smith/notice.doc /home/jones |