Ssh

 SSH, the Secure Shell, is a popular, powerful, software-based approach to
network security.* Whenever data is sent by a computer to the network, SSH
automatically encrypts it. When the data reaches its intended recipient, SSH
automatically decrypts (unscrambles) it. The result is transparent encryption:
users can work normally, unaware that their communications are safely
encrypted on the network. In addition, SSH uses modern, secure encryption
algorithms and is effective enough to be found within mission-critical
applications at major corporations

 An SSH server program, typically installed and run by a system administrator,
accepts or rejects incoming connections to its host computer. Users then run
SSH client programs, typically on other computers, to make requests of the
SSH server, such as “Please log me in,” “Please send me a file,” or “Please
execute this command.” All communications between clients and servers are
securely encrypted and protected from modification.

The SSH Protocol
 SSH is a protocol, not a product. It is a specification of how to conduct secure communication
over a network.*
 Authentication Reliably determines someone’s identity. If you try to log into an account on a
remote computer, SSH asks for digital proof of your identity. If you pass the test, you may log in;
otherwise SSH rejects the connection. Encryption Scrambles data so it is unintelligible except to the
intended recipients. This protects your data as it passes over the network. Integrity Guarantees the
data traveling over the network arrives unaltered. If a third party captures and modifies your data in
transit, SSH detects this fact.

Protocols, Products, Clients, and
Confusion
 SSH-based products—i.e., products that implement the SSH protocol—exist for
many flavors of Unix, Windows, Macintosh, and other operating systems.
 The first SSH product, created by Tatu Ylönen for Unix, was simply called
“SSH.” This causes confusion because SSH is also the name of the protocol.
Some people call Ylönen’s software “Unix SSH,” but other Unix-based
implementations are now available so the name is unsatisfactory

 Protocols are denoted with dashes: SSH-1, SSH-2.
 Products are denoted in uppercase, without dashes: SSH1, SSH2.
 Client programs are in lowercase: ssh, ssh1, ssh2, etc.

Overview of SSH Features
 SSH, such as secure remote logins, secure file copying, and secure invocation of
remote commands. We use SSH1 in the examples, but all are possible with
OpenSSH, SSH2, and F-Secure SSH.
 Secure Remote Logins
Suppose you have accounts on several computers on the Internet. Typically, you
connect from a home PC to your ISP, and then use a telnet program to log into
your accounts on other computers. Unfortunately, telnet transmits your username
and password in plaintext over the Internet, where a malicious third party can
intercept them.* Additionally, your entire telnet session is readable by a network
snooper.

Secure File Transfer
 Using SSH, the file can be transferred securely between machines with a
single secure copy command. If the file were named myfile, the command
executed on firstaccount.com might be:
 $ scp myfile metoo@secondaccount.com: When transmitted by scp, the file is
automatically encrypted as it leaves firstaccount.com and decrypted as it
arrives on secondaccount.com.

Keys and Agents
SSH can authenticate you to all your computer accounts securely without requiring
you to memorize many passwords or enter them repeatedly. It works like this:
1. In advance (and only once), place special files called public key files into your
remote computer accounts. These enable your SSH clients (ssh, scp) to access
your remote accounts.
2. On your local machine, invoke the ssh-agent program, which runs in the
background.
3. Choose the key (or keys) you will need during your login session.
4. Load the keys into the agent with the ssh-add program. This requires knowledge
of each key’s secret passphrase.

Access Control
 Suppose you want to permit another person to use your computer account,
but only for certain purposes. For example, while you’re out of town you’d
like your secretary to read your email but not to do anything else in your
account. With SSH, you can give your secretary access to your account
without revealing or changing your password, and with only the ability to run
the email program. No system-administrator privileges are required to set up
this restricted access.

Port Forwarding
 SSH can increase the security of other TCP/IP-based applications such as telnet, ftp, and the X
Window System. A technique called port forwarding or tunneling reroutes a TCP/IP connection to pass
through an SSH connection, transparently encrypting it end-to-end. Port forwarding can also pass such
applications through network firewalls that otherwise prevent their use.
 Suppose you are logged into a machine away from work and want to access the internal news server at
your office, news.yoyodyne.com. The Yoyodyne network is connected to the Internet, but a network
firewall blocks incoming connections to most ports, particularly port 119, the news port. The firewall
does allow incoming SSH connections, however, since the SSH protocol is secure enough that even
 Yoyodyne’s rabidly paranoid system administrators trust it. SSH can establish a secure tunnel on an
arbitrary local TCP port—say, port 3002—to the news port on the remote host. The command might
look a bit cryptic at this early stage, but here it is:
 $ ssh -L 3002:localhost:119 news.yoyodyne.com

Kerberos
 Kerberos is a secure authentication system for environments where networks
may be monitored, and computers aren’t under central control
 Kerberos and SSH solve similar problems but are quite different in scope. SSH
is lightweight and easily deployed, designed to work on existing systems with
minimal changes.

IPSEC
Internet Protocol Security (IPSEC) is an evolving Internet standard for network security. IPSEC can
securely connect a single machine to a remote network through an intervening untrusted network
(such as the Internet), or it can connect entire networks (this is the idea of the “Virtual Private
Network,” or VPN).
SRP provides strong two-party mutual authentication, with the client needing only to remember a
short password which need not be so strongly random. With traditional password schemes, the server
maintains a sensitive database that must be protected, such as the passwords themselves, or hashed
versions of them (as in the Unix /etc/passwd and /etc/shadow files).

Firewalls
 A firewall is a hardware device or software program that prevents certain data from entering or
exiting a network. For example, a firewall placed between a web site and the Internet might permit
only HTTP and HTTPS traffic to reach the site. As another example, a firewall can reject all TCP/IP
packets unless they originate from a designated set of network addresses. Firewalls aren’t a
replacement for SSH or other authentication and encryption approaches, but they do address similar
problems. The techniques may be used together.

Basic Client Use
 SSH
Logging into a remote computer over a secure connection
Transferring files between computers over a secure connection
Remote Terminal Sessions with ssh
 Suppose your remote username on shell.isp.com is “pat”. To connect to your remote account from your
friend’s account on local.university.edu, you type:
 $ ssh -l pat shell.isp.com
 pat's password: ******
 Last login: Mon May 24 19:32:51 1999 from quondam.nefertiti.org
 You have new mail.
 shell.isp.com>

 On first contact, SSH establishes a secure channel between the client and the server so all transmissions
between them are encrypted. The client then prompts for your password, which it supplies to the server
over the secure channel. The server authenticates you by checking that the password is correct and
permits the login. All subsequent client/server exchanges are protected by that secure channel,
including the contents of the email you proceed to read using a mail program on shell.isp.com.
 File Transfer with scp
The scp program has syntax much like the traditional Unix cp program and nearly identical to the insecure
rcp program. It is roughly:
scp name-of-source name-of-destination In this example, scp copies the file print-me on shell.isp.com over
the network to a local file in your friend’s account on local.university.edu, also called print-me:
$ scp pat@shell.isp.com:print-me print-me

Known Hosts
 The first time an SSH client encounters a new remote machine, it does some
extra work and prints a message like the following:
 $ ssh -l pat shell.isp.com
 Host key not found from the list of known hosts. Are you sure you want to
continue connecting (yes/no)? Assuming you respond yes (the most common
response), the client continues: Host 'shell.isp.com' added to the list of known
hosts. This message appears only the first time you contact a particular
remote host. The message is a security feature related to SSH’s concept of
known hosts.

 Of course, it’s better to have recorded the server’s public host key before
connecting to it the first time, since otherwise you are technically open to a
man-in-themiddle attack that first time. Administrators can maintain system-
wide known-hosts lists for given sets of hosts, but this doesn’t do much good
for connecting to random new hosts around the world. Until a reliable, widely
deployed method of retrieving such keys securely exists (such as secure DNS,
or X.509-based publickey infrastructure), this record-on-first-use mechanism
is an acceptable compromise. If authentication of the server fails, various
things may happen depending on the reason for failure and the SSH
configuration. Typically a warning appears on the screen, ranging from a
repeat of the known-hosts message:

 Host key not found from the list of known hosts. Are you sure you want to
continue connecting (yes/no)? to more dire words:
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that the host key has just been changed.
Please contact your system administrator. Add correct host key in <path>/known_hosts to get rid of this message. Agent forwarding is disabled to avoid attacks by corrupted servers.
X11 forwarding is disabled to avoid attacks by corrupted servers. Are you sure you want to continue connecting (yes/no)

Authentication by Cryptographic Key
In our running example, the user pat is authenticated by the SSH server via login password.
Passwords, however, have serious drawbacks:
• In order for a password to be secure, it should be long and random, but such passwords are hard to
memorize.
• A password sent across the network, even protected by an SSH secure channel,can be captured
when it arrives on the remote host if that host has been compromised.
• Most operating systems support only a single password per account. For shared accounts (e.g., a
superuser account), this presents difficulties:
— Password changes are inconvenient because the new password must be communicated to all people
with access to the account.
— Tracking usage of the account becomes difficult because the operating system doesn’t distinguish
between the different users of the account.

 To address these problems, SSH supports public-key authentication: instead of
relying on the password scheme of the host operating system, SSH may use
cryptographic keys.
A Brief Introduction to Keys:
 A key is a digital identity. It’s a unique string of binary data that means, “This is
me, honestly, I swear.” And with a little cryptographic magic, your SSH client can
prove to a server that its key is genuine, and you are really you. An SSH identity
uses a pair of keys, one private and one public. The private key is a closely
guarded secret only you have. Your SSH clients use it to prove your identity to
servers. The public key is, like the name says, public. You place it freely into your
accounts on SSH server machines. During authentication, the SSH client and server
have a little conversation about your private and public key. If they match
(according to a cryptographic test), your identity is proven, and authentication
succeeds

Generating Key Pairs with ssh-keygen
 To use cryptographic authentication, you must first generate a key pair for yourself, consisting of a
private key (your digital identity that sits on the client machine) and a public key (that sits on the server
machine). To do this, use the ssh-keygen program. Its behavior differs for SSH1, SSH2, and OpenSSH. On
an SSH1 system, the program is called ssh-keygen or ssh-keygen1.

 ssh-keygen creates an RSA key pair and asks you for a secret passphrase to protect the private key.*
 $ ssh-keygen1
Initializing random number generator...
Generating p: ..................................++ (distance 1368)
Generating q: ....++ (distance 58)
Computing the keys...
Testing the keys...
Key generation complete.
Enter file in which to save the key (/home/pat/.ssh/identity):
Enter passphrase: **************
Enter the same passphrase again: **************
Your identification has been saved in identity.
Your public key is:
1024 35
112727219578779368805091678587329704858725674867038216368301950099934876023218886571857276
011133767701853088352661186539160906921498698924021450762186406354890873029854647821544673
72459844567089631066077107611074114663544313782992987840457273825436579285836220249339573
0648451296601594344979290457421809236729 path@shell.isp.com
Your public key has been saved in identity.pub.
On SSH2 systems, the command is either ssh-keygen or ssh-keygen2, and its behavior is a bit different and
produces either a DSA key (the default) or an RSA key:

 $ ssh-keygen2
Generating 1024-bit dsa key pair
1 ..oOo.oOo.oO
2 o.oOo.oOo.oO
3 o.oOo.oOo.oO
4 o.oOo.oOo.oO
Key generated.
1024-bit dsa, created by pat@shell.isp.com Mon Mar 20 13:01:15 2000
Passphrase : **************
Again : **************
Private key saved to /home/pat/.ssh2/id_dsa_1024_a
Public key saved to /home/pat/.ssh2/id_dsa_1024_a.pub

 The OpenSSH version of ssh-keygen also can produce either RSA or DSA keys,
defaulting to RSA. Its operation is similar to that of ssh-keygen1. Normally, ssh-
keygen performs all necessary mathematics to generate a key, but on
some operating systems you might be asked to assist it.

Connecting Without a Password
 To use SSH clients for interactive sessions without a password
 Public-key authentication with an agent
 Trusted-host authentication
 Kerberos authentication

sftp
 The scp command is convenient and useful, but many users are already familiar with FTP (File
Transfer Protocol), a more widely used technique for transferring files on the Internet.* sftp is a
separate file-transfer tool layered on top of SSH.
 Slogin
 slogin is an alternative name for ssh, just as rlogin is a synonym for rsh. On Unix systems, slogin is
simply a symbolic link to ssh. Note that the slogin link is found in SSH1 and OpenSSH but not SSH2.

Inside SSH
 The major features and guarantees of the SSH protocol are:
 Privacy of your data, via strong encryption
 Integrity of communications, guaranteeing they haven’t been altered
 Authentication, i.e., proof of identity of senders and receivers
 Authorization, i.e., access control to accounts
 Forwarding or tunneling to encrypt other TCP/IP-based sessions

Privacy (Encryption)
 Privacy means protecting data from disclosure.
 SSH provides privacy by encrypting data that passes over the network
 SSH supports a variety of encryption algorithms for session data, including
such standard ciphers as ARCFOUR, Blowfish, DES, IDEA, and triple-DES
(3DES).

Integrity
 Integrity means assuring that data transmitted from one end of a network
connection arrives unaltered on the other side. The underlying transport of
SSH, TCP/IP, does have integrity checking to detect alteration due to network
problems (electrical noise, lost packets due to excessive traffic, etc.).
 Authentication
 Authentication means verifying someone’s identity. Suppose I claim to be
Richard Silverman, and you want to authenticate that claim. If not much is at
stake, you might just take my word for it. If you’re a little concerned, you
might ask for my driver’s license or other photo ID.

Authorization
 Authorization means deciding what someone may or may not do. It occurs after
authentication, since you can’t grant someone privileges until you know who she is. SSH
servers have various ways of restricting clients’ actions. Access to interactive login sessions,
TCP port and X window forwarding, key agent forwarding, etc., can all be controlled, though
not all these features are available in all SSH implementations, and they aren’t always as
general or flexible as you might want. Authorization may be controlled at a serverwide level
(e.g., the /etc/sshd_config)

Forwarding (Tunneling)
 Forwarding or tunneling means encapsulating another TCP-based service, such
as Telnet or IMAP, within an SSH session. This brings the security benefits of
SSH (privacy, integrity, authentication, authorization) to other TCP-based
services. For example, an ordinary Telnet connection transmits your
username, password, and the rest of your login session in the clear. By
forwarding telnet through SSH, all of this data is automatically encrypted and
integrity-checked, and you may authenticate using SSH credentials.

Public- and Secret-Key Cryptography
 Encryption algorithms as described so far are called symmetric or secret-key ciphers; the same
key is used for encrypting and decrypting. Examples are Blowfish,DES, IDEA, and RC4.
 Public-key, or asymmetric, cryptography replaces the single key with a pair of related keys:
public and private.
 Public-key methods are also the basis for digital signatures: extra information attached to a
digital document to provide evidence that a particular person has seen and agreed to it, much as
a pen-and-ink signature does with a paper document.Any asymmetric cipher (RSA, ElGamal,
Elliptic Curve, etc.) may be used for digital signatures, though the reverse isn’t true. For
instance, the DSA algorithm,which is used by the SSH-2 protocol for its keys, is a signature-only
public-key scheme and can’t be used for encryption.†

 Secret- and public-key encryption algorithms differ in another way: performance. All common
public-key algorithms are enormously slower than secret-key ciphers—by orders of magnitude. It is
simply infeasible to encrypt large quantities of data using a public-key cipher. For this reason,
modern data encryption uses both methods together. Suppose you want to send some data securely
to your friend Bob Bitflipper. Here’s what a modern encryption program does:
 1. Generate a random key, called the bulk key, for a fast, secret-key algorithm such as 3DES (a.k.a
the bulk cipher).
 2. Encrypt the plaintext with the bulk key.
 3. Secure the bulk key by encrypting it with Bob Bitflipper’s public key, so only Bob can decrypt it.
Since secret keys are small (a few hundred bits long at most), the speed of the public-key
algorithm isn’t an issue.

big picture of SSH:
 Server A program that allows incoming SSH connections to a machine, handling authentication,
authorization, and so forth. In most Unix SSH implementations, the server is sshd.
 Client A program that connects to SSH servers and makes requests, such as “log me in” or “copy this
file.” In SSH1, SSH2, and OpenSSH, the major clients are ssh and scp.

 Session An ongoing connection between a client and a server. It begins after the client successfully
authenticates to a server and ends when the connection terminates. Sessions may be interactive or
batch. Key A relatively small amount of data, generally from tens to one or two thousand bits, used as
a parameter to cryptographic algorithms such as encryption or message authentication. The use of the
key binds the algorithm operation in some way to the key holder: in encryption, it ensures that only
someone else holding that key (or a related one) can decrypt the message; in authentication, it allows
you to later verify that the key holder actually signed the message.

F-Secure SSH Client for Windows
 1. Public-key
 2. Password
 Password authentication
 During password authentication, the user supplies a password to the SSH client, which the client transmits
securely to the server over the encrypted connection. The server then checks that the given password is
acceptable for the target account, and allows the connection if so. In the simplest case, the SSH server checks
this through the native password-authentication mechanism of the host operating system.
 Password authentication is quite convenient because it requires no additional setup for the user. You don’t
need to generate a key, create a ~/.ssh directory on the server machine, or edit any configuration files. This is
particularly convenient for first-time SSH users and for users who travel a lot and don’t carry their private
keys. You might not want to use your private keys on other machines, or there may be no way to get them onto
the machine in question. If you frequently travel, you should consider setting up SSH to use one-time
passwords if your implementation supports them, improving the security of the password scheme

SSH and File Transfers (scp and sftp)

Hash Functions
 CRC-32
 MD5
 SHA-1
 RIPEMD-160

Compression Algorithms: zlib
 zlib is currently the only compression algorithm defined for SSH. In the SSH
protocol documents, the term “zlib” refers to the “deflate” lossless
compression algorithm as first implemented in the popular gzip compression
utility, and later documented in RFC-1951. It is available as a software library
called ZLIB at:

 Eavesdropping
 Name Service and IP Spoofing
 Connection Hijacking
 Man-in-the-Middle Attacks

Installation and Compile-Time
Configuration
 SSH1 and SSH2
SSH1 and SSH2 (a.k.a SSH Secure Shell) were written for Unix and have been
ported to several other operating systems. Both products are distributed as
source code that must be compiled before use, although precompiled
executables for various platforms are also available.

 SSH1 and SSH2 are available by anonymous FTP from ftp.ssh.com in the
directory /pub/ssh, or equivalently from the URL:
 ftp://ftp.ssh.com/pub/ssh/
 You may reach this repository from the web site of SSH Communications
Security:
 http://www.ssh.com/

 Extracting the files
 Distributions are packaged in gzipped tar format. To extract the files, apply
gunzip followed by tar. For example, to extract SSH1 Version 1.2.27 from the
gzipped tar file ssh-1.2.27.tar.gz, type:
 $ gunzip ssh-1.2.27.tar.gz
 $ tar xvf ssh-1.2.27.tar
 Alternatively, use a single command with a pipe:
 $ gunzip < ssh-1.2.27.tar.gz | tar xvf -

Building and Installing SSH1
 Generally, SSH1 is compiled and installed by the following steps. You should
read any README, INSTALL, etc., documents in the distribution to see if there
are any particular known problems or extras steps for installation in your
environment.
 Run the supplied configure script To accept all defaults, change the directory
to the root of the SSH1 distribution and type:
 $ ./configure
 2. Compile everything:
 $ make

Creating the Serverwide Known-Hosts File
 After configuring and installing SSH1 on a host, it’s time to create a machinewide known hosts file
 Normally /etc/ssh_known_hosts, this file contains the public host keys of all hosts in the local domain
or remote hosts that people in this domain connect to frequently via SSH1
 For example, the known hosts file on myhost.example.com likely contains the host keys of all machines
in the example.com domain and perhaps others.

Concurrent Version System (CVS)
 CVS is a version-control system. It maintains a history of changes to sets of
files, and helps coordinate the work of multiple people on the same files. It
can use rsh to connect to repositories on remote hosts. For example, when
you check in a new version of a file:
 $ cvs commit myfile
 if the repository is located on a remote machine, CVS may invoke rsh to
access the remote repository. For a more secure solution, CVS can run ssh
instead of rsh. Of course, the remote machine must be running an SSH server,
and if you use publickey authentication, your remote account must contain
your key in the appropriate place.*

 To make CVS use ssh, simply set the environment variable CVS_RSH to contain the
path to your ssh client:
 # Bourne shell family
 # Put in ~/.profile to make permanent.
 CVS_RSH=/usr/local/bin/ssh
 export CVS_RSH
 # C shell family
 # Put in ~/.login to make permanent.
 setenv CVS_RSH /usr/local/bin/ssh
 This approach has one problem: each time you check in a file, the logger’s name is
the remote account owner, which might not be your own. The problem is solved by
manually setting the remote LOGNAME variable using the “environment=” option
in your remote authorized_keys file.

Serverwide Configuration
 After installing an SSH server (sshd ), it’s time to make informed decisions about your server’s
operation. Which authentication techniques should be permitted? How many bits should the server key
contain? Should idle connections be dropped after a time limit or left connected indefinitely? These
and other questions must be considered carefully. sshd has reasonable defaults, but don’t accept them
blindly. Your server should conform to a carefully planned security policy. Fortunately, sshd is highly
configurable so you can make it do all kinds of interesting tricks.
 sshd may be configured at three levels, and this chapter covers the second one: serverwide
configuration, in which a system administrator controls the global runtime behavior of the server. This
includes a large, rich set of features, such as TCP/IP settings, encryption, authentication, access
control, and error logging. Some features are controlled by modifying a serverwide configuration file,
and others by command-line options passed to the server at invocation.

FTP and Network Address Translation
(NAT)
 Passive-mode transfers can also work around another common problem with FTP: its difficulties
with network address translation, or NAT. NAT is the practice of connecting two networks by a
gateway that rewrites the source and destination addresses of packets as they pass through. One
benefit is that you may connect a network to the Internet or change ISPs without having to
renumber the network (that is, change all your IP addresses). It also allows sharing a limited
number of routable Internet addresses among a larger number of machines on a network using
private addresses not routed on the Internet. This flavor of NAT is often called masquerading.

Ssh

More Related Content

Ssh