Re: Some users locked out of ssh and sftp?

[Eric Bambach <eric@cisu.net>]

On Tuesday 01 March 2005 10:59 am, Ray Olszewski wrote:
> At 08:22 AM 3/1/2005 -0800, Eve Emshoff wrote:
> >This isn't making sense to me. I have users logging in
> >via SSH to a redhat linux box using their network
> >username/password. I'm able to do it as are most
> >others, either locally or remotely. ie:
> >
> >ssh -l eve <ipaddress>
> >or
> >sftp eve@<ipaddress>
> >
> >Thus far, I've run across 1 user who can't sftp OR
> >SSH. He's entirely locked out, despite having the
> >correct username and password. He appears to be set up
> >the same as well the others.
> >
> >Is there a file or some such I should edit and/or
> >check to ensure he can get access? Anything to point
> >me to in terms of what I can check in that he may
> >*not* be set up the same as everyone else?
>
> Ok. First thing to do is get his password and make sure that *you* can ssh
> in using the same userid and password he is using. If you can, then you are
> either seeing some sort of user error or a problem associated with the site
> he is trying to connect *from*. (It's hard to come up with an example of
> the second, but I can imagine that an ISP might block traffic to port 22
> for some reason that does not occur to me ... although if "entirely locked
> out" means he is prompted for a password, then rejected, that example does
> not apply.)
>
> (BTW, what do you mean by "network" username/password? Does this host use
> something other than the standard files /etc/passwd and /etc/shadow for
> userid and password? For example, is NIS involved somehow, or some LDAP
> gimmickry? If so, and if you decide to post a followup, please clarify this
> part.)
>
> (Also, you say "most others" can log in. Is this just caution in reporting,
> or do you have other reports of unexplained failures?)
>
> If you can log in and you want to explore the possibility that the problem
> is NOT user error, then to get help here you'll need to say more about the
> failure he is seeing.
>
> Once you've verified for yourself that the userid/password combo does not
> work for you either, first check that this userid/password combo can do a
> normal shell login. If it can't, try (as root) chainging the password, to
> see if the problem is nothing more than the user having misremembered his
> password. Also check his entry in /etc/passwd to make sure a valid shell
> (/bin/bash, usually) is provided ... it has to be something listed in
> /etc/shells .
>
> If the ssh problem remains after a password change (but the local login
> problem is fixed, or if local logins always worked so you skipped this
> step), the check the sshd config file (not sure where Red Hat keeps this,
> but maybe /etc/ssh/sshd_config ... that's where Debian puts it, anyway) and
> see if something there is interfering. For example, the entry
>
>          PermitRootLogin no
>
> blocks root logins via ssh. More generally, the entries
>
>          AllowUsers
>
> and
>
>          DenyUsers
>
> followed by a pattern or list can restrict which userids are allowed or
> forbidden to ssh in.
>
> These are the easy examples. There is too much more to say ... read the man
> page for sshd_config if you want a general intro ... without a more
> specific indication of what the problem actually looks like (more than
> "entirely locked out", I mean), which could narrow the possibilities.
>
> I've focused on ssh here because it is a bit easier to troubleshoot. But
> all the same considerations should apply to sftp as well ... that is, once
> you get ssh logins working, sftp should also work ... they use the same
> authentication mechanism and tunneling.

Besides all of Ray's perfectly good suggestions I have something to add.

Check the permissions on his/her ~/.ssh directory. If the permissions somehow 
became world write/readable ssh will refuse to log that person in. Check the 
log files too! If ssh is logging its failures it can tell you a whole lot!

If you can, try running ssh on an alternate port in debugging mode and logging 
in as that user. That way you can see where/why ssh is failing.

However, try to log the user in locally first because if its a local problem 
then fiddling with SSH wont do anything. Also if its a local problem and you 
fix it then SSH should work itself out.

-- 
----------------------------------------
--EB

> All is fine except that I can reliably "oops" it simply by trying to read
> from /proc/apm (e.g. cat /proc/apm).
> oops output and ksymoops-2.3.4 output is attached.
> Is there anything else I can contribute?

The latitude and longtitude of the bios writers current position, and
a ballistic missile.

                --Alan Cox LKML-December 08,2000 

----------------------------------------
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs