How SM should handle this situation below -

The project that you describe is a fixed-schedule project. If you look at the required work and you estimate that you can't complete it, you only have a few options. You can increase the schedule (which you say is not possible), you can reduce the scope, or maybe you can reduce the quality (but there's a floor to quality - the product still needs to be good enough for use).

Alternatively, you can educate the customers on the value of Agile Software Development. The fact you are demonstrating, if not delivering, working software on a regular basis. You'd allow the customer to provide feedback - to change their mind on what they need or the priority of the work as a regular part of the process. You can extend the project as much as desired - if the cost of executing one Sprint is worth the value that can likely be delivered, the project can be extended; if the cost is too great compared to the value, the product can be accepted.

If you're on a fixed scope and fixed schedule project, I'm not sure how useful applying Scrum will be. Scrum is designed for adapting to a changing environment. If your environment "can't" change, then maybe a framework to help you adapt to change isn't the best fit.

Also How Sprint Planning meeting should run if project is starting from scratch

Some thoughts on how to help your team get started before the first Sprint Planning:

• As SM facilitate a conversation with the Development Team around creating a definition of "Done", considering whether your organization has set such standards already. You mentioned the team is lacking technical skills so this conversation will be critical. Perhaps the first Sprint will require work to build up skills and other items (CI/CD/Automation) to have a worthwhile DoD.
• Spend time working with your Product Owner and Development Team to create enough "Ready" Product Backlog for the first Sprint, considering both functional and non functional requirements. If this is a new product, what is the minimum amount of architecture is needed to prove out at least one PBI important to the business stakeholders?
• Do these Developers have any past history of working together? If so might facilitating a conversation with them about Sprint capacity help them get started? If not you have no empirical data on capacity, and the Development Team will have to make their best guess on capacity.

Its a 3 month project only, each Sprint is 1 month long.

Who picked 1 month Sprints? Has the Scrum Team considered shorter Sprints to limit risk, since they don't have the all the technical skills? In other words, rather than wait 1 month to find out what is missing to deliver a "Done" Increment, why not consider shortening the feedback loop, make it transparent, and use the Sprint Retrospective to improve the next 2 week Sprint and the DoD? Perhaps providing transparency to the skills gap to your Product Owner and Stakeholders early could save a lot of grief and money.

How SM should handle this case?

It sounds as though scope is flexible. Why not suggest developing an MVP which helps the team to acquire the skills necessary for work to be "Done", and to refine and estimate a Product Backlog?

Its a 3 month project only, each Sprint is 1 month long.

It requires technical skills which scrum team currently don't have.

Time period of project cannot be extended to 4 months or so.   

We don't have any Past Data for this project.

What could they possibly be basing the project duration on, if there isn't any past data to guide their estimate, the scope hasn't been defined yet (starting from scratch), and the team selected to do the work doesn't have the ability to deliver?