300 likes | 528 Views
Remote Control in Unix. The "r" Utilities. Once upon a time, people thought they had a need to be able to "easily" access other machines without going through a normal login Out of this desire, the "r-commands" were born rcp – remote file copy rlogin – remote login
E N D
The "r" Utilities • Once upon a time, people thought they had a need to be able to "easily" access other machines without going through a normal login • Out of this desire, the "r-commands" were born • rcp – remote file copy • rlogin – remote login • rsh, remsh, remote_shell – variants of remote shell • rwho – who is logged on other systems on your net
rcp – Remote File Copy • rcp allows you to copy files between systems • Syntax: rcp [-p] filename1 filename2 or rcp [-pr] filename… directory • p – try to give each copy the same modification times, access times, and access rights as the original file • r – copy each subtree rooted at filename; the destination must be a directory • filename – either a local file (containing no : or \ characters) or a remote filename of the formhostname:path or username@hostname:path
rlogin – Remote Login • Allows you to establish a remote login from your terminal to another host • Syntax: rlogin [-8EL] –ec] [-l username] hostname • 8 – pass 8 bit data across the net instead of 7-bit data • ec – specify a different escape character (c) for the line used to disconnect from the remote host • E – stop any character from being recognized as an escape • l username – login as a different username than your current local login • hostname – hostname of the remote machine
rsh, remsh, remote_shell – Remote Shell • rsh (or it's variants) let you connect to a remote machine and execute a specified command • Syntax: rsh [-n] [-l username] hostname command • n – redirect the input of rsh to /dev/null • l username – username for login on remote machine if different from login name on local machine • hostname – hostname of remote system • command – command to execute of remote system Note: interactive commands, such as vi, cannot be run using rsh; use rlogin instead
rwho – Remote who • Display a list of users logged into all systems in your network • Syntax: rwho [-a] • a – Report all users regardless of whether they have been idle for more than an hour • rwho does not work through gateways • The directory /var/spool/rwh must exist on the machine you run rwho from • For large networks, the network bandwidth costs of rwho may well be prohibitive
Did I mention passwords? • The /etc/hosts.equiv and .rhosts files provide the "remote authentication" database for rlogin, rsh, and rcp • The files specify remote hosts and users that are considered "trusted" • Trusted users are allowed to access the local system without supplying a password • The /etc/hosts.equiv file applies to the entire system, while individual users can maintain their own .rhosts files in their home directories • These files bypass the standard password-based user authentication mechanism.
The remote authentication procedure determines whether a user from a remote host should be allowed to access the local system with the identity of a local user • This procedure first checks the /etc/hosts.equiv file and then checks the .rhosts file in the home directory of the local user who is requesting access • Entries in these files can be of two forms. • Positive entries allow access, while negative entries deny access.
The authentication succeeds when a matching positive entry is found • The procedure fails when the first matching negative entry is found, or if no matching entries are found in either file • The order of entries is important • If the files contain both positive and negative entries, the entry that appears first will prevail. • The rsh and rcp programs fail if the remote authentication procedure fails • The rlogin program falls back to the standard password-based login procedure if the remote authentication fails.
Notes from the man page • When a system is listed in hosts.equiv, its security must be as good as local security. One insecure system listed in hosts.equiv can compromise the security of the entire system. • Because of the security issues, many systems no longer allow rcp, rlogin, or rsh • Instead, use something like ssh, the secure shell
SSH – The Secure Shell Protocol • SSH provides secure replacements for rsh, rlogin, rcp, ftp, and telnet, all of which transmit data over the network as clear text • The SSH protocol was developed in 1995 to address the various security issues associated with the "r-commands" • Developed by Tatu Ylönen, a researcher at the Helsinki University of Technology • Motivated by a password-sniffing attack on the university network Note: Following figures are from "SSH, The Secure Shell" by Daniel J. Barrett and Richard E. Silverman
SSH Architecture • SSH protocol is based on a client/server architecture • A user who wants to connect to a remote host will execute the ssh command (the client) on his local machine • It will connect to the remote computer's ssh daemon (the server) • There are two primary versions of the SSH protocol • SSH-1 • SSH-2
SSH-2 Specifics • SSH-2 is a complete rewrite of SSH-2 that improves both security and performance • It also supports two forms of encryption • RSA (Rivest-Shamir-Adleman), patented until September 21, 2000 • DSA (Digital Signature Algorithm) non-patented • SSH-2 uses a three layer architecture • Transport layer • Usually runs over TCP/IP • Responsible for data encryption, host authentication, and data integrity by including a message authentication code (MAC) in each data packet
The user authentication layer assumes the transport layer is providing data encryption and integrity • Responsible for actually logging a user onto the remote server, authenticating the user, and requesting specific services from the server • The connection layer assumes that the two lower layers are providing security and user authentication • Used to open channels for psuedo terminals, port forwarding, and X11 forwarding • This allows you to run applications such a xterms and have them communicate securely
Using SSH • Although SSH is a protocol, there are several utilities provided with most SSH implementations • ssh – replacement for rsh, basically a secure telnet • scp – secure file copy • slogin – secure replacement for rlogin, generally simply a link to ssh • sftp – a secure version of ftp • There are also several utilities for managing your encryption keys
ssh • Syntax: ssh [-l username] remotehost • l username – username you want to use on the remote machine, ssh defaults to your login id on the local machine • remotehost – name of the remote machine if on the local network or fully qualified internet name if on a remote network • neptune • neptune.dcccd.edu • You can also provide the username with the remotehost name • ssh frazer@neptune.dcccd.edu
scp • Syntax: scp source_file destination_file • source_file and destination_file can either or both use the full user and system name like in ssh • scp klh@dizzy.uucc.com:my_file my_local_file
sftp • Syntax is similar to ftp • Has several advantages • It's secure • Multiple file commands can be performed in one sftp session; scp requires a separate session for each action • It has command line editing, similar to the emacs mode of ksh • Regular expression matching for filenames • However, it does not have separate ASCII and binary transfer modes so if you move text files between Unix and Windows, you will have to handle line ending conversion
User Authentication • All of the previous commands will ask you to supply the password for the remote system • Passwords have several problems • Good passwords are hard to remember • If a password is sent across the net, even encrypted, it can still be captured if the remote host has been compromised • SSH has the option to use public-key authentication instead
Key-Based Cryptography • In the world of cryptography, a key is a computer-generated numeric value that cryptographic algorithms (such as RSA and DSA) use for the purpose of encrypting or decrypting data • The key can be of various lengths, with longer keysproviding more secure encryption • You may have heard people referring to 512-bit or 1024-bit encryption, they were talking about the length of the key
Secure protocols such as SSH use these keys to authenticate users and hosts. • Authentication is the act of insuring that a given host or user is who they say they are, and not an imposter • There are two types of keys -- private and public • There are also two different methods for using those keys to authenticate users and hosts • Private key cryptography • Public key cryptography
Private Key Cryptography • Private key cryptography (aka symmetric cryptography, because one key is used to both encrypt and decrypt messages) was the first popular key-based cryptographic method • It involved generating an encryption key and then sharing that key only with people that you trust • Having your private key allowed people to encrypt messages to you and decrypt messages or data from you
The problem was if someone got hold of your private key (which had to be passed around a bit if anyone was going to be able to encrypt or decrypt messages to or from you), or if you lost your private key, anyone who gained access to that key could then read all of your transmissions
Public Key Cryptography • Public key encryption (aka asymmetric cryptography, because different keys of different lengths are used to encrypt and decrypt messages) took a different approach to the problem • With public key cryptography, there are two keys • A private key that only you use • A public key that anyone can have access to • The private and public keys are both generated at the same time, using the same algorithm
If someone wants to send you a message, they encrypt the message by using your public key • Only you are able to decrypt it with your private key • Private keys are never exchanged or sent over the network • This also makes it possible to identify yourself by signing your e-mail with a digital certificate or signature that can only be decrypted with your public key
Passphrases • All of the ssh client commands ask for a passphrase in order to decrypt your private key • If you transfer multiple files using scp, you will have to enter your passphrase each time L • Wouldn't it be nice if your machine would remember your passphrase for you? • SSH has a concept called agents • Agents keep your private keys in memory and provide authentication services to ssh clients • By using agents, you only have to provide your passphrase once for each login