On Nov 21, 2012 7:57 PM, "Paul Robert Marino" <prmari...@gmail.com> 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" <t...@fnal.gov> 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:* owner-scientific-linux-us...@listserv.fnal.gov [mailto:
>> owner-scientific-linux-us...@listserv.fnal.gov] *On Behalf Of *Joseph
>> Areeda
>> *Sent:* Wednesday, November 21, 2012 5:46 PM
>> *To:* owner-scientific-linux-us...@listserv.fnal.gov
>> *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 128.32.206.55    3 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 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 <newsre...@areeda.com>
>> 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****
>>
>> ** **
>>
>

Reply via email to