Workbook 10 Chapter

1
Workbook 10Chapter 8.  Remote Shell Commands
Pace Center for Business and Technology
2
Chapter 8.  Remote Shell Commands

• Key Concepts
• Remote shell applications allow users to execute
  arbitrary commands on remote machines, and have
  standard out returned locally. Alternately, an
  interactive shell can be started.
• The Secure Shell application provides a remote
  shell, where all transactions are encrypted, and
  users can be authenticated by traditional
  passwords or using a public key authentication
  scheme.
• In order to use the public key authentication
  scheme, a public- private key pair must be
  generated with the ssh-keygen command.
• Because Secure shell servers have their own
  public-private key pairs, servers can be
  authenticated to clients as well as clients
  authenticated to servers.

3
The Original Remote Shell rsh and Rhosts
Authentication

• Remote Shells with rsh
• Linux (and Unix) shells are intentionally
  designed with simple interfaces they read input
  from the standard in stream, and deliver output
  to the standard out stream. As a result, the
  interfaces are easily implemented over network
  connections. By simply substituting a TCP socket
  for a terminal device, a shell can operate on a
  remote machine as easily as the local machine. In
  Linux (and Unix), applications which provide this
  functionality are referred to as remote shells.
• The first commonly used Unix remote shell was the
  simple rsh application. If a remote machine is
  properly configured (i.e., it is running the RSH
  server), users can use a rsh command to invoke a
  remote shell.

4
The Original Remote Shell rsh and Rhosts
Authentication

• Translating, this command says "as the user elvis
  on the host server1, run the command ls /tmp".
  The command executes on the remote machine
  (server1), but standard out is delivered to the
  local machine (station). When the command
  completes, elvis's prompt implies that he is
  still on the host station.
• If elvis does not specify a command to run, the
  rsh utility would opens an interactive shell on
  the remote host server1. By paying close
  attention to the bash prompt in the following
  excerpt, note which commands execute on which
  machine.

5
Rhosts Authentication /.rhosts

• In each case, elvis did not need issue a
  password. Before he could access his remote
  account using rsh, however, elvis needed to
  configure the account to allow him access from
  his local machine. For rsh, access control
  configuration is as trivial as adding a line to a
  file. On the remote account, elvis created the
  file /.rhosts, and added one line containing the
  hostname and username for each external account
  which he wanted to grant access. Additionally,
  the RSH server requires that the file's
  permissions prohibit anyone but the user owner
  from reading the file. As the following commands
  illustrate, elvis has already configured his
  .rhosts file on the remote machine.
• Authentication which relies on a properly
  configured /.rhosts configuration file is
  commonly called rhosts authentication.

6
The Secure Shell

• The rhosts authentication method is pitiful. At
  its essence, it relies on DNS (Domain Name
  Service) to authenticate a user. In order to
  exploit elvis's /.rhosts configuration, all
  someone would have to do is detach the real host
  station from the network, and bring up another
  machine configured with station's IP address. The
  fault is not elvis's, but the design of the rhost
  authentication protocol.
• Additionally, rsh is a plaintext protocol.
  Exchanging data over a network in plaintext is
  essentially the equivalent to sending mail on
  postcards anyone handling the data between here
  and there is privy to its contents.
• The Secure Shell was developed to address both of
  these shortcomings of the rsh command, and add
  significant new capabilities, while still
  providing all of rsh's convenience. Assuming the
  remote machine is running the ssh service (i.e.,
  the sshd daemon), elvis could invoke a shell on
  the remote machine with the following.

7
The Secure Shell

• The ssh command's new syntax for specifying the
  username of the remote account is slightly easier
  than is rsh's, although the -l command line
  switch is also implemented (in order to be fully
  backwards compatible).
• In the above example, elvis is authenticated by
  providing a password instead of configuring a
  /.rhosts file. In the next section, we find that
  the Secure Shell can use a more mature public key
  technique to grant users "password free" access
  to an account. When public key authentication is
  not implemented, however, ssh falls back to
  traditional password authentication. 2

8
Secure Shell Public Key Authentication

• In addition to traditional password
  authentication, the Secure Shell application can
  use public key cryptography to authenticate
  users. Public key encryption algorithms relate
  two large numbers, referred to as "keys", so that
  information encrypted with one key can only be
  decrypted with the other. Anyone who wants to use
  public key cryptography must first generate a
  pair of keys. Most public key protocols call one
  key a public key, and the complementary key a
  private key. Your public key you treat like your
  phone number you share it with anyone with whom
  you are willing to communicate, and may choose to
  list it in public directories. Your private key,
  on the other hand, you share with no one. All of
  the security provided by public key protocols
  relies on the fact that only you know the
  contents of your private key.

9
Generating a Public-Private Key Pair ssh-keygen

• When using ssh, a user's public-private key pair
  can be generated with the ssh-keygen command. In
  the following example, elvis uses ssh-keygen to
  generate a ssh public-private key pair.
• The user elvis was first prompted for the new
  (private) key's filename, to which elvis simply
  hit RETURN to accept the default filename
  /.ssh/id_rsa. Next, elvis was given the
  opportunity to attach a passphrase to his private
  key. By hitting RETURN again (twice), elvis chose
  not to. (We will discuss passphrases in more
  detail later.)

10
Generating a Public-Private Key Pair ssh-keygen

• When the command returns, elvis has two new files
  in his (perhaps newly created) /.ssh directory.
  The first is his private key, which he shares
  with no one. (He certainly doesn't publish it in
  an online text).
• He is free to share his second key (the public
  key) with anyone whom asks.

11
Allowing Account Access /.ssh/authorized_keys

• SSH access to an account is granted by obtaining
  a copy of the public key of the person who is to
  be granted access, and storing it in the
  account's /.ssh/authorized_keys file. Like the
  /.rhosts file, the /.ssh/authorized_keys file,
  and the whole /.ssh directory, must only be
  readable by the user. How the copy of the public
  key is obtained does not matter. It could be
  emailed, scped (as discussed in a moment), or
  transferred from one terminal to another using
  the mouse's cut and paste buffer.

12
Allowing Account Access /.ssh/authorized_keys

• When handling public keys, however, care must be
  taken to ensure that the key is placed in the
  file with no embedded whitespace, including
  newlines. Although too long to be displayed as
  such, SSH public keys are always stored as a
  single line of text. More people can be granted
  access to an account by simply appending their
  public keys to the /.ssh/authorized_keys files,
  one public key per line.

13
Allowing Account Access /.ssh/authorized_keys

• In the following example, elvis uses ssh,
  redirection, and some carefully placed quotes to
  append his public key (on the host station) to
  the authorized_keys file in his account on the
  host serer1.
• Okay, so we need to make the .ssh directory
  first.
• Why the quotes? With no quotes, the output of the
  cat command would have been appended to the file
  .ssh/authorized_keys on the local machine. The
  quotes serve to pass the redirection syntax
  "into" the remote shell.

14
Allowing Account Access /.ssh/authorized_keys

• Having placed his public key in the
  /.ssh/authorized_keys file on the remote
  machine, elvis now expects to be able to examine
  the contents of the file without having to issue
  a password.
• Something is amiss, because elvis was again
  prompted for his password. Recalling that only
  the user should be able to access the /.ssh
  directory and read the /.ssh/authorized_keys
  file, elvis implements the appropriate chmod
  command on the remote machine. Afterwords, he is
  able to observe the new permissions without
  having to issue a password.
• Success.

15
Public Key Authentication Details

• In order to develop an appreciation for the
  robustness of public key authentication, we will
  spend a few moments discussing the protocol. When
  the secure shell application implements public
  key authentication, it uses a procedure similar
  to the following. In our discussion, the
  following symbols will be used.

16
Public Key Authentication Details

• First, the ssh client on the host station
  requests a connection to the sshd daemon on the
  host server1. Upon receiving the connection
  request, the sshd daemon looks for a registered
  public key in the destination account's
  /.ssh/authorized_keys file.
• If a relevant public key is discovered, the sshd
  daemon initiates public key authentication by
  generating a random string R. It then encrypts
  the random string with elvis's public key P
  (which it obtains from the /.ssh/authorized_keys
  file), and delivers the encrypted random string
  P(R) over the network to the ssh client.

17
Public Key Authentication Details

• Upon receiving the encrypted random string P(R),
  the ssh client uses elvis's private key S to
  decrypt it. Once the original random string R is
  recovered, the ssh client returns it to the sshd
  daemon.

18
Public Key Authentication Details

• If the sshd daemon receives from the ssh client
  the same random string with which it started, the
  client is authenticated, and the connection is
  allowed to continue.

19
Public Key Authentication Details

• A couple of aspects of this algorithm deserve
  mentioning.
• The ssh client is authenticated not by a hostname
  or IP address, and not by a password, but solely
  by the possession of the private key. (If the
  client could not access the appropriate private
  key, it would not have been able to decrypt the
  encrypted random string passed to it.)
• The only information passed over the network is
  an encrypted random string, and a random string
  (the symbols colored red in the accompanying
  figures). Anyone eavesdropping on the
  conversation would not learn anything useful.
• In practice, the actual algorithm used is more
  complicated. But the protocol outlined above
  illustrates the most important features of the
  public key authentication protocol

20
Transferring Files Securely and Easily scp

• As the previous discussion illustrates, files can
  be transferred from one machine to another using
  ssh with the cat command and careful redirection.
  Fortunately, there is an easier and less error
  prone way scp.
• The scp command uses a syntax almost identical to
  the cp command, but either the source file(s) or
  the destination file can be on a remote machine,
  accessed through a specified account. 3 When
  referring to a file on a remote machine, the
  following syntax is used.
• The user and host are simply enough the host
  where the file resides, and the user whose
  account is used to access the file. If the file's
  path begins with a /, it is considered an
  absolute reference. If not, it is considered
  relative to the user's home directory. If no path
  is supplied, the user's home directory is
  assumed.
• As an example, the following command line would
  transfer the /etc/services file from server1 into
  the /cfg/server1/etc/ directory in elvis's home
  directory.

21
Transferring Files Securely and Easily scp

• Because elvis has a properly configured public
  key authentication with his account on server1,
  he is able to transfer the file without issuing a
  password. What happens if he tries to transfer
  the file /etc/shadow?
• The user elvis on the host server1 does not have
  permissions to read the file /etc/shadow, so the
  file can naturally not be transferred. If the
  user elvis knows the password to the root account
  on the remote machine, however, the file could be
  accessed through it.
• Because elvis does not have public key
  authenticated access to the root account on
  server1, ssh used traditional password
  authentication.

22
Transferring Files Securely and Easily scp

• The -r command line switch (for "recursive") must
  be specified when copying an entire directory
  (and its subdirectories). In the following, elvis
  recursively copies the /etc/sysconfig directory
  from his local machine (station) to the machine
  server1's /tmp directory.
• As the scp command performs the transfer, it
  displays transfer timing information for each
  file.

23
Secure Shell Host Authentication

• The first time the ssh (or scp) client is used to
  connect to a sshd Secure Shell server, a message
  similar to the following is displayed.
• If the user answers yes (the only answer which
  will allow the connection to continue), the
  connection proceeds, with the following warning.
• On subsequent connections, the message is no
  longer seen.

24
Secure Shell Host Authentication

• The Secure Shell not only authenticates clients
  to servers, but also servers to clients, using
  public key authentication. Just as users can
  create public-private key pairs with the
  ssh-keygen command, the sshd daemon maintains its
  own public-private key pair, known as its host
  key. The first time a ssh client connects to a
  sshd daemon, it appends a copy of the remote
  daemon's public host key to the local file
  /.ssh/known_hosts.
• As the client is used to connect to various
  machines, the /.ssh/known_hosts file grows,
  recording one public key for each machine
  contacted. The next time the client connects to a
  host, it silently uses the same public key
  protocol used to authenticate users, reversed, to
  authenticate the host to which it is connecting.

25
Secure Shell Host Authentication

• What if the remote host does not posses the same
  identity which complements the public key stored
  in the client's /.ssh/known_hosts file? The
  client refuses to connect, and instead issues the
  following warning.

26
Secure Shell Host Authentication

• Often, there is a very reasonable explanation why
  the server has changed identity. For example, the
  server might have been upgraded with a more
  recent version of its operating system, and as a
  result, generated a new host public-private key
  pair. If a reasonable explanation for the change
  in identity is available, the ssh client can be
  convinced to connect by removing the offending
  line from the /.ssh/known_hosts file, and
  "starting over" by collecting a new key for the
  host.

27
Secure Shell Host AuthenticationLAB

• http//csis.pace.edu/adelgado/rha-030/labs/workboo
  k10/chapter-8/ssh-no-keys.htm