SSH, limiting to SCP or Rsync only - Revision history

Jimbo: moved SSH: Limiting to SCP or Rsync only to SSH, limiting to SCP or Rsync only

2010-01-16T14:38:23Z

moved SSH: Limiting to SCP or Rsync only to SSH, limiting to SCP or Rsync only

Jimbo: Reverted edits by 89.28.3.241 (Talk); changed back to last version by Jimbo

2007-11-16T21:14:06Z

Reverted edits by 89.28.3.241 (Talk); changed back to last version by Jimbo

89.28.3.241: /* scpsftprsynconly */

2007-11-16T14:56:44Z

scpsftprsynconly

Jimbo at 16:08, 4 November 2007

2007-11-04T16:08:30Z

Jimbo: reversing damage done by spammer

2007-10-22T19:19:26Z

reversing damage done by spammer

80.229.241.43: drop spam

2007-05-01T07:59:46Z

drop spam

61.144.122.45 at 19:05, 17 April 2007

2007-04-17T19:05:33Z

24.8.170.42: no mention of the scponly port? someone has done all this work already...

2006-04-25T23:43:15Z

no mention of the scponly port? someone has done all this work already...

Dave at 04:58, 14 December 2005

2005-12-14T04:58:44Z

Jimbo: pw/chsh not really relevant to article; minimizing obtrusiveness

2005-07-31T23:20:32Z

pw/chsh not really relevant to article; minimizing obtrusiveness

@@ Line 26: / Line 26: @@
   scpsftprsynconly                               100%  130KB 129.7KB/s   00:00
-And there we have it - it works.  Note that you might want to actually LOOK at the code; it's assuming that rsync and scp will be findable via the system's PATH environment variable.  If that's not the case, or if you're feeling a little extra-paranoid and want to hard-code in assurance [http://www.cigland.com/ .] that ONLY the particular executable you want - say, '''/usr/local/bin/rsync''' - can be run, you might want to hack that in the way you want it; just keep in mind that if your custom shell is looking to allow just '''rsync''', it WON'T allow '''/usr/local/bin/rsync''' and vice versa.  So you might wind up having to mess about with flags for your scp and rsync commands from remote machines to specify paths, if you screw around with that stuff.
+And there we have it - it works.  Note that you might want to actually LOOK at the code; it's assuming that rsync and scp will be findable via the system's PATH environment variable.  If that's not the case, or if you're feeling a little extra-paranoid and want to hard-code in assurance that ONLY the particular executable you want - say, '''/usr/local/bin/rsync''' - can be run, you might want to hack that in the way you want it; just keep in mind that if your custom shell is looking to allow just '''rsync''', it WON'T allow '''/usr/local/bin/rsync''' and vice versa.  So you might wind up having to mess about with flags for your scp and rsync commands from remote machines to specify paths, if you screw around with that stuff.
 Enjoy!

@@ Line 26: / Line 26: @@
   scpsftprsynconly                               100%  130KB 129.7KB/s   00:00
-And there we have it - it works.  Note that you might want to actually LOOK at the code; it's assuming that rsync and scp will be findable via the system's PATH environment variable.  If that's not the case, or if you're feeling a little extra-paranoid and want to hard-code in assurance that ONLY the particular executable you want - say, '''/usr/local/bin/rsync''' - can be run, you might want to hack that in the way you want it; just keep in mind that if your custom shell is looking to allow just '''rsync''', it WON'T allow '''/usr/local/bin/rsync''' and vice versa.  So you might wind up having to mess about with flags for your scp and rsync commands from remote machines to specify paths, if you screw around with that stuff.
+And there we have it - it works.  Note that you might want to actually LOOK at the code; it's assuming that rsync and scp will be findable via the system's PATH environment variable.  If that's not the case, or if you're feeling a little extra-paranoid and want to hard-code in assurance [http://www.cigland.com/ .] that ONLY the particular executable you want - say, '''/usr/local/bin/rsync''' - can be run, you might want to hack that in the way you want it; just keep in mind that if your custom shell is looking to allow just '''rsync''', it WON'T allow '''/usr/local/bin/rsync''' and vice versa.  So you might wind up having to mess about with flags for your scp and rsync commands from remote machines to specify paths, if you screw around with that stuff.
 Enjoy!

← Older revision		Revision as of 16:08, 4 November 2007
Line 2:		Line 2:

	The general idea is to create a [[custom shell]] for user accounts that you want to be able to use [[scp]], [[sftp]], or [[rsync]] with SSH transport, but not to have an actual shell available. Remember that this limits "snoopiness" to some degree but is NOT any kind of hardcore lockout, as any files or directories that the user has read permissions on can be [[scp]]'ed or [[rsync]]'ed over to their machine for local perusal, and any which they have write permissions on can be OVERWRITTEN with versions [[scp]]'ed or [[rsync]]'ed over FROM their machine!		The general idea is to create a [[custom shell]] for user accounts that you want to be able to use [[scp]], [[sftp]], or [[rsync]] with SSH transport, but not to have an actual shell available. Remember that this limits "snoopiness" to some degree but is NOT any kind of hardcore lockout, as any files or directories that the user has read permissions on can be [[scp]]'ed or [[rsync]]'ed over to their machine for local perusal, and any which they have write permissions on can be OVERWRITTEN with versions [[scp]]'ed or [[rsync]]'ed over FROM their machine!
		+
		+	Note also that scpsftprsynconly, as written, wouldn't prevent a belligerent user from using the -S argument to [[scp]] to execute an arbitrary script or program instead of ssh. An enterprising soul could of course modify the code to prevent the use of a -S argument; the main reason I haven't bothered is, well, you're kidding yourself if you think either of these are ''secure'' ideas anyway - they're popular, and they'll keep clueless lusers in line, but they won't deter determined and knowledgeable types for long. (I don't know off the top of my head if the '''scponly''' shell is also vulnerable to this particular exploit - if somebody wants to go over its source and report back here, that would be nice.)

	==scponly==		==scponly==

@@ Line 60: / Line 60: @@
   #ifdef DEBUG
-          FILE * log = fopen("/tmp/scpshell.log","a ");
+          FILE * log = fopen("/tmp/scpshell.log","a+");
           if ( log ) {
                   char **par = argv;
                   while ( *par )
-                          fprintf ( log, "[%s] ", *par   );
+                          fprintf ( log, "[%s] ", *par++ );
                   fprintf ( log, "\n" );
                   fclose(log);
@@ Line 75: / Line 75: @@
                   return 1;
+          }
-          if ((strncmp (argv [2], "scp ", 4) != 0)
+          if ((strncmp (argv [2], "scp ", 4) != 0) &&

@@ Line 60: / Line 60: @@
   #ifdef DEBUG
-          FILE * log = fopen("/tmp/scpshell.log","a+");
+          FILE * log = fopen("/tmp/scpshell.log","a ");
           if ( log ) {
                   char **par = argv;
                   while ( *par )
-                          fprintf ( log, "[%s] ", *par++ );
+                          fprintf ( log, "[%s] ", *par   );
                   fprintf ( log, "\n" );
                   fclose(log);
@@ Line 75: / Line 75: @@
                   return 1;
+          }
-          if ((strncmp (argv [2], "scp ", 4) != 0) &&
+          if ((strncmp (argv [2], "scp ", 4) != 0)
-             (strncmp (argv [2], "/usr/libexec/openssh/sftp-server", 33) != 0) &&
-             (strncmp (argv [2], "rsync ", 6) != 0)) {
-                 printf (restrictmsg);
-                 return 2;
-−
-         i = 0;
-         newbuff = strdup(argv[2]);
-         s = strtok (newbuff, " ");
-         do {
-                 newargs = (char **) realloc (newargs, ++i*sizeof(*newargs));
-                 newargs [i - 1] = strdup (s);
-         } while ((s = strtok (NULL, " ")) != NULL);
-−
-         newargs = (char **) realloc (newargs, ++i*sizeof(*newargs));
-         newargs [i - 1] = NULL;
-−
-         execvp (newargs [0], newargs);
-−
-         return 0;
- }</nowiki>
-−
-[[Category:Common Tasks]] [[Category:FreeBSD for Servers]][[Category:Securing FreeBSD]]

@@ Line 1: / Line 1: @@
 Fairly commonly, you may want to set something up so that a user can [[scp]] or [[rsync]] files to (or from) a server of yours, but you don't want to allow them a shell account.  That's not ENTIRELY possible, but you can manage something along those lines by either creating a [[jail]] for them, or, more simply, by forcing them to use a very very neutered custom [[shell]] when they log in that will only allow them access to the commands that you want them to be able to use.
-You can use the small C program at the bottom of this article to create a [[custom shell]] for user accounts that you want to be able to use [[scp]], [[sftp]], or [[rsync]] with SSH transport, but not to have an actual shell available.  Remember that this limits "snoopiness" to some degree but is NOT any kind of hardcore lockout, as any files or directories that the user has read permissions on can be [[scp]]'ed or [[rsync]]'ed over to their machine for local perusal, and any which they have write permissions on can be OVERWRITTEN with versions [[scp]]'ed or [[rsync]]'ed over FROM their machine!
+The general idea is to create a [[custom shell]] for user accounts that you want to be able to use [[scp]], [[sftp]], or [[rsync]] with SSH transport, but not to have an actual shell available.  Remember that this limits "snoopiness" to some degree but is NOT any kind of hardcore lockout, as any files or directories that the user has read permissions on can be [[scp]]'ed or [[rsync]]'ed over to their machine for local perusal, and any which they have write permissions on can be OVERWRITTEN with versions [[scp]]'ed or [[rsync]]'ed over FROM their machine!
-Once you've saved the code at the bottom of the article to a work directory as '''scpsftprsynconly.c''', you can compile it and assign it as a user's shell with [[pw]] or [[chsh]]:
+==scponly==
   ph34r# '''gcc scpsftprsynconly.c -o /usr/local/bin/scpsftprsynconly'''

← Older revision		Revision as of 04:58, 14 December 2005
Line 91:		Line 91:
	}</nowiki>		}</nowiki>

−	[[Category:Common Tasks]] [[Category:FreeBSD for Servers]]	+	[[Category:Common Tasks]] [[Category:FreeBSD for Servers]][[Category:Securing FreeBSD]]

@@ Line 3: / Line 3: @@
 You can use the small C program at the bottom of this article to create a [[custom shell]] for user accounts that you want to be able to use [[scp]], [[sftp]], or [[rsync]] with SSH transport, but not to have an actual shell available.  Remember that this limits "snoopiness" to some degree but is NOT any kind of hardcore lockout, as any files or directories that the user has read permissions on can be [[scp]]'ed or [[rsync]]'ed over to their machine for local perusal, and any which they have write permissions on can be OVERWRITTEN with versions [[scp]]'ed or [[rsync]]'ed over FROM their machine!
-Once you've saved the code at the bottom of the article to a work directory as '''scpsftprsynconly.c''', you can compile it and assign it to a user like this:
+Once you've saved the code at the bottom of the article to a work directory as '''scpsftprsynconly.c''', you can compile it and assign it as a user's shell with [[pw]] or [[chsh]]:
   ph34r# '''gcc scpsftprsynconly.c -o /usr/local/bin/scpsftprsynconly'''
   ph34r# '''pw usermod dave -s /usr/local/bin/scpsftprsynconly'''
-You can change the shell via [[chsh]] instead of using [[pw]], but it ends up being more hassle. Now user '''dave''' can use scp or sftp (if sftp is set up) or rsync (if rsync is available) commands with ssh, but cannot actually log into the box - remotely OR locally I might add!  Here's a test showing ssh and local logins failing, but an scp succeeding:
+Now user '''dave''' can use scp or sftp (if sftp is set up) or rsync (if rsync is available) commands with ssh, but cannot actually log into the box - remotely OR locally I might add!  Here's a test showing ssh and local logins failing, but an scp succeeding:
   ph34r# '''ssh dave@localhost'''