Developer wanting to use story point which is no Fibonacci number

Since Story Points are not part of Scrum and are not mentioned at all in the Scrum Guide, I would answer that if the Developers all agree to the practice then there is no problem.  The Scrum Master is not the individual that tells a Scrum Team how to estimate their work.  That is entirely up to the Developers to decide.  This is from the Scrum Guide section that describes the Product Backlog

The Developers who will be doing the work are responsible for the sizing. The Product Owner may influence the Developers by helping them understand and select trade-offs.

I would also point out that when Story Points were created, there was no such thing as a "reference story".  That is a practice that has been added over time.  Story Points were originally used to identify "ideal days" and didn't have any reference to other stories. 

I recommend you read this article from Ron Jeffries where he explains how he "created" story points.  It should help you better understand them. 

how to handle the situation?

What situation? The team have made a decision and the Developers are responsible for making their own estimates. What problem is there to solve?

Relative estimation is a practice where items are sized in relation to each other (larger/smaller).   The reason that the Fibonacci sequence is popular for this purpose is because it establishes larger and smaller values that are not multiples of previous values.

For example, using a value of 6 as the next highest value after 3 (i.e. - twice the size) implies a level of exactness that simply isn't there.   A team member can certainly say that one item is larger than the other, but they would be incorrect in stating that one item is double or triple the size of another item.   They simply cannot know that with any level of certainty.

And as Daniel mentioned previously, story points and relative estimation are just popular techniques that teams use, but they are not required to practice Scrum.

Many teams adopted Fibonacci to reflect the fact that the bigger the estimate the less accurate it is likely to be. If your developers are confident that their estimates are accurate they may well be thinking in terms of actual time. In that case it might be worth having a conversation around moving to time based estimates.

As others have said, its ultimately up to the developers. With more established workloads, I have had more luck with time based estimates using 1 point to represent 1/2 a day.