SERVICIOS DE

INTERNET
M.Sc. Julio Santisteban Pablo
r - Utilities
SSH
r - UTILITIES
4
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
5
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 form
hostname:path or username@hostname:path
6
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
7
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
8
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
9
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.
10

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.

Did I mention passwords?
11

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.
Did I mention passwords?
12
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
Local login
terminal
driver
kernel
user at a
terminal
login
shell

TELNET Client and Server
TELNET/rlogin
client
terminal
driver
TCP/IP
kernel
user at a
terminal
TELNET/rlogin
server
TCP/IP
pseudo-
terminal
driver
kernel
Fork shell
Sed ui
Only ONE TCP connection !!!

Network Virtual Terminal
2007
rLOGIN Protocol Start up
Specified in RFC 1282
Use a single TCP connection
The rlogin process uses the TCP port 513
Protocol between client and server after connection is set up
Client writes 4 strings to server
a byte of 0
login name of user on client, terminated by a byte of 0
login name of user on server, terminated by a byte of 0
name of users terminal type, a slash, terminal speed, terminated by a byte of
0
(\0John\0John\0ibmpc3/9600\0)
Server responds with a byte of 0
Optionally server can ask user for a password
Server sends a request to client asking for terminals window size
2007
Interactive input
Client
keystroke
Server
Server
display
echo
2007
Flow control
Done by client
User type Control-S, Control-Q, asking
SERVER to stop sending data, or start
sending data
Control-S stop writing to the network
Control-Q start writing to the network

Control by Server
2007
Server to Client Commands
Need to mark command bytes because only one TCP connection is
used
Use TCPs urgent mode to mark command bytes
To send a command to client, server enters urgent mode and
makes command byte the last byte of urgent data
Four command bytes
0x02: client flushes output
0x10: client stops performing flow control
0x20: client resumes flow control
0x80: client sends current window size to server immediately and
notifies server if changing window size
2007
Client to Server Command
When client receives command 0x80 from
server, client needs to send window size to
server
This command needs to be marked
2 bytes of 0xff
2 flag bytes of ASCII char s
4 16-bit values: #rows, #chars per row, #pixels in X
direction, #pixels in Y direction
2007
rLOGIN Client Escape
Talk to client directly instead of sending the input
to server
Start with a tilde ~
Followed by one of four characters
.: terminate client
EOF (Ctrl-D): terminate client
Job control suspend char (Ctrl-Z): suspend client
Job control delayed suspend char (Ctrl-Y): suspend
only client input but keep server output
William Nelson Joy (born November 8,
1954), commonly known as Bill Joy, is an
American computer scientist.
As a UC Berkeley graduate student, Joy worked for Fabry's
Computer Systems Research Group CSRG in managing the
BSD support and rollout where many claim he was largely
responsible for managing the authorship of BSD UNIX, from
which sprang many modern forms of UNIX, including
FreeBSD, NetBSD, and OpenBSD. Apple Inc. has based
much of the Mac OS X kernel and OS Services on the BSD
technology.

Some of his most notable contributions were the vi editor,
NFS, and csh.
Bill Joy
SSH
24
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 Ylnen, 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
25
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
26
SSH Architecture
27
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

In 1999, developers wanting a free software version to be available
went back to the older 1.2.12 release of the original SSH program,
which was the last released under an open source license. Bjrn
Grnvall's OSSH was subsequently developed from this codebase.
Shortly thereafter, OpenBSD developers forked Grnvall's code and
did extensive work on it, creating OpenSSH, which shipped with the
2.6 release of OpenBSD. From this version, a "portability" branch
was formed to port OpenSSH to other operating systems.

It is estimated that, as of 2000, there were 2,000,000 users of
SSH.[8]

As of 2005, OpenSSH is the single most popular SSH
implementation, coming by default in a large number of operating
systems. OSSH meanwhile has become obsolete.
OpenSSH
29

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
SSH-2 Specifics
Authentication, Encryption, and Integrity
31
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
32
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

33
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

34
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
35
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
36
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
keys
providing 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
37

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
Key-Based Cryptography
38
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
39

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

Private Key Cryptography
40
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
41

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
Public Key Cryptography
42
Public-key Authentication
43
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
44
How the SSH Agent Works
SSH Login Annoyances
SSH is great, but its annoying to have to type
your password/passphrase every time you log
in, run a remote command or copy some files
across the network.
SSH doesnt allow ~/.rhosts functionality for
security reasons.
Passphrase-less keys are quite insecure and
not recommended practice.
Can users log in securely without typing their
password all the time?
The SSH Agent
The agent solves these problems
Only available for key-based login, however
You authenticate once to the agent at the
beginning of your session
The agent holds your SSH private keys in
memory and provides them to ssh and scp
commands when necessary
You dont have to unlock them each time
Agent goes away when you log out so unlocked
keys are never stored on disk
Preparing To Use The Agent
First, get key-based login working
Distribute your public key to all non-CUE hosts
you need to log into
CUE hosts all share your home directory so the
key is already there
scp p ~/.ssh/authorized_keys
remotehost:/home/<username>/.ssh
Use normal SSH and make sure youre
prompted for a passphrase and not a password
Using the Agent Interactively
Run ssh-agent c to start the agent
Will print some output that you need to type into
the same shell or cut-n-paste


Save yourself some typing and do it the clever way

Now other commands in the same window will be
able to use the agent
jlabs2:/home/jdoe> ssh-agent -c
setenv SSH2_AUTH_SOCK /tmp/ssh-jdoe/ssh2-8765-agent;
setenv SSH2_AGENT_PID 8766;
echo Agent pid 8766;
jlabl1:/home/jdoe> eval `ssh-agent c`
Agent pid 8766
Logging In To The Agent
Use the ssh-add command to authenticate
yourself to the agent
After you do this, you wont need to log in with
SSH or scp!
jlabl1:/home/jdoe> ssh-add
Enter passphrase for /home/jdoe/.ssh/id_dsa: <PASSPHRASE>
Identity added: /home/jdoe/.ssh/id_dsa
jlabl1:/home/jdoe> ssh-add -l
2048 6e:ef:22:a4:83:a1:98:39:22:44:57:21:2c:ee:d3:33 /home/jdoe/.ssh/id_dsa (DSA)
jlabl1:/home/jdoe> ssh jlabs1
[login proceeds normally without a password]
jlabs1:/home/jdoe>
Uses
For login to a shell on a remote host (replacing Telnet and rlogin)
For executing a single command on a remote host (replacing rsh)
For copying files from a local server to a remote host. See SCP, as an
alternative for rcp
In combination with SFTP, as a secure alternative to FTP file transfer
In combination with rsync to backup, copy and mirror files efficiently and
securely
For forwarding or tunneling a port (not to be confused with a VPN which
routes packets between different networks or bridges two broadcast
domains into one.).
For using as a full-fledged encrypted VPN. Note that only OpenSSH
server and client supports this feature.
For forwarding X from a remote host (possible through multiple
intermediate hosts)
For browsing the web through an encrypted proxy connection with SSH
clients that support the SOCKS protocol.
For securely mounting a directory on a remote server as a filesystem on
a local computer using SSHFS.
Uses
Port forwarding
ssh L localport:tohost:toport remotehost
Tunnels localhost:localport to remotehost's resolution of
tohost:toport
Can use to punch through firewalls
Example: access from classroom to Mercury rupdate
-D for SOCKS forwarding and R for remote-to-local
forwarding
VPNs
Can run PPP connection over SSH
A bit convoluted, but it works
Uses