Per-Account Server Configuration

We've seen two techniques for controlling the SSH server's behavior globally: compile-time configuration (Chapter 4) and serverwide configuration (Chapter 5). These techniques affect
all incoming SSH connections to a given server machine. Now it's time to introduce a third, finer-grained method of server control: per-account configuration.
As the name implies, per-account configuration controls the SSH server differently for each user account on the server machine. For example, a user account sandy can accept incoming SSH connections from any machine on the Internet, while rick permits connections only from the domain verysafe.com, and fraidycat refuses key-based connections. Each user configures his or her own account, using the facilities highlighted in Figure 8-1, without
needing special privileges or assistance from the system administrator.
Figure 8.1. Per-account configuration (highlighted parts)
We have already seen a simple type of per-account configuration. A user may place a public key into her authorization file, instructing the SSH server to permit logins to her account by
public-key authentication. But per-account configuration can go further, becoming a powerful tool for access control and playing some fun tricks with your account. Accepting or rejecting connections by particular keys or hosts is just the beginning. For instance, you can make an incoming SSH connection run a program of your choice, instead of the client's choice. This is called a forced command, and we'll cover quite a few interesting applications.
Per-account configuration may control only incoming SSH connections to your account. If you're interested in configuring outgoing SSH connections by running SSH clients, refer to Chapter 7.
Book: SSH, The Secure Shell: The Definitive Guide Section: Chapter 8. Per-Account Server Configuration
8.1 Limits of This Technique
Per-account configuration can do many interesting things, but it has some restrictions that we will discuss:
  • ●  It can't defeat security measures put in place by compile-time or serverwide configuration. (Thank goodness.)
  • ●  It is most flexible and secure if you use public-key authentication. Trusted-host and password authentication provide a much narrower range of options.
    8.1.1 Overriding Serverwide Settings
    SSH settings in a user's account may only restrict the authentication of incoming connections. They can't enable any SSH features that have been turned off more globally, and they can't permit a forbidden user or host to authenticate. For example, if your SSH server rejects all connections from the domain evil.org, you can't override this restriction
    [1]
    within your account by per-account configuration.
    This limitation makes sense. No end-user tool should be able to violate a server security policy. However, end users should be (and are) allowed to restrict incoming connections to their accounts.
    A few features of the server may be overridden by per-account configuration. The most notable one is the server's idle timeout, which may be extended beyond the serverwide setting. But such features can't coerce the server to accept a connection it has been globally configured to reject.
    If you are an end user, and per-account configuration doesn't provide enough flexibility, you can run your own instance of the SSH server, which you may configure to your heart's content. [Section 5.2.2] Be cautious, though, since this is seldom the right thing to do. The
    restrictions you're trying to circumvent are part of the security policy defined for the machine by its administrators, and you shouldn't run a program that flouts this policy just because you can. If the machine in question is under your administrative control, simply configure the main SSH server as you wish. If not, then installing and running your own sshd might violate your usage agreement and/or certainly annoy your sysadmin. And that's never a wise thing to do.
    8.1.2 Authentication Issues
To make the best use of per-account configuration, use public-key authentication.
Password authentication is too limited, since the only way to control access is with the password itself. Trusted-host authentication permits a small amount of flexibility, but not nearly as much as public-key authentication.
If you're still stuck in the password-authentication dark ages, let this be another reason to switch to public keys. Even though passwords and public-key passphrases might seem similar (you type a secret word, and voilà, you're logged in), public keys are far more flexible for permitting or denying access to your account. Read on and learn how.
[1]
There is one exception to this rule: trusted-host authentication. A user's ~/.shosts file may
override a restriction placed by the system administrator in /etc/shosts.equiv. [Section 8.3][Section 3.4.2.3]
Book: SSH, The Secure Shell: The Definitive Guide Section: Chapter 8. Per-Account Server Configuration
8.2 Public Key-Based Configuration
To set up public-key authentication in your account on an SSH server machine, you create an authorization file, typically called authorized_keys (SSH1, OpenSSH/1), authorized_keys2 (OpenSSH/2), or authorization (SSH2), and list the keys that provide access to your account. [Section 2.4] Well, we've been keeping a secret. Your authorization file can contain not only keys but also other keywords or options to control the SSH server in powerful ways. We will discuss:
● ● ● ● ● ●
The full format of an authorization file
Forced commands for limiting the set of programs that the client may invoke on the server Restricting incoming connections from particular hosts
Setting environment variables for remote programs
Setting an idle timeout so clients will be forcibly disconnected if they aren't sending data Disabling certain features of the incoming SSH connection, such as port forwarding and tty allocation
As we
server
will use the new information. Any existing connections are already authenticated and won't be affected by the change.
demonstrate how to modify your authorization file, remember that the file is consulted by the SSH only at authentication time. Therefore, if you change your authorization file, only new connections
Also remember that an incoming connection request won't reach your authorization file if the SSH server rejects it for other reasons, namely, failing to satisfy the serverwide configuration. If a change to your authorization file doesn't seem to be having an effect, make sure it doesn't conflict with a (more powerful) serverwide configuration setting.
8.2.1 SSH1 Authorization Files
Your SSH1 authorized_keys file, generally found in ~/.ssh/authorized_keys, is a secure doorway into your account via the SSH-1 protocol. Each line of the file contains a public key and means the following: "I give permission for SSH-1 clients to access my account, in a particular way, using this key as authentication." Notice the words "in a particular way." Until now, public keys have provided unlimited access to an account. Now we'll see the rest of the story.
Each line of authorized_keys contains up to three items in order, some optional and some required:
  • ●  A set of options (optional, surprise, surprise).
  • ●  The public key (required). This appears in three parts: [Section 3.4.2.2]
    • ❍  The number of bits in the key, typically a small integer such as 1024
    • ❍  The exponent of the key: an integer
    • ❍  The modulus of the key: a very large integer, typically several hundred digits long
  • ●  A descriptive comment (optional). This can be any text, such as "Bob's public key" or "My home PC using SecureCRT 3.1."
Public keys and comments are generated by ssh-keygen in .pub files, you may recall, and you typically insert
them into authorized_keys by copying. [Section 2.4.3] Options, however, are usually typed into
[2]
An option may take two forms. It may be a keyword, such as: 
# SSH1, OpenSSH: Turn off port forwarding
no-port-forwarding
or it may be a keyword followed by an equals sign and a value, such as: 
# SSH1, OpenSSH: Set idle timeout to five minutes
idle-timeout=5m
Multiple options may be given together, separated by commas, with no whitespace between the options: 
# SSH1, OpenSSH
no-port-forwarding,idle-timeout=5m
If you mistakenly include whitespace: 
# THIS IS ILLEGAL: whitespace between the options
no-port-forwarding, idle-timeout=5m
your connection by this key won't work properly. If you connect with debugging turned on (ssh1 -v), you will see a "syntax error" message from the SSH server.
Many SSH users aren't aware of options or neglect to use them. This is a pity because options provide extra security and convenience. The more you know about the clients that access your account, the more options you can use to control that access.
8.2.2 SSH2 Authorization Files
[3]
An SSH2 authorization file, typically found in ~/.ssh2/authorization,
ancestor. Instead of public keys, it contains keywords and values, much like other SSH configuration files we've seen. Each line of the file contains one keyword followed by its value. The most commonly used keywords are Key and Command.
Public keys are indicated using the Key keyword. Key is followed by whitespace, and then the name of a file containing a public key. Relative filenames refer to files in ~/.ssh2. For example: 
# SSH2 only
Key myself.pub
means that an SSH-2 public key is contained in ~/.ssh2/myself.pub. Your authorization file must contain at least one Key line for public-key authentication to occur.
Each Key line may optionally be followed immediately by a Command keyword and its value. Command specifies a forced command, i.e., a command to be executed whenever the key immediately above is used
authorized_keys with a text editor.
has a different format from its SSH1
for access. We discuss forced commands later in great detail. [Section 8.2.4] For now, all you need to know is this: a forced command begins with the keyword Command, is followed by whitespace, and ends with a shell command line. For example: 
# SSH2 only
Key somekey.pub
Command "/bin/echo All logins are disabled"
Remember that a Command line by itself is an error. The following examples are illegal: 
# THIS IS ILLEGAL: no Key line
Command "/bin/echo This line is bad."
# THIS IS ILLEGAL: no Key line precedes the second Command
Key somekey.pub
Command "/bin/echo All logins are disabled"
Command "/bin/echo This line is bad."
8.2.2.1 SSH2 PGP key authentication
SSH2 Version 2.0.13 introduced support for PGP authentication. [Section 5.5.1.6] Your authorization file may also include PgpPublicKeyFile, PgpKeyName, PgpKey Fingerprint, and PgpKeyId
lines. A Command line may follow PgpKeyName, PgpKeyFingerprint, or PgpKeyId, just as it may follow Key: 
# SSH2 only
PgpKeyName my-key
Command "/bin/echo PGP authentication was detected"
8.2.3 OpenSSH Authorization Files
For SSH-1 protocol connections, OpenSSH/1 uses the same authorized_keys file as SSH1. All configuration that's possible with SSH1 is available within OpenSSH/1.
For SSH-2 connections, OpenSSH/2 takes a new approach unlike SSH2's: a new authorization file, ~/.ssh/ authorized_keys2, with a format similar to that of authorized_keys. Each line may contain:
  • ●  Key authorization options (optional)
  • ●  The string "ssh-dss" (required)
  • ●  The DSA public key, represented as a long string (required)
  • ●  A descriptive comment (optional)
    Here's an example with the long public key abbreviated: 
    host=192.168.10.1 ssh-dss AAAAB3NzaC1kc3MA... My OpenSSH key
    8.2.4 Forced Commands
Ordinarily, an SSH connection invokes a remote command chosen by the client: 

# Invoke a remote login shell
$ ssh server.example.com
# Invoke a remote directory listing
$ ssh server.example.com /bin/ls
A forced command transfers this control from the client to the server. Instead of the client's deciding which command will run, the owner of the server account decides. In Figure 8-2, the client has requested the command /bin/ls, but the server-side forced command runs /bin/who instead.
Figure 8.2. Forced command substituting /bin/who for /bin/ls
Forced commands can be quite useful. Suppose you want to give your assistant access to your account but only to read your email. You could associate a forced command with your assistant's SSH key to run only your email program and nothing else.
In SSH1 and OpenSSH, a forced command may be specified in authorized_keys with the "command" option preceding the desired key. For example, to run the email program pine whenever your assistant connects:
# SSH1, OpenSSH
command="/usr/local/bin/pine" ...secretary's public key...
In SSH2, a forced command appears on the line immediately following the desired Key, using the Command keyword. The previous example would be represented: 
# SSH2 only
Key secretary.pub
Command "/usr/local/bin/pine"
You may associate at most one forced command with a given key. To associate multiple commands with a key, put them in a script on the remote machine and run the script as the forced command. (We demonstrate this in [Section 8.2.4.3].) 

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)