User-specific sshd_config?

[Jim Knoble]

Circa 2008-04-04 10:46 dixit Bob Proulx:

: Peter Stuge wrote:
: > Ingemar Nilsson wrote:
: > > I wonder if it would be possible to implement support for a 
: > > user-specific sshd_config.
: > Either way I believe it will be much quicker to ask your friendly
: > root to add the exception in a Match block in the system sshd_config.
: 
: When faced with a similar problem I ran an additional and separate
: sshd and supplemented the configuration with command line arguments.
: In this case IIRC -oPasswordAuthentication=no -Port=2222
: -oPidFile=/var/run/sshd-noppass.pid and installed a control script
: /etc/init.d/sshd.nopass and then adjusted firewall rules accordingly.

I've gone even further before and done the following in addition to what
Bob writes above:

  - Create an alternate sshd_config file, containing the restricted
    configuration, limiting the configuration to specific users using
    either the AllowUsers or AllowGroups directive.

  - Forbid the specific users allowed above from using the general
    sshd_config using DenyUsers or DenyGroups (or using a disjoint
    AllowUsers or AllowGroups directive).

  - If the users are to be severely restricted in what they're allowed
    to do, create a ~/.ssh/authorized_keys file with restrictions for
    every allowed key, and ensure that the user's home directory,
    ~/.ssh directory, and ~/.ssh/authorized_keys file are neither owned
    nor writable by the user.  The StrictModes directive is often needed
    for this to work.

If you're attempting to restrict a user to only pubkey authentication so
that you can use authorized_keys to control what the user may do, then
you should pay particular attention to the *Authentication directives:

    PubkeyAuthentication yes
    PasswordAuthentication no
    ChallengeResponseAuthentication no
    HostbasedAuthentication no
    KerberosAuthentication no
    GSSAPIAuthentication no
    UsePAM no

Several of the above are defaults, but it's best to be explicit when
you're creating a restricted configuration.

You may wish to considier other restrictions as well, such as:

    AllowTcpForwarding no
    X11Forwarding no
    PermitTunnel no
    PermitUserEnvironment no
    # Remove any AcceptEnv directives that should not apply
    # Remove any Subsystem directives that should not apply
    # You may also wish to do:
    MaxAuthTries 1
    PrintLastLog no
    PrintMotd no

If you want to use ForceCommand, you should upgrade to OpenSSH 5.0 or
5.0p1, as there was a bugfix associated with whether ~/.ssh/rc is
processed when ForceCommand is specified.

Good luck.

-- 
jim knoble  |  jmknoble at pobox.com  |  http://www.pobox.com/~jmknoble/
(GnuPG key ID: 6F39C2CC  >>>>>>  http://www.pobox.com/~jmknoble/keys/ )
(GnuPG fingerprint: 5024:D578:7CF4:5660:7269::F6F3:B919:9307:6F39:C2CC)
+----------------------------------------------------------------------+
|[L]iberty, as we all know, cannot flourish in a country that is perma-|
| nently on a war footing, or even a near-war footing.  --Aldous Huxley|
+----------------------------------------------------------------------+