openssh bugs - Mar 2006 - [Bug 1172] [PATCH] Restrict public key authentication to scp access only

http://bugzilla.mindrot.org/show_bug.cgi?id=1172

           Summary: [PATCH] Restrict public key authentication to scp access
                    only
           Product: Portable OpenSSH
           Version: 4.3p2
          Platform: All
        OS/Version: Linux
            Status: NEW
          Keywords: patch
          Severity: enhancement
          Priority: P2
         Component: scp
        AssignedTo: bitbucket at mindrot.org
        ReportedBy: tomwilliams14 at comcast.net


In the manual page for sshd, the section "AUTHORIZED_KEYS FILE FORMAT"
indicates that a public key can be modified to include
'command="command"' and
within this paragraph it is indicated that "This option might be useful to
restrict certain public keys to perform just a specific operation".  By
(slightly) abusing this feature one can restrict public key authentication to
only allow scp, i.e., no shell or command execution, for a specific key.

1. Modify the public key in .ssh/authenticated_keys to include
'command="scp-only"'.

2. Apply the attached patch to session.c, RCSID("$OpenBSD: session.c,v
1.191
2005/12/24 02:27:41 djm Exp $"), included in the source for portable
openssh-4.3p2.

The patch takes advantage of the check for the existence of a value in
forced_command. Instead of simply replacing the command from the remote user
with the value in forced_command, the value of forced_command is checked for
the "magic value" of "scp-only" (or some more suitable value
or convention). If
the forced_command begins with this magic value and the command is for scp then
the substitution is not made and the value of command is allowed to continue. 
On the other hand, if the command is not for scp then fatal() is called to
terminate the connection.  With suitable restrictions on the users home
directory, .ssh directory, and the .ssh/authorized_keys file, it seems that a
fairly tight restriction forbidding shell or remote command execution can be
achieved while still allowing scp to function normally.

The patch includes a bit to run through the user submitted scp command and
truncate it at the first ';'. This may or may not be a useful exercise.
Having
it does cause a compiler warning "assignment discards qualifiers from
pointer
target type" because command is a const. My thought was that it might be
better
to truncate then to allow for any funny business that might be included after
the ';'.

The position in session.c where the patch is applied might also be a good place
to put a more general hook to control activities related to a particular
authentication key by further abusing the value of
'command="some_other_magic_value"' that is included in the
public key where
"some_other_magic_value" follows a convention that allows meaningful
magic
values to be recognized as not being any actual command (the original intent of
command=).




------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=1172





------- Comment #1 from tomwilliams14 at comcast.net  2006-03-09 06:59 -------
Created an attachment (id=1093)
 --> (http://bugzilla.mindrot.org/attachment.cgi?id=1093&action=view)
Patch session.c




------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=1172





------- Comment #2 from tomwilliams14 at comcast.net  2006-03-09 08:32 -------
An alternative to the above hack might be to recognize a new option, e.g.,
"scp-only" and change auth_parse_options() to recognize this option
and set a
global variable similar to what happens with, say,
"no-port-forwarding".  Then
change the patch to check for this global variable and act accordingly if it is
set instead of abusing the command= option with "magic values".  Then
to get
the "only scp with this key" behavior you could insert
"scp-only" at the
beginning of the key instead of command="scp-only". I'd be happy
to provide
this patch if it has a better chance of acceptance.




------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=1172


tomwilliams14 at comcast.net changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
Attachment #1093 is|0                           |1
           obsolete|                            |




------- Comment #3 from tomwilliams14 at comcast.net  2006-03-09 10:08 -------
Created an attachment (id=1094)
 --> (http://bugzilla.mindrot.org/attachment.cgi?id=1094&action=view)
Implements "scp-only" as separate option

The cleaner approach of implementing the scp-only behavior as a separate option
instead of abusing the command= option.  Tested between two Slackware boxes.
Running the scp command from the "client" behaves as expected. 
Attempting to
open a shell or remotely run a command results in the client being rudely
disconnected. Related failure message are sent to syslog via fatal().




------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=1172


tomwilliams14 at comcast.net changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         OS/Version|Linux                       |All






------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.