How to estimate work for longer period when you don't have any input/metric/etc.?

Right now, I have nothing

What you have is an awareness that Story Points are being spoofed, and are really just hours in a time tracking system...quite likely for billing purposes. Why not just treat it as such, and estimate any way you see fit?

You could map your Developers' estimates, for any Sprint of known length and capacity, to the time tracking system being operated. This sort of thing isn't great, but it is a familiar challenge. I'd suggest that this pig is no different for all the lipstick the client has smeared over it.

Just for the reference, its a PO job to build relationship with a stakeholders and handle the issues with them. In fact its a primary reason Product owner exist in a Scrum team.

"where you are using Story Points as hours"

Using Scrum involves also educating stakeholders about methodology they themselves hired you and other developers to be  implemented.

And one of the basics of Scrum is that STORY POINT is not time related. Its NOT.

There is time related metric called ideal day vs real day, and using story point as measurement of time is one of the first errors which makes many projects go off the road.

Once again, PO who needs to use his diplomatic skills and connections to educate stakeholder about this issue, which is a serious problem by the way.

Also its a Scrum team, not stakeholders, who decide the duration of Sprint or whatever other tasks

if the management of company wants control, planning and hierarchy instead of self organizing Agile team, why running Scrum at all?

They can run good old PRINCE2 , waterfall project, with 15 minute daily employee drilling if they want, they can also call it "Scrum", but it is as much Scrum as the cat is a dog.

Human recourse deciding to assign or deduct story point from Scrum team is a mockery of whole methodology, and its also fault of Scrum master and Product owner who should treat this attitude as impediment and at least try educating stakeholders about the basics of methodology they are hired to run?

Basically its like early 20 century company buying a truck to bring product to the market but then, instead of driving it, running it like a cart with a horse, because management does not understand the combustion engines...

In general what you are describing is ethical problem of the professional in any industry. Someone hires you to do the job, and then tells you to do it wrongly, using "customer is a king" pressure.

Fine, but then he pays for during things wrongly, and will get wrong result in the end. So professional should at least inform his client about the error.

If they want to keep paying for error, its entirely their risk.

From what you describe there is anything but teh Scrum going on in the organization you work for.

"Product Manager from their side and he will create epic, stories"

I am sorry I missed this point..

You mean the management does not actually collect user feedback or customers commands to convert into user story's, but makes them up?

Okay...

My advice is to make one effort to explain Scrum to them, if not - work there as long as it takes to find a new, normal Scrum master position and say good buy. Possibly taking the team with you

Ok, maybe I need to give some more insight for better understanding. 

That SP system is introduced by some mambo jumbo Agile coach inside the client's organization. The logic behind it is to track everybody inside the organization and it was like an easier way for employees to better plan their work. I assume that it is something good for other departments but when it comes to development teams, it is just not good. 

We had several meetings during the last couple of months and it was either you will go like this or we will terminate the contract. I created several presentations and had 2 live ones and they will always say we understand but we will go like this. 

I don't have support from my management since this is a good client and they don't want me to make any trouble. So, what I can only do is try to find some way to help my team to do estimation and forecast as well as they can, since we don't have a commodity to miss a lot. 

@nicholas I am not sure if they have data collected from user feedback or some other channel but I know that they have fully defined all 5 components that we should work on. 

We all come across different tasks, duties and deadlines throughout our lives as professionals, now there are two approaches to find the solution to a problem.

The first approach is a reactive approach whereby we try to find a solution to the problem at hand only after it arrives.

In the second approach which can be called a Proactive Approach, we first prepare ourselves well before the problem arrives with our past experiences and then with our past experience, we try to find a solution to the challenge when it arrives. Estimation can thus be considered as a technique that is applied when we take a proactive approach to the problem.

Thus Estimation can be used to predict how much effort with respect to time and cost would be required to complete a defined task. Once the testing team is able to make an estimate of the problem at hand, then it is easier for them to come up with a solution that would be optimum to the problem at hand.

Your organization has already decided that the way you have done your work is not the way you will do the work for this client.  So, while I applaud your attempts to change the perception of your management and the client, you were unsuccessful.  So, if you want to continue to work for your current employer on this client's contract, you don't have much of a choice.  You get to call a time tracking system "estimating by Story Points".  

As with using Story Points to estimate, you can do the same with hours.  Is there a requirement that you use 1,2,3,4,5,6,7,8,... for your estimates?  Or could you estimate with 1,2,3,5,8,13?  In other words, use your current method of estimating in Story Points and then use them as estimates in hours for the client.  No one has to do anything differently. Estimates are guesses based upon information you have at the time of the estimate regardless of what unit you decide to use.

Another alternative is to look back at product backlog items that have been completed in the past.  Look at the Story Point estimates and then try to calculate the actual hours spent. Maybe use the code repository to identify time from first push of code to the last push of code for that product backlog item. Then you have some SWAG (Scientific Wild A## Guess, because you use a formula) data to come up with a conversion chart.