Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

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!

share|improve this question
3  
Tell your admin that that is an incredibly bad (and stupid) way of authenticating users. Plus the script is all sorts of broken (as dr jimbob pointed out in his answer). The proper way of doing this is to use the pam_access module. Its designed for EXACTLY this purpose. –  Patrick Jan 19 '12 at 0:03
    
@Patrick: Thanks for the advice! I feel difficult to inform my supervisor his way is bad. –  anon Jan 19 '12 at 1:47
    
Ok, you can leave out telling him its crap :-P. Just say that its causing you problems and point out the pam_access module (linux.die.net/man/8/pam_access). –  Patrick Jan 19 '12 at 3:40
    
defo. this method of authentication seems like madness. –  Sirex Jan 19 '12 at 10:38
    
@Patrick You really should tell someone why its a bad idea instead of just saying its bad and stupid. People don't react well to being told their way is stupid and then close themselves off to your reasons for why the idea is stupid. So maybe you should explain why its a bad idea and educate everyone. –  deltaray Jun 3 at 18:10

1 Answer 1

up vote 5 down vote accepted

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

Try ssh -vvv time@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.

share|improve this answer
    
Thanks! I have upload the output to here. I found that each of three lines are particularly slow. Please see my new post here. Thanks! –  Tim Jan 19 '12 at 0:32
    
@Tim - Hey made some changes (e.g., how your supervisor can fix his script; how you can just change your shell; and better methods for the supervisor to do access-control). –  dr jimbob Jan 19 '12 at 6:31
    
Thanks! I tried chsh tim -s /bin/bash, but You may not change the shell for 'tim'. –  Tim Jan 19 '12 at 15:37
    
Apparently, the supervisor setup PAM to limit normal users from using chsh. See last paragraph: en.wikipedia.org/wiki/Chsh –  dr jimbob Jan 19 '12 at 15:48

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.