Thank you Paul, Steven and Steve,
I think Kerberos may be the issue. I do NOT use Kerberos to access this
machine, I have a lot to learn before I turn that and LDAP on. But I do
use it to access several services in our collaboration so the client
machine often has a valid Kerberos TGT (and probably more often an
expired ticket). I think it's worth experimenting with the client in
different states of Kerberosity (or whatever that word should be).
The user's directory is 755 which is the convention for grid computers
in our collaboration and the plan is for this machine to be on our soon
to be delivered cluster. The .ssh directory is 700. This doesn't
change between the working and non-working state.
I tarred the /etc/ssh directory and saved it for next time but wouldn't
generating new keys make them almost completely different? Generating
new keys makes no sense to me either, but it does work. Well, at least
it has been the only thing I've done coincident with resolving the
problem the last 3 times this has happened.
I also save the triple verbose ssh output.
I really appreciate the discussion gentlemen, it helps a lot.
Best,
Joe
On 11/21/2012 04:58 PM, Paul Robert Marino wrote:
On Nov 21, 2012 7:57 PM, "Paul Robert Marino" <[email protected]
<mailto:[email protected]>> wrote:
Ok
To be clear are you using kerberos or not
If the answer is no and you are just using ssh keys the most
common cause of this issue is that the useres home directory is
group or world readable. In the most secure mode which is the
default if the useres home and or the ~/.ssh directory is has a
any thing other than 700 or 500 set as the permissions it will
reject the public key (the one on the server you are trying to
connect to) this become obvious with -vvv but not -vv
On Nov 21, 2012 7:34 PM, "Steven C Timm" <[email protected]
<mailto:[email protected]>> wrote:
Shouldn’t need to regenerate the keys.. once you get them
generated once they should be good for the life of the machine.
Save copies of the keys as they are now and if your system
goes bad, do differences to see what changed, if anything.
Steve Timm
*From:*[email protected]
<mailto:[email protected]>
[mailto:[email protected]
<mailto:[email protected]>] *On
Behalf Of *Joseph Areeda
*Sent:* Wednesday, November 21, 2012 5:46 PM
*To:* [email protected]
<mailto:[email protected]>
*Cc:* scientific-linux-users
*Subject:* Re: ssh returns "Permission denied
(gssapi-keyex,gssapi-with-mic)."
Thank you Tam, and Steven,
I just confirmed that regenerating the keys (ssh-keygen -t dsa
-f ssh_host_dsa_key && ssh -t rsa -f ssh_host_rsa_key) in
/etc/ssh "fixes the problem"
So ssh -vv shows me how it's supposed to look. I'll save that
and do a diff when it happens again.
As I continue my googling I can report on a few things it's not
Server machine has a fixed ip address and dns/rdns appears
working.
Time issue Steven mentioned does not seem to be it, although I
may stop using pool machines and set up a local ntp server so
everybody gets the same time. I can ssh and gsissh to other
servers.
Server:
ntpq -p
remote refid st t when poll reach
delay offset jitter
==============================================================================
*ping-audit-207- .ACTS. 1 u 5 128 377
19.867 5.804 1.927
+10504.x.rootbsd 198.30.92.2 2 u 129 128 376 45.146
-28.571 5.558
+ntp.sunflower.c 132.236.56.250 3 u 77 128 355 63.836
-14.753 5.360
-ntp2.ResComp.Be <http://ntp2.ResComp.Be> 128.32.206.55 3
<tel:128.32.206.55%C2%A0%C2%A0%C2%A0%203> u 126 128 377
22.112 7.311 2.022
Client:
ntpq -p
remote refid st t when poll reach
delay offset jitter
==============================================================================
64.147.116.229 .ACTS. 1 u 47 128 0
13.543 0.567 0.000
*nist1-chi.ustim .ACTS. 1 u 25 128 377
106.619 14.458 5.896
+name3.glorb.com <http://name3.glorb.com> 69.36.224.15 2
u 64 128 377 88.564 -27.542 3.631
+131.211.8.244 .PPS. 1 u 81 128 377
167.107 3.259 2.340
The only setting I change in sshd_config is to turn off
password auth but this machine is being brought up behind a
firewall and I haven't done that yet. Also if it was a config
problem I doubt changing the key would fix it, even temporarily.
I will report back with the ssh -vv stuff when it happens again.
At least now I have a chance of figuring out what's going on.
Best,
Joe
On 11/21/2012 02:30 PM, Tam Nguyen wrote:
Hi Joe,
Did you look at the sshd_config file?
I ran into a similar error output but it may not necessarily
be the same issue you're having. In my case, the sshd_conf
file on one of my users machine was edited and renamed. I
backup that file and copy a default sshd_config file, then
test it.
Good luck.
-T
On Wed, Nov 21, 2012 at 5:16 PM, Joseph Areeda
<[email protected] <mailto:[email protected]>> wrote:
I can't figure out what causes this error.
I can "fix" it by regenerating the server key on the system
I'm trying to connect to and restarting sshd but that seems to
be temporary as the same problem comes back in a week or so.
Rebooting the server does not fix it.
Does anyone know what that error means? I am using ssh not
gsissh although I do have globus toolkit installed to contact
grid computers.
I'm pretty sure it's a misconfiguration on my part but I can't
figure out what I did or didn't do.
Thanks,
Joe
