Usually in the 'vanilla' SCRUM the technical tasks you mentioned will not go as separate stories.
To me the non-technical PO should not be looking at the stories like 'Upgrade the server'. It's not a business story, it is not visible to the end-user so it is difficult to prioritize if it is formulated this way. Priorities should be assigned according to the business value of the work. 'Upgrading' does not mean much. 'Allowing more simultaneous connections', 'Reducing the downtime' or even 'improving the team velocity' might provide much more valuable insight to a non-technical person. If you cannot find a non-technical description ask yourself a question about the necessity of the upgrade :)
The 'refactoring' story is even more complicated. Did you ask yourself why is it a story at all? Refactoring could be done as a task in the story but it is rarely a story on itself. So if you want to make login work better or provide more features that's a story but tinkering under the hood does not count as one. Please also note that refactoring without a business purpose could easily lead to a so-called 'gold plating'
I would suggest doing the 'upgrade' stories as a spike with the 'improve performance' and 're-factor' being the tasks for a relevant business story.
P.S. You might find a good discussion on this topic (mostly in part 3 of it) in the excellent book by Mike Cohn called "User Stories Applied: For Agile Software Development".