[scponly] ssh and scponly related query.

[J.D. Baldwin]

On Thu, Sep 15, 2005 at 07:48:26PM +0100, Benjamin Donnachie wrote:
> >Create two UNIX users, let's say ben1 and ben2.  Both will be defined
> >with the same home directory and UID, and the same group membership.
> >In ~ben1/.ssh/authorized_keys are your public keys for authentication.
> >There is no ~/ben2/.ssh/authorized_keys file.
> 
> My understanding is that OpenSSH looks in the ~/.ssh directory for it's 
> config files - so if both users have the same home directory, they'll both 
> have the same .ssh/authorized_keys file... :-/

Oops, got a little sloppy there.  You are right about that of course.

> >Now you can do uploads/downloads with the ben2 account and its
> >password, but you can shell in to ben1 with your key.
> 
> Though this might not matter as ben2 could remain chroot'ed with scp as its 
> shell and ben1 be "un-chrooted" with bash...  Do you know whether public 
> key authentication will work even if a user's password is disabled?  
> (Unfortunately, I'm off site at the moment so can't check)  As, if so, this 
> would be an ideal solution! :-)

The answer to the above question depends on the OS and the way you
disable the password.  Solaris 9/10 have fixed some irritating
deficiencies in their password-disabling methods.  If the password is
*locked* -- e.g., "*LK*" in the shadow file, OpenSSH won't let you log
in even with a key.  If the password is "no password" -- e.g., "NP" in
the shadow file, you'll be allowed in as long as you have some way of
authenticating without a password.

I expect other UNIX variants and work-alikes have similar provisions,
but I don't know what they are and how to manipulate them.  I can tell
you (looking at the man page in another window) that in later versions
of Solaris:

    passwd -l LOCKS the account
    passwd -N disables password-based authentication, but allows use
                of the account

Another option would be to use the AuthorizedKeysFile directive in
sshd_config to give ben1 a key while ben2 gets none and therefore has
to use a password.

Example line in sshd_config:

AuthorizedKeysFile    /usr/local/etc/authorized_keys/%u

Now instead of ~/.ssh/authorized_keys, the ben1 account looks in
/usr/local/etc/authorized_keys/ben1 for public keys.

A couple of caveats:

 - the key file must be readable by the user being logged in (I don't
   know why, given that the authentication is being done as root, but
   that is how it works)

 - Solaris doesn't support this -- even if you are on Sol9 or Sol10 you
   will have to install OpenSSH to get this feature

jd