Is my default remote shell a trouble maker?

Question

By finger tim on the server, I learned that my default shell is some script /usr/local/bin/bash-wrapper whose content is:

#!/bin/bash

USERNAME=`whoami`

if ! grep ^$USERNAME$ /etc/domain-users > /dev/null; then
   echo -e "You are not authorized to log into this server\n\n"
elif test -z "$2"; then
   echo -e "User authorized"
   /bin/bash
else #in case users are trying to send a command via ssh or use scp
   $2
fi

I now understand the script is the cause of me previously being kicked out upon logging in using ssh. The problem is now gone, because I was just recently added to that file /etc/domain-users which grep is searching in.

Now my questions are:

1. What does the script do if I send a command for the server shell to run in the same line as ssh, such as the following two questions Part 2 and Part 3?

2. Is it the cause of the failure of my copy of public key:

   $ cat /home/tim/.ssh/id_rsa.pub | ssh tim@server 'cat >> .ssh/authorized_keys'
   Password: 
   cat: >>: No such file or directory
   cat: .ssh/authorized_keys: No such file or directory
   

   I also tried ssh-copy-id, but it doesn't work either:

   $ ssh-copy-id tim@server
   Password: 
   /usr/local/bin/bash-wrapper: line 11: umask: 077;: octal number out of range
   

3. The following ssh-tunneling command doesn't run well from my local either:

   ssh -f -D 9999 tim@server "if [ -f ~/.tunnel ]; then rm ~/.tunnel; fi; while [ ! -f ~/.tunnel ]; do echo > /dev/null; done"
   

   Here is the error that I get

   /usr/local/bin/bash-wrapper: line 11: if: command not found
   

   I wonder why?

4. My login is always very slow. Is it because the grep takes time? Note that the file /etc/domain-usersin which grep searches has 199 lines and each line is a username. Is it supposed to take long for grep to do its job?

5. How can I change my default shell?

Thanks and regards!

Answer 1

Grepping through a 200 line file should take millisecond or so, so I would doubt its that.

Try ssh -vvv tim@server to see what's slowing it down.

Your default shell is saved in /etc/passwd at the end of your line:

drjimbob:x:1000:1000:jim bob,,,:/home/drjimbob:/bin/bash

and can be changed by chsh tim -s /bin/bash (change shell) though you typically have to have root privileges to change your default shell, which you can do if you have your user's password (you do not need root permission).

Note, that /usr/bin/ssh-copy-id is just a script and the line that's getting you in trouble is:

{ eval "$GET_ID" ; } | ssh ${1%:} "umask 077; test -d .ssh || mkdir .ssh ; cat >> .ssh/authorized_keys" || exit 1

If you test this; with a script like test_script.sh

#!/bin/bash

umask 077; echo "Works fine"
$2

and run it like bash -v -x test_script.sh "ignored_first_parameter" "umask 077; echo 'no'"

You'll see that the bash tokenization (based on the environmental variable $IFS) of the variable "umask 077; echo no" into the second parameter and then shell expansion told bash to run the command umask '077;' which gives the error.

It's basically due to the fact that typing into bash command1; command2 is fundamentally different than setting a variable some_var='command1; command2" and then running $some_var.

See: http://www.gnu.org/software/bash/manual/bashref.html

---

EDIT: To address your specific questions;

(1) I still think this method of access control is suspect and possibly circumvented by one of the standard tricks if a user has some other sort of access. Let's say they have ftp access to their user directory; they could potentially upload a .login file (containing a fake $PATH and a fake whoami) that lets them login.

At the very least the script should specify the full path of whoami (on my ubuntu machine its /usr/bin/whoami; may vary on different systems). See: Secure Programming for Linux Ch 5.2.

It seems cleaner to disable the shell for users who can't login (e.g., set the shell to /bin/false in /etc/passwd for users not in your list). Alternatively (or additionally), if you are only worried about remote logins, possibly use a setting in /etc/ssh/sshd_config to use some combination of AllowUsers/AllowGroups to whitelist users/groups or DenyUsers/DenyGroups to blacklist users/groups to ssh (though noting that these users could login if the have physical access to the machine).

However, if your supervisor modified their script to use eval $2 it should fix the immediate issues with ssh-copy-id. See Bash: why use eval with variable expansion.

#!/bin/bash

USERNAME=`whoami`

if ! grep ^$USERNAME$ /etc/domain-users > /dev/null; then
 echo -e "You are not authorized to log into this server\n\n"
elif test -z "$2"; then
 echo -e "User authorized"
 /bin/bash
else #in case users are trying to send a command via ssh or use scp
 eval $2
fi

For questions 2-5; the answers, (2) yes, (3) yes, (4) no, (5) chsh tim -s /bin/bash.