Re: BUG #51821 - client is using insecure global_id reclaim

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I have had the same issue with the windows client.  
I had to issue 
	ceph config set mon auth_expose_insecure_global_id_reclaim false
Which allows the other clients to connect.  
I think you need to restart the monitors as well, because the first few times I tried this, I still couldn't connect.

-----Original Message-----
From: Richard Bade <hitrich@xxxxxxxxx> 
Sent: Sunday, August 8, 2021 8:27 PM
To: Daniel Persson <mailto.woden@xxxxxxxxx>
Cc: Ceph Users <ceph-users@xxxxxxx>
Subject:  Re: BUG #51821 - client is using insecure global_id reclaim

Hi Daniel,
I had a similar issue last week after upgrading my test cluster from
14.2.13 to 14.2.22 which included this fix for Global ID reclaim in .20. My issue was a rados gw that I was re-deploying on the latest version. The problem seemed to be related with cephx authentication.
It kept displaying the error message you have and the service wouldn't start.
I ended up stopping and removing the old rgw service, deleting all the keys in /etc/ceph/ and all data in /var/lib/ceph/radosgw/ and re-deploying the radosgw. This used the new rgw bootstrap keys and new key for this radosgw.
So, I would suggest you double and triple check which keys your clients are using and that cephx is enabled correctly on your cluster.
Check your admin key in /etc/ceph as well, as that's what's being used for ceph status.

Regards,
Rich

On Sun, 8 Aug 2021 at 05:01, Daniel Persson <mailto.woden@xxxxxxxxx> wrote:
>
> Hi everyone.
>
> I suggested asking for help here instead of in the bug tracker so that 
> I will try it.
>
> https://tracker.ceph.com/issues/51821?next_issue_id=51820&prev_issue_i
> d=51824
>
> I have a problem that I can't seem to figure out how to resolve the issue.
>
> AUTH_INSECURE_GLOBAL_ID_RECLAIM: client is using insecure global_id 
> reclaim
> AUTH_INSECURE_GLOBAL_ID_RECLAIM_ALLOWED: mons are allowing insecure 
> global_id reclaim
>
>
> Both of these have to do with reclaiming ID and securing that no 
> client could steal or reuse another client's ID. I understand the 
> reason for this and want to resolve the issue.
>
> Currently, I have three different clients.
>
> * One Windows client using the latest Ceph-Dokan build. (ceph version
> 15.0.0-22274-g5656003758 (5656003758614f8fd2a8c49c2e7d4f5cd637b0ea) 
> pacific
> (rc))
> * One Linux Debian build using the built packages for that kernel. (
> 4.19.0-17-amd64)
> * And one client that I've built from source for a raspberry PI as 
> there is no arm build for the Pacific release. (5.11.0-1015-raspi)
>
> If I switch over to not allow global id reclaim, none of these clients 
> could connect, and using the command "ceph status" on one of my nodes 
> will also fail.
>
> All of them giving the same error message:
>
> monclient(hunting): handle_auth_bad_method server allowed_methods [2] 
> but i only support [2]
>
>
> Has anyone encountered this problem and have any suggestions?
>
> PS. The reason I have 3 different hosts is that this is a test 
> environment where I try to resolve and look at issues before we 
> upgrade our production environment to pacific. DS.
>
> Best regards
> Daniel
> _______________________________________________
> ceph-users mailing list -- ceph-users@xxxxxxx To unsubscribe send an 
> email to ceph-users-leave@xxxxxxx
_______________________________________________
ceph-users mailing list -- ceph-users@xxxxxxx To unsubscribe send an email to ceph-users-leave@xxxxxxx
_______________________________________________
ceph-users mailing list -- ceph-users@xxxxxxx
To unsubscribe send an email to ceph-users-leave@xxxxxxx



[Index of Archives]     [Information on CEPH]     [Linux Filesystem Development]     [Ceph Development]     [Ceph Large]     [Ceph Dev]     [Linux USB Development]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [xfs]


  Powered by Linux