ssh & telnet troubles (want users to have a bash shell) when using PAM/NSS with LDAP Authentication

Hi all,

I have PAM/NSS set up on my RedHat 9 system.  I have a LDAP server containing user information set up on a separate system.   The only difference in LDAP accounts between userA and userB is that userA does not have a 'loginShell' attribute while userB has a "loginShell=/bin/bash".

When I telnet or ssh in as userA, everything works fine and I am in a sh shell.  When I telnet in as userB, everything works and I am dropped into a bash shell.  When I ssh in as userB, I receive an error in the /var/log/secure file:  
sshd[2388]: User userB not allowed because shell /bin/bash  does not exist

ll /bin/bash:
-rwxr-xr-x    1 root     root       626028 Feb 11  2003 /bin/bash


Questions:
1) How can I get a user my users to drop into a bash shell when they telnet or use ssh?
2) Why does userA get dropped into a sh shell?

Thanks in advance!
diamond1Asked:
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

x
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

jlevieCommented:
Obviously, /bin/bash does exist and has the correct perms. Could it be that the LDAP records isn't exactly /bin/bash?
ahoffmannCommented:
the shell is specified in /etc/passwd
when you get get the sshd error, it's either 'cause the path to the shell is wrong, or 'cause it's not listed in /etc/shells
ahoffmannCommented:
oops, didn't see the LDAP
So my /etc/passwd suggestion is wrong, you need to heck the LDAP database
Sorry.
IT Pros Agree: AI and Machine Learning Key

We’d all like to think our company’s data is well protected, but when you ask IT professionals they admit the data probably is not as safe as it could be.

diamond1Author Commented:
/bin/bash is one of the available shells:
[root@x-dhcp-x-x-x sysconfig]# cat /etc/shells
/bin/sh
/bin/bash
/sbin/nologin
/bin/bash2
/bin/ash
/bin/bsh
/bin/tcsh
/bin/csh

I will keep looking into the LDAP end of things for an answer.  Thanks for the replies.
majorwooCommented:
check that /bin/bash is not a symlink
majorwooCommented:
ok, I'll join ahoffmann in the correcting ourselves dept, looks like you listed it
diamond1Author Commented:
Yes, just to clarify, /bin/bash is not a symlink.
ahoffmannCommented:
.. and what is in you ldap entry? can you please post the results of a ldapsearch.
diamond1Author Commented:
I pasted the two entries from a ldapsearch that I am concerned with below. The difference between the two users is that userB has a loginshell attribute while userA does not.  

dn: uid=userA,ou=people,dc=BBC,dc=com
uid: userA
cn: John A Smitch
userPassword:: e2NyeXB0fUFCcVpTckZPNlVOZTY=
uidNumber: 500
gidNumber: 500
homeDirectory: /home/john
objectClass: posixAccount
objectClass: account
objectClass: top

dn: uid=userB,ou=people,dc=BBC,dc=com
uid: userB
cn: John B Smitch
userPassword:: e2NyeXB0fUFCUHpyVERvcE5yMFk=
uidNumber: 500
gidNumber: 500
homeDirectory: /home/john
loginShell:: L2Jpbi9iYXNoIA==
objectClass: posixAccount
objectClass: account
objectClass: top

From /etc/passwd:
john:CDuRnyJpg:500:500:John Smith:/home/john:/bin/bash

when I SSH to the client system, I do something like:  ssh -l userA 10.1.1.1
The shell I get dropped into (with either telnet or ssh) has a prompt like the following:  -sh-2.05b$

SSH with userB does not work.  telnet with userB drops me into a bash shell ([john@10.1.1.1 john]$)

I want to get dropped into a bash shell with both telnet and ssh.  I believe ahoffmann is correct in that I need to keep looking at the LDAP end of things.  



ahoffmannCommented:
your value of the loginShell attribute is encoded. Is that correct?
jlevieCommented:
"loginShell:: L2Jpbi9iYXNoIA==" is bogus data and it explains why userB has problems. I'm guessing here, but I believe that user john doesn't get the shell prompt that you expect because the LDAP data for the account is incomplete (loginShell is missing). That might means that john's login doesn't correctly set up his home dir and thus the shell init scripts aren't run. That theory is supported by the shell prompt that john sees. The Bash version on RedHat 9 is 2.05b, which matches the prompt.

I could be wrong, but my understanding is that when you use LDAP for authentication the passwd file isn't consulted at all. So the LDAP data must include the mandatory fields of a password entry (login name, UID, GID, Gecos, home dir, and shell).
diamond1Author Commented:
I have been assuming that the loginShell is  encoded.

ldapsearch -x -b "dc=BBC,dc=com" "(loginShell=/bin/bash)" will return me the data for userB.

When I created the data for userB, I created a *.ldif file with my the user information including a plain text loginShell attribute for userB.  Then I added the data with the following command:

ldapmodify -x -D "cn=Manager,dc=BBC,dc=com" -w secret > -x -a -f users.ldif

The loginShell for userB always shows up as displayed in the above e-mail.    Since the ldapsearch command works fine, I assumed the loginShell was encoded automatically by the server.  I will investigate the settings on my server and see if I can come up with a definitive answer.

In my case, the passwd file is not consulted, only LDAP is used for authentication.
diamond1Author Commented:
Aha!  I have cleared up some of my confusion.

On the client system, I can do a 'finger username' and see that the shell for userA is listed as /bin/sh while the shell for userB is listed as /bin/bash.  I believe this is due to me specifying or not specifying the loginShell attribute on the LDAP server.  

 from the man pages:  
when bash is invoked it reads from: /etc/profile,  ~/.bash_profile, ~/.bash_login, and ~/.profile.  
when invoked with the name sh it reads from /etc/profile and ~/.profile

So, this explains why my prompt looks different between the two users: -sh-2.05b$ versus [user@host dir]$

I still need to keep researching why the user with a /bin/bash shell gets errors when trying to ssh.  
pjedmondCommented:
I trust that both your users are not both uid 500?

For user A (because no explicit shell is given)  assumes the default shell (sh). I have tested this by removing the shell attribute for my RH9 system, and this is indead the case.

As for user B, it enters the bash shell as specified when telnetting, so obviously /bin/bash exists and is useable. Therefore the only thing I can think of is that a chroot type process is being carried out meaning that the original /bin/bash is no longer visible. (Might be an idea to copy /bin/bash to ~/bin/bash and see what happens).

If you remove the shell from user B, then I assume that that you end up logging in in exactly the same way as for user A.

Just curious....but if you try logging in as UserA and enter the command:

chsh

(change shell)...can you change to /bin/bash, without messing around with the LDAP entries manually. In which case you should be able to create a 'template' user with bash login that you can then duplicate?

HTH:)
MarkLead Sales Engineer - Public SectorCommented:
This is a complete wild guess here...

The problem appears to be related to SSH access. Is SSHD running in a chrooted jail? If so, is there a ./bin/bash available inside the jail?
diamond1Author Commented:
Thanks for the responses.  I apologize for taking so long to get back to you.  I got sidetracked on a different project.

pjedomnd - in answer to your questions:

-- Both users are UID 500.  I want individuals to log in with their user name (so it gets logged in the log file) but then be dropped into one standard account.  This way I only need one account on a Linux system & I can tell which individual logged into the system by looking in the log files.
--  if I remove the LoginShell attribute from user B, I log in exactly the same way I do with user A.
-- I copyied /bin/bash to ~/bin/bash.  I still received a "shell /bin/bash does not exist" for user B when I try doing ssh.
-- if I try to do a chsh as user A, I enter a password, then the line says "New shell [/bin/bash]:".  I hit the return key, I do not get any error messages and I am still in the sh shell.  I tried typing in /bin/bash at the "New shell" prompt but received the same results.

mburdick -- I have been looking around on the internet but haven't been able to determine whether sshd is running in a chrooted jail or not.  I will continue searching for this.
diamond1Author Commented:
I have yet so solve my problem.  I thank you all for your time and suggestions.  I am going to close the question but I will give each of you points for your help.  Thanks!!
diamond1Author Commented:
I have not found an answer to my original question as to why the user with a /bin/bash shell can not use SSH.  I believe I do understand why the two users end up with different shells when they log in (see my post on 11/05/03).  

I am giving up on using a /bin/bash shell and will use the /bin/sh instead.  The users in ldap will not have a login shell attribute so they will automatically be dropped into the /bin/sh shell.  I asked that the question be closed since it has been open for almost 3 months and I can live with using a /bin/sh shell.  

Thanks for all the assistance.
ahoffmannCommented:
do experts agree with 0 points PAQ, refund?
jlevieCommented:
Yes.
LunchyCommented:
PAQed at expert recommendation, with points refunded (150)

Lunchy
Friendly Neighbourhood Community Support Admin

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Linux Security

From novice to tech pro — start learning today.