Unit 3. Using TCP/IP Commands
What This Unit Is About
This unit describes selected TCP/IP for common network activities.
What You Should Be Able To Do
After completing this unit, students should be able to:
•Log into remote hosts
•Transfer files between systems
•Execute commands on remote systems
•Identify the files used for user authentication
How You Will Check Your Progress
Accountability:
•Exercises
•Checkpoint questions
Basic TCP/IP User Functions
ARPNET BERKLEY
file transfer / ftp tftp / rcpremote
command
execution / rexec / rsh
remote login / telnet/tn / rlogin
OTHER
Finger rwho talk
Figure 3-2. Basic TCP/IP User Functions
Notes:
ARPANET commands were designed to work on the Internet consisting of heterogeneous, multi-vendor machines.
Berkeley commands were designed to work on UNIX-based machines.
$HOME/.netrc File
$ cat /home/team02/.netrc
machine sys2 login team02 password dalvm3
macdef budget
type binary
cd /weekly/update
put monthly
macdef inventory type ascii get widget /wooden
machine sys4 login team03 password p4ccf22 macdef init
put filel
get file2
quit
Figure 3-3. $HOME/.netrc File
Notes:
A SHOME/.netrc file in the local user's home directory permits automatic login and can contain macros that will automatically be run when called. You can have multiple entries in this file allowing you to execute on different hosts. You should have only one entry for each foreign host.
.netrc must be a hidden file in the user's home directory and must be owned by the user executing the command or by root. As the .netrc file can contain a password, the permissions on .netrc must be set to 600 (read and write by owner only); otherwise automatic login will fail.
The machine, login, and password line may be typed horizontally or vertically in the file.
Up to 16 macros containing, at most, 4096 characters for all macros can be defined in one .netrc file. A special macdef named init is always executed upon successful login to the specified server. All other macdefs must be called by its name from the ftp> prompt by putting a $ in front of the macdef name.
It is required that macdefs be followed by a blank line including the last macdef in the file.
If ftp is invoked with the -n flag the .netrc will not be read and the user will be required to provide a userid and password. This provides a way to bypass the init macdef or automatic login.
/etc/ftpusers File
• File created by root on the server (remote) machine that denies access to certain users from other hosts from using ftp
sys1 -Client
sys2-Server
/etc/ftpusers /etc/passwd
$ whoami
team01 $ftpsys2
User team01 access denied
team01
team01:!:250:1 ::/home/team01/usr/bin/ksh
Figure 3-4. /etc/ftpusers File
Notes:
User names listed in the /etc/ftpusers file on the server must also appear in the server's /etc/passwd file.
/etc/ftpusers is a list of client users who do not have permission to ftp into the server's system. The ftpd daemon on the server does not allow access to the users names listed in this file.
/etc/ftpusers can be built with vi, through smit ftpusers or by using the ruser command.
Instructor Notes:
Purpose — Discuss the purpose of the /etc/ftpusers file.
Details — There may be some users on the network that a server would like to deny ftp privileges to either permanently or temporarily. In order to do this the root user on that server would create a file called /etc/ftpusers and simply list the user names of those on the network that should be denied access to the server's ftpd daemon. In our example, team01 from sysl wants to ftp to the server, sys2. The server does not want team01 to have ftp privileges and therefore puts team01's name into its /etc/ftpusers file. The names in the server's /etc/ftpusers file must also appear in the server's /etc/passwd file. When team01 tries to ftp to sys2, he will get the message that he has been denied access.
Additional Information — The SMIT menu under the Remote Access menu of Server Network Services allows you to List/Add/Delete users from the /etc/ftpusers file. This uses the ruser command
#ruser -s-FLists all restricted users
#ruser -a -f userAdds a restricted user
#ruser -d -f userDeletes a restricted user
#ruser -X -FDeletes all restricted users
Transition Statement —ftp is commonly used to get information from a public facility such as a University. The user name is usually anonymous. Let's see how a system can be set up for public access as an anonymous ftp server.
Anonymous ftp Directory Tree
•Allows users without passwords ftp access to a special ftp directory structure on the server
•Set up with script /usr/samples/tcpip/anon.ftp
Figure 3-5. Anonymous ftp Directory Tree
Notes:
The above ftp directory structure is created automatically by executing a shell script named /usr/samples/tcpip/anon.ftp.
Along with the anonymous ftp directory tree structure, two user accounts are created in the /etc/passwd file for users ftp and anonymou. The two user names do not require a password in order to gain access to the public domain directory /home/ftp/pub. Remember, login names can be 1-8 characters. The "s" is dropped.
/home/ftp is owned by root and has permissions of 555.
/home/ftp/bin is owned by root and must contain the Is command. The Is command has permissions set to 111.
/home/ftp/pub is owned by root with permissions of 777. This is where system administrators make public utility programs available to everyone.
rexec Command
sys1> rexec sys2 date
Name: (sys2:team02):
Password (sys2:team02)
Tue Aug 4 11:14:21 CDT2006
sys1> cat /home/team02/.netrc machine sys2 login team02 password yyyy
machine sys3 login teamOS password yyyy
sys1> rexec sys2 date
Tue Feb 4 11:23:16 CDT 2007
sys1>
Figure 3-6. rexec Command
Notes:
The rexec command executes a command on the specified server machine. The host parameter specifies the name of the host where the command is to be executed. The command parameter specifies the command, including any flags or parameters, to be executed on the server host.
The rexec command provides an automatic login feature by checking for a SHOME/.netrc file that contains the user name and password to use at the server host. If such an entry is not found, rexec prompts for a valid user name and password for the server host.
The rexec command does not recognize a macdef entry in the .netrc file. If a macdef entry exists, the rexec command does not fail, but the user will get an error message about unknown options.
rexec cannot handle commands that use a full screen such as vi or graphical applications.
Authentication for ARPA Commands
Figure 3-7. Authentication for ARPA Commands
Notes:
rcp Command
sys1> whoami team02
sys1> rcp filea sys2:fileb
sys1> rcp filea team04@sys2:fi!eb sys1> rcp -p -r sys2:dir sys4:dir
Figure 3-8. rcp Command
Notes:
The rcp command is used to copy one or more files between a client host and a server host.
When copying files to or from a server host, any server file or directory name must be prefixed by the server host name and a colon. Client file and directory names do not need to have a host specified.
-p will preserve the modification times and modes of the source file.
-r recursively copies, for directories only, each file and subdirectory in the source directory into the destination directory.
If the user name where the file is to be copied to or from is different from the user name issuing the command, the server user name precedes the server host name and is separated from it by an @ sign.
rsh Command
sys1>whoami team02
sys1> rsh sys2 date
sys1> rsh sys2 -l team04 date sys1> rsh sys2
rlogin sys2
Figure 3-9. rsh Command
Notes:
rsh command executes the specified command on the server host.
If you do not want to execute a command on the server as your logged in client user name, the -I is used followed by another user name.
rsh executed without a command argument acts as an rlogin and logs the user in.
rlogin Command
sys1> whoami team02
sys1> rsh sys2 date
sys1> rsh sys2 -I team04 date
Figure 3-10. rlogin Command
Notes:
The rlogin command is served by the rlogind daemon on the server. The rlogin command performs a remote login on behalf of the user. If the user wants to login using a user name other than the one he/she is currently logged in as, the -I option is used along with the new user name.
A client user name that is not properly authorized will be prompted for a login and password. Therefore, if a user does have a valid user name and password in the server's /etc/passwd file, they will be able to login when prompted.
To close the rlogin session, type logout or exit.
/etc/hosts.equiv File
Defines which client host's users are permitted to execute commands on the server host without supplying a password
svs1svs2
/etc/passwd sys1 > whoami
Figure 3-11. /etc/hosts.equiv File
Notes:
The format of the /etc/hosts.equiv file is a simple list of host names. A host name by itself authorizes any user on that host to run as the same user on this host. If a user name follows the host name, only that combination of user and host name is allowed. Note that this will allow the specified user/host to run as any non-root user on the server, which is potentially a very significant security issue.
The daemons that check this file are Ipd, rlogind, and rshd.
In this example, the file filea will be remotely copied to /home/team02 on the server, sys2, and called fileb.
It is possible, as shown in the chart, to deny access, by preceding a host or user name with a "-". This is a way to deny a user or host explicitly. If a host/user matches such an entry, then the remaining entries in /etc/hosts.equiv are not checked. Nor is $HOME/.rhosts. See the manual page for /etc/hosts.equiv for more details.
If the user name was root, this file would not be checked. Authentication for root would be passed to the SHOME/.rhosts file.
$HOME/.rhosts
Defines a list of client users who are not required to supply a login password when they execute rcp, rlogin and rsh using a server user account
svs1sys2
sys1>whoami/etc/passwd
team02
sys1> rcp filea team04@sys2:file
Figure 3-12. $HOME/.rhosts
Notes:
If an /etc/hosts.equiv file does not exist on sys2, or does exist but does not authorize the user on the remote system, then the SHOME/.rhosts file will be looked at for user authentication. In particular, sys2 will look at the .rhosts file in the home directory of the user under whom the command is to run.
In the above example, team02 wants to remote copy filea to team04 s home directory on sys2 and rename it fileb. The user name team04 is checked. Even though team04 has an entry in /etc/passwd, the command is not authorized since the entry for sys1 in /etc/hosts.equiv authorized users on sys1 only to run as the same ID on sys2. Instead, the rshd on sys2 will look for an entry in the .rhosts in team04's home directory. team04 has given team02 on sys1 permission to perform remote copies to its directory.
The SHOME/.rhosts is a hidden file in a server host user's directory.
The syntax of this file is < host name> < user name>.
rsh, rcp and Robin Verification
Figure 3-13. rsh, rcp, and login Verification
Notes:
In order to use the rsh, rcp, or rlogin commands successfully, a user must qualify on the server host. A user qualifies if both of the following are true:
•Client user name exists in the server host's /etc/passwd file.
•On the server, either /etc/hosts.equiv authorizes the client name or the SHOME/.rhosts does so.
Note that /etc/hosts.equiv may explicitly deny a host or a user, in which case SHOME/.rhosts is not checked.
Which Commands Work?
Figure 3-14. Which Commands Work?
Notes:
From the commands above, determine if the command will run successfully at the server system:
1.
2.
3„
4.
Making TCP/IP More Secure
The Berkeley commands (rsh, rcp, rlogin) and the tftp command allow access to a system without a password. This could introduce a security loophole into an otherwise secure system.
securetcpip will disable the following facilities:
•tftpd, rlogind, rshd daemons
•tftp, utftp, rlogin, rsh, rcp commands
• Ability to specify a password in .netrc files
Figure 3-15. Making TCP/IP More Secure
Notes:
A number of TCP/IP services could compromise the security of a system without careful implementation. These include the Berkeley commands and tftp which allows access without passwords and the ftp/exec commands which can have passwords supplied by the .netrc file.
The securetcpip script is in the directory /usr/lpp/bos.net/inst_root/etc.
Instructor Notes:
Purpose — Make students aware of the securetcpip command.
Details — A system which is being configured to meet the TCSEC Class C2 level of security should disable these facilities with the securetcpip command, securetcpip performs the following operations:
•Changes the permissions to 0000 and updates the trusted computing base for the following programs: tftpd, rlogind, rshd, tftp, utftp, rlogin, rsh, rcp.
•Updates the /etc/security/sysck.cfg file to disallow ftp and rexec from using passwords stored in .netrc files. It cannot prevent users from typing clear text passwords into a text file, but will generate an error if such security breaches are detected.
The disadvantage with this mechanism is that Xstations and diskless workstations use the TFTP protocol (and therefore the tftpd daemon) when booting from a server. They will no longer boot.
To cure this problem restore access to tftpd using chmod 555 /usr/sbin/tftpd and create a /etc/tftpaccess.ctl file as follows:
#/etc/tftpaccess.ctl
###################################################################
#The following example, when uncommented, only
#allow access to the Xstations boot files. ################################################################### allow:/usr/lpp/x_st_mgr/bin/bootfile
allow:/usr/lpp/x_st_mgr/bin/bootfile1 allow:/usr/lpp/x_st_mgr/bin/bootfi1e2 ###################################################################
#The following example, when uncomrnented, only
#allows access to the DisklessClient boot files. allow:/tftpboot
A sample of this file can be found in the /usr/samples/tcpip directory.
Transition Statement — There are some other network commands that are useful to know. Let's take a look at what they are starting with the finger command.
Showing Remote Hosts/Users
sys1$ ruptime
sys6 up4:17,
sys4 down0:15
sys2 down0:45
sys5 up0:05,
sys1$ rwho
0 users, load 0.00, 0.00, 0.00
2 users, load 0.15, 0.30, 0.15
user3sys1:console
rootsys5:pts0
user1sys3:pts1
user2sys5:pts2
Feb 23 15:05 Feb 23 15:07 Feb 23 15:22Feb 23 15:21
22 20 05 06
Note: the local and remote hosts must be running rwhod
Figure 3-17. Showing Remote Hosts/Users
Notes:
ruptime displays the status of each host that is on the local network and running the rwhod daemon. The status lines are stored by host name and are provided in packets broadcast once every three minutes by each network host running the rwhod daemon.
rwho displays the user name, host name, and start date and time of each session of everyone on the local network who is currently logged in to a host running the rwho daemon. If the user has not typed anything for at least three minutes, the rwho command reports the idle time in minutes.
Talk With Another User
sys1$ talk fred@sys2
(user fred will receive the following message:)
Message from TalkDaemon@sys1 at 15:16... talk: connection requested byjohn@sys1. talk: respond with: talk john@sys1
(to accept the invitation, fred enters:)
sys2$ talk john@sys1
Figure 3-18. Talk With Another User
Notes:
talk allows two users on the same host or different hosts to have an interactive conversation, talk opens both a send and receive window on each user's display.