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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.linux-learn.org/faqs
