If you're logging *into* a RHEL5.1 system with the "stock" kernel, then
you'll see this problem because the first time your home directory tries
to mount (to read the .ssh dir to get the keys) you get the ENOENT error
from the kernel and so ssh is falling back to password mode. The retry
works because the second mount attempt works fine.
Upgrade your 5.1 system's kernel to 2.6.18-53.1.4 or later and the
problem should go away.
If you're seeing this problem logging *into* a RHEL5.0 system, then this
may be some other issue, because 5.0 did not have the particular bug
mentioned above. But 5.0 was pretty sketchy, IMHO. NFS/autofs
problems, Xen problems, etc. I'm avoiding 5.0 and starting out with 5.1
directly (with the updated -53.1.4 kernel).
Paul Krizak 5900 E. Ben White Blvd. MS 625
Advanced Micro Devices Austin, TX 78741
Linux/Unix Systems Engineering Phone: (512) 602-8775
Silicon Design Division Cell: (512) 791-0686
Peter Sobisch wrote:
On Thu, Dec 06, 2007 at 02:44:21PM +0900, Ian Kent wrote:
[...]
At first some words about our environment:
one server with RHEL5, connected to SAN (FC), this server is our
fileserver, exporting a couple of nfs shares (incl. home directories),
we use automount on the client machines, which are also RHEL5.
Automount and credentials are distributed by nis.
We use ssh (public key) to start remotely applications on some clients
without password.
Well, our Problems are:
1) very often some processes on the clients complain about missing
files, which are definitively there.
If we retry to run the process everything runs well.
This is the first time I've heard this reported but this isn't really
enough information to understand even the source of the problem.
Do you have a bug logged for this?
not yet. I just want to make sure, if it is a bug or not.
Maybe a setting mistake, but the previous version went well.
2) somethimes the ssh command line tool asks for password
than, after pressing Ctrl+C and retry, ssh runs as usual,
without query the password.
We have Nagios running here, which is testing several services
and after upgrade to RHEL5 we're getting a couple warnings that
our "ssh" service on a RHEL5 box doesn't answer. The next check
is good one. Very strange.
What kernel revision are you using?
There is a known problem with kernel shipped with 5.1.
You need to be using revision 53.1.4 or later with RHEL-5.1.
here, just tried to login from RHEL5.0 to RHEL5.1 via ssh to check
the kernel version, the ssh-problem occurred:
-------snip--------
[EMAIL PROTECTED]:~] ssh cp5
[EMAIL PROTECTED]'s password:
[EMAIL PROTECTED]:~] ssh cp5
Last login: Wed Dec 5 18:18:54 2007 from srv1
DISPLAY is: srv1:0.0
[EMAIL PROTECTED]:~] uname -a
Linux cp5 2.6.18-53.el5 #1 SMP Wed Oct 10 16:34:02 EDT 2007 i686 i686 i386
GNU/Linux
-----snap-----
kernel version of our RHEL5.0 is:
Linux srv1 2.6.18-8.el5PAE #1 SMP Fri Jan 26 14:28:43 EST 2007 i686 i686 i386 GNU/Linux
Is it an option, that our ssh-problem occures because of the missing
file problem (because the sshd cannot find user's "authorized_keys" file
?
We use automount to mount /somewhere/home which contains all our home
directories.
But we didn't have any problems with automount for years, we setup this
on SunSolaris 5.6, than some years later we replaced SUN by x86 with
RHEL4U1, than a half year later we did an upgrade to RHEL4U3 and than a
year later or so to RHEL5. We didn't have a problems prior to RHEL5.
We didn't change the timeout value of auto unmount.
best regards
Peter
_______________________________________________
rhelv5-list mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/rhelv5-list
_______________________________________________
rhelv5-list mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/rhelv5-list
