How many other beloved books have been bowdlerized and then reissued without the public’s knowledge? //

“It seems depressing that we are so squeamish that we can’t credit youngsters with seeing the context for texts,” Geoff Barton, head of King Edward’s School in Bury St Edmunds, added.

 lsattr -aR .//. | sed -rn '/i.+\.\/\/\./s/\.\/\///p'

 lsattr -Ra 2>/dev/null /|awk '$1 ~ /i/ && $1 !~ /^\// {print}'

Change i to d to find "nodump" attribute/flag

FreeBSD:
find . -flags +nodump

GNU Rush is a Restricted User Shell, designed for sites providing limited remote access to their resources, such as, for example, savannah.gnu.org. Its main program, rush, is configured as a user login shell for users that are allowed only remote access to the machine.

In OpenSSH, a user's authorized keys file lists keys that are authorized for authenticating as that user, one per line. Lines starting with # and empty lines are ignored.

Each line contains a public SSH key. The public key may be preceded by options that control what can be done with the key.

The following options are supported in authorized_keys files.

The authorized_keys has a command="..." option that restricts a key to a single command. Is there a way to restrict a key to multiple commands? E.g. by having a regex there, or by editing some other configuration file? //

You can have only one command per key, because the command is “forced”.

But you can use a wrapper script. The called command gets the original command line as environment variable $SSH_ORIGINAL_COMMAND, which it can evaluate.

Our second line of defense in securing our script setup is to use the command ="" directive, also specified in the authorized_keys file. The syntax for this looks like:

 command ="command",  KEY

This tells SSH to run command and then exit. It effectively limits your ability to run commands on the remote server.

Rawhide (rh(1)) lets you search for files on the command line using expressions and user-defined functions in a mini-language inspired by C. It's like find(1), but more fun to use.

sshdo provides an easily configurable way of controlling which commands may be executed via incoming ssh connections.

But, what if you really want to be really precise on the command? Using the above example, not only running rsync but also specifying the path and the arguments? You could cheat and find what the command you are sending is supposed to look like by replacing (temporarily) your wrapper script with this

 #!/bin/sh

 DEBUG="logger" # Linux
 #DEBUG="syslog -s -l note" # OSX

 if [ -n "$SSH_ORIGINAL_COMMAND" ]; then
         $DEBUG "Passed SSH command $SSH_ORIGINAL_COMMAND"
 elif [ -n "$SSH2_ORIGINAL_COMMAND" ]; then
         $DEBUG "Passed SSH2 command     $SSH2_ORIGINAL_COMMAND"
 else
         $DEBUG Not passed a command.
 fi

Then you run the ssh command and see what it looks like in the log file. Copy that to your original wrapper script, and you are good to go. So

 ssh -t -i /home/raub/.ssh/le_key raub@virtualpork echo "Hey"

Results in

 Dec 26 13:34:05 virtualpork syslog[64541]: Passed SSH command echo Hey

While

 rsync -avz -e 'ssh -i /home/raub/.ssh/le_key' raub@virtualpork:Public /tmp/backup/

results in

 Dec 26 13:28:17 virtualpork syslog[64541]: Passed SSH command rsync --server  --sender -vlogDtprze.iLs . Public

The latter meaning our little wrapper script would then look like

 #!/bin/sh
 case $SSH_ORIGINAL_COMMAND in
     "rsync --server --sender -vlogDtprze.iLs . Public")
         $SSH_ORIGINAL_COMMAND
         ;;
     *)
         echo "Permission denied."
         exit 1
         ;;
 esac

///

find command:
grep "Passed SSH command" /var/log/syslog