Your machine is only as secure as the least secure of the 'trusted' hosts listed in this file. If you care about computer security, you should not use this file. Users should be discouraged from using the.rhosts file as well. You are better off using ssh (secure shell). (5) /etc/inetd.conf.
- Using the built-in SSH client in Mac OS X. Mac OS X includes a command-line SSH client as part of the operating system. To use it, goto Finder, and selext Go - Utilities from the top menu. Then look for Terminal. Terminal can be used to get a local terminal window, and also supports SSH connections to remote servers.
- The secure shell, ssh, has a replacement for the r-utilities (rcp, rlogin, rsh) which doesn't suffer from this problem. Unix provides a command called rlogin for easy login to remote machines. Here is a simple example of its use.
1.1. What is Secure Shell?
To quote the README file:
Secure Shell (SSH) is a program to log into another computer over a network, to execute commands in a remote machine, and to move files from one machine to another. It provides strong authentication and secure communications over unsecure channels. It is intended as a replacement for rlogin, rsh, and rcp.
Additionally, SSH provides secure X connections and secure forwarding of arbitrary TCP connections. You can also use SSH as a tool for things like rsyncand secure network backups.
The traditional BSD 'r' - commmands (rsh, rlogin, rcp) are vulnerable to different kinds of attacks. Somebody who has rootaccess to machines on the network, or physical access to the wire, can gain unauthorized access to systems in a variety of ways.It is also possible for such a person to log all the traffic to and from your system, including passwords (which ssh never sends inthe clear).
The X Window System also has a number of severe vulnerabilities. With ssh, you can create secure remote X sessions whichare transparent to the user. As a side effect, using remote X clients with ssh is more convenient for users.
1.2 How widespread is its use?
The most current figures available are over 2 million Secure Shell users in over 60 countries.This is not an accurate amount, but an estimate. It also does not necessarily include thedifferent implementations of Secure Shell for different operating systems.
1.3 What protocols does SSH use?
For the SSH1 protocol, you can find this information in an old IETF draft available here.It is also available with the source distribution.
For the SSH2 protocol, you can find this information in the SSH2 IETF drafts:
- SSH Protocol Architecture: draft-ietf-secsh-architecture-04.txt
- SSH Connection Protocol: draft-ietf-secsh-connect-06.txt
- SSH Transport Layer Protocol: draft-ietf-secsh-transport-06.txt
- SSH Authentication Protocol: draft-ietf-secsh-userauth-06.txt
- Generic Message Exchange Authentication For SSH: draft-ietf-secsh-auth-kbdinteract-00.txt
1.4 What encryption algorithms does SSH use?
SSH uses the following ciphers for encryption:| Cipher | SSH1 | SSH2 |
| DES | yes | no |
| 3DES | yes | yes |
| IDEA | yes | yes |
| Blowfish | yes | yes |
| Twofish | no | yes |
| Arcfour | no | yes |
| Cast128-cbc | no | yes |
| Cipher | SSH1 | SSH2 |
| RSA | yes | yes * |
| DSA | no | yes |
* Note: This is only for the commercial release (Datafellows) of SSH2.
1.5 How does SSH authenticate?
SSH authenticates using one or more of the following:
- Public key (RSA or DSA)
- Password
- Kerberos
- .rhosts or /etc/hosts.equiv
1.6 What does SSH protect against?
Ssh protects against (again, from the README):
- IP spoofing, where a remote host sends out packets which pretend to come from another, trusted host. Ssh even protects against a spoofer on the local network, who can pretend he is your router to the outside.
- IP source routing, where a host can pretend that an IP packet comes from another, trusted host.
- DNS spoofing, where an attacker forges name server records
- Interception of cleartext passwords and other data by intermediate hosts
- Manipulation of data by people in control of intermediate hosts
- Attacks based on listening to X authentication data and spoofed connection to the X11 server
In other words, ssh never trusts the net; somebody hostile who has taken over the network can only force ssh to disconnect, but cannot decrypt or play back the traffic, or hijack the connection.
The above only holds if you actually use encryption. Ssh does have an option to use encryption of type 'none' this is only for debugging purposes, and should not be used.
1.7 What doesn't SSH protect against?
Ssh will not help you with anything that compromises your host's security in some other way. Once an attacker has gained rootaccess to a machine, he can then subvert ssh, too.
If somebody malevolent has access to your home directory, then security is nonexistent. This is very much the case if your homedirectory is exported via NFS.
1.8 What is the difference between SSH1 and SSH2?
Rcp Ssh Download
The difference between SSH1 and SSH2 is they are two entirely differentprotocols. SSH1 and SSH2 encrypt at different parts of the packets, andSSH1 uses server and host keys to authenticate systems where SSH2 only useshost keys. SSH2 is a complete rewrite of the protocol, and it does not usethe same networking implementation that SSH1 does. Also, SSH2 is moresecure.Because of the different protocol implementation, they are not compatible.
1.9 Who maintains SSH?
SSH Communications Security, is the developer of secure shell (SSH) protocoland maintains the releases of SSH1 and SSH2. SSH Communications Security,F-Secure, and Van Dyke all sell their own releases of the application.
For more information on support, see section 8 of this FAQ.
1.10 Can I run SSH legally?
Most likely. It depends on your country's laws for cryptography and which version of SSH that you're using. Check out the information on licensing, cryptography laws, and patents on cryptographic algorithms below.
1.10.1 Licensing
Please direct any licensing concerns to SSH Communications Security.
The following lists the licensing information from the official distribution siteat ftp.cs.hut.fi/pub/ssh.
SSH1: The UNIX version of ssh 1.2.27 may be used freely for non-commercial purposes and may not be sold commercially as a separate product, as part of a bigger product or project, or otherwise used for financial gain without a separate license The definition of 'commercial use' is generally interpreted as using ssh for anything that would generate financial gain, such as logging into a customers system to do administration, or providing ssh as a secure login to your partners or vendors. Seethe COPYING file for more information.
1.10.2 Cryptography laws
In some countries, particularly France, Russia, Iraq, and Pakistan, it may be illegal to use any encryption at all without a specialpermit.
If you are in the United States, you should be aware that, while ssh was written outside the United States using informationpublicly available everywhere, the US Government may consider it a criminal offence to export this software from the US once ithas been imported, including putting it on a ftp site. Contact the Office of Defence Trade Controls if you need more information.
There's a really good link that keeps up to date with the Wassenaar Agreement and thecryptography laws throughout the world. Check out Bert-Jaap Koops Crypto Law Survey.
1.10.3 Patents on Cryptographic algorithms
The algorithms RSA and IDEA, which are used by ssh, are claimed as patented in different countries, including the US. Linkingagainst the RSAREF library, which is possible, may or may not make it legal to use ssh for non-commercial purposes in the US.You may need to obtain licenses for commercial use of IDEA; ssh can be configured without IDEA and works perfectly finewithout it.
For information on software patents in general, see the League for Programming Freedom's homepage at http://lpf.ai.mit.edu/.
1.11 What operating systems does SSH run on?
From the SSH home page:
SSH2 currently runs on the following platforms:
- ix86; NetBSD 1.2, 1.3
- ix86; FreeBSD 2.2.x, 3.0-current
- ix86; Linux 2.0.34
- Sparc; Solaris 2.6, 2.5.1
- PowerPC; AIX 4.1, 4.2.x
- hppa1.1; HP/UX 10.20
- hppa2.0; HP/UX 11.00
- Mips; IRIX 6.2
The non-commercial Unix version of SSH1 works on almost all unix variants, including at least the following:
- 386BSD 0.1; i386
- AIX 3.2.5, 4.1, 4.2; RS6000, PowerPC
- A/UX 3.1.1
- BSD 4.4; several platforms
- BSD/OS 1.1, 2.0.1, 3.0; i486
- BSD/386 1.1; i386
- BSDI 2.1, 3.0; x86 (using gnu make)
- ConvexOS 10.1; Convex
- Digital Unix 4.0, 4.0A, 4.0B; Alpha
- DGUX 5.4R2.10; DGUX
- DolphinOS 3.8
- FreeBSD 1.x, 2.x, 3.0; Pentium
- HPUX 7.x, 9.x, 10.0; HPPA
- IRIX 5.2, 5.3, 6.2, 6.3; SGI Indy
- IRIX 6.0.1; Mips-R8000
- Linux 1.2.x, 2.0.x Slackware 2.x, 3.x, RedHat 2.1, 3.0; i486, Sparc
- Linux 3.0.3, 4.0; Alpha
- Linux/Mach3, Macintosh(PowerPC)
- Linux/m68k (1.2.x, 2.0.x, 2.1.x)
- Mach3; Mips
- Mach3/Lites; i386
- Machten 2.2VM (m68k); Macintosh
- NCR Unix 3.00; NCR S40
- NetBSD 1.0A, 1.1, 1.2, 1.3; Pentium, Sparc, Mac68k, Alpha
- OpenBSD 2.0; x86, mac68k.
- NextSTEP 3.3; 68040
- OSF/1 3.0, 3.2, 3.2; Alpha
- Sequent Dynix/ptx 3.2.0 V2.1.0; i386
- SCO Unix; i386 (client only)
- SINIX 5.42; Mips R4000
- Solaris 2.3, 2.4, 2.5, 2.5.1, 2.6; Sparc, i386
- Sony NEWS-OS 3.3 (BSD 4.3); m68k
- SunOS 4.1.1, 4.1.2, 4.1.3, 4.1.4; Sparc, Sun3
- SysV 4.x; several platforms
- Ultrix 4.1; Mips
- Unicos 8.0.3; Cray C90
There are also non-commercial ports of SSH for SSH1 including PalmOS, Windows, Macintosh, OS/2, BeOS, WindowsCE, Java, and OpenVMS. See section 2 of this FAQ for information on how to SSH.
1.12 . Shouldn't I be using only SSH2?
Because of the licensing restrictions on SSH2, many companies like ISPs are notrunning SSH2. Instead, they are still running SSH1. You should check which version ofSSH you are connecting to before installing a client.
If you are installing a daemon, check to make sure your remote clients are connectingto you with the right version of SSH.
| Table of contents of this chapter || General table of contents | | Beginning of this section |
Rcp Ssh Software
Name
rcp - remote file copy
Synopsis
rcp [-px] file1 file2
rcp [-px] [-r] file ... directory
Description
Rcp copies files between machines. Each file or directory argument is either a remote file name of the form 'rname@rhost:path', or alocal file name (containing no ':' characters, or a '/' before any ':'s).
-p' The -p option causes rcp to attempt to preserve (duplicate) in its copies the modification times and modes of the source files,ignoring the umaskRcp Ssh Example
. By default, the mode and owner of file2 are preserved if it already existed; otherwise the mode of the source file modifiedby the umask(2) on the destination host is used.If path is not a full path name, it is interpreted relative to the login directory of the specified user ruser on rhost, or yourcurrent user name if no other remote user name is specified. A path on a remote host may be quoted (using , ', or ') so that the metacharacters areinterpreted remotely.
Rcp does not prompt for passwords; it performs remote execution via rsh(1), and requires the same authorization.
Rcp handles third party copies, where neither source nor target files are on the current machine.
See Also
cp(1), ftp(1), rsh(1), rlogin(1)
History
The rcp command appeared in 4.2BSD.
Bugs
Doesn't detect all cases where the target of a copy might be a file in cases where only a directory should be legal.
Is confused by any output generated by commands in a .login, .profile, or .cshrc file on the remote host.
The destination user and hostname may have to be specified as 'rhost.rname' when the destination machine is running the 4.2BSD version of rcp.
Linux NetKit (0.17) August 15, 1999 Linux NetKit (0.17)
Rcp Ssh List
Referenced By
ncftp(1),ncftpget(1),ncftpls(1),ncftpput(1),pdcp(1),rfcp(1),rfdir(1),scp(1),star(1),v4rcp(1)