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@pobox.com | http://www.pobox.com/~jmknoble/
(GnuPG key ID: 6F39C2CC >>>>>> http://www.pobox.com/~jmknoble/keys/ )
(GnuPG fingerprint: 5024578: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|
+----------------------------------------------------------------------+
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/li...enssh-unix-dev