In your sshd_config did you identify the users who are allowed to connect?

# Authentication:  
Allowusers testuser  
No I have not update sshd_config file with "Allowsusers". In your example, it's limited to the testUser, what if I want "all" users?    

Update: Tried to connect on the same network i.e, both machines are now on same network and it worked fine with SSH.    

However, when source and destination are on different network, permissions denied error continue to appear.    

Will check the logs on other network...
											
Are you sure there are no port restriction on any router/firewalls between the two networks? How about the Windows firewall on the remote machine?    
SSH requires port 22 to be open -- unless the server on the remote machine is listening on some other port.
											
Following rule were created and I confirmed it exists on server side:     
New-NetFirewallRule -Name SSH -DisplayName 'OpenSSH SSH Server Port' -Enabled True -Direction Inbound -Protocol TCP -Action Allow -LocalPort 22 -Program "C:\System32\OpenSSH\sshd.exe"    
Per my understanding, remote PC is a Windows client configured with a static WAN IP address which is used by source PC to connect over SSH and SCP. So, best of my knowledge, there is remote PC is not directly connected to any router or firewall.
											
Use Powershell's test-netconnection to verify network connectivity and that you can ping the remote machine and connect to port 22.     
https://learn.microsoft.com/en-us/powershell/module/nettcpip/test-netconnection?view=windowsserver2019-ps    
											
Didn't you say they were on two different networks? Unless there's some sort of black magic happening there's a router that connects the two networks -- and routers usually act as firewalls, too.    
Have you tried using another SSH client on your machine? "Putty" a good one (putty.org)    
											
That's correct that source and destination machines are on different network. And when devices are on same network, it worked fine.    

Have checked with TeraTerm (similar to putty) and received Time Out error message.    

So I suspect having a machine configured with a static WAN address is not enough to achieve what  I want?    
											
Is the source PC accessing the destination PC via the internet? If you browse https://canyouseeme.org on the destination machine, enter 22 in the "port to check' field. if the Ip address that the page reports is the same IP that ipconfig shows, then you are directly connected to the internet and you will need to check the Windows firewall settings. If it shows a different ip, then the destination Pc is behind some firewall/router and you will need to enable port forwarding for port 22.    
											
Is the source PC accessing the destination PC via the internet? >> YES    
If you browse https://canyouseeme.org on the destination machine, enter 22 in the "port to check' field. >> YES    

Same IP address and listening on port 22 >>    
Source can PING remote IP >> NO    

WARNING: Ping to XX.XX.XX.XX failed with status: TimedOut    
											
Do you have any Linux machines available? The Microsoft "tracert" command is lacking the necessary means to help here. And the PowerShell 5 Test-Connection lacks the ability to specify the use of TCP or to select a specific port for the test.    
From any *nix machine, this might tell you where your problem is coming from: traceroute -T -p 22 www.example.com by showing you the last IP address that allowed port 22 to pass.    
You may be encountering a firewall or an intrusion detection system. They may allow you to connect to port 22 but intercept any encrypted packets, or they may simply not respond.    
											
Are these company networks? Or are they networks connected by consumer ISPs?    
If these are company networks, contact the network admin(s) for help. If they're consumer ISP networks you may have to resort to using a VPN (another client/server pair), in which case you'd be able to use whatever you want to allow on the server side. No need for further encryption, so you use PowerShell to do the file movement.
			 
i just ran some tests and that Pubkey statement is not the problem. I was not able to login with my admin account, so I had to comment out the AllowUsers because it was only letting my testuser in.      
Add these 2 lines to your config.     
SyslogFacility LOCAL0    

LogLevel Debug1    
Then recycle the sshd service and try to log in again. Check for errors in the C:\ProgramData\ssh\logs\sshd.log file.     
Here is my sshd_config file. (Update; I used Filezilla and connected via SFTP.)    
# This is the sshd server system-wide configuration file.  See  
# sshd_config(5) for more information.  
# The strategy used for options in the default sshd_config shipped with  
# OpenSSH is to specify options with their default value where  
# possible, but leave them commented.  Uncommented options override the  
# default value.  
#Port 22  
#AddressFamily any  
#ListenAddress 0.0.0.0  
#ListenAddress ::  
#HostKey __PROGRAMDATA__/ssh/ssh_host_rsa_key  
#HostKey __PROGRAMDATA__/ssh/ssh_host_dsa_key  
#HostKey __PROGRAMDATA__/ssh/ssh_host_ecdsa_key  
#HostKey __PROGRAMDATA__/ssh/ssh_host_ed25519_key  
# Ciphers and keying  
#RekeyLimit default none  
# Logging  
#SyslogFacility AUTH  
# Local0 is the log folder  
SyslogFacility LOCAL0  
LogLevel Debug1  
# Authentication:  
#Allowusers testuser  
#LoginGraceTime 2m  
#PermitRootLogin prohibit-password  
PermitRootLogin yes  
#StrictModes yes  
#MaxAuthTries 6  
#MaxSessions 10  
PubkeyAuthentication yes  
# The default is to check both .ssh/authorized_keys and .ssh/authorized_keys2  
# but this is overridden so installations will only check .ssh/authorized_keys  
AuthorizedKeysFile .ssh/authorized_keys  
#AuthorizedPrincipalsFile none  
# For this to work you will also need host keys in %programData%/ssh/ssh_known_hosts  
#HostbasedAuthentication no  
# Change to yes if you don't trust ~/.ssh/known_hosts for  
# HostbasedAuthentication  
#IgnoreUserKnownHosts no  
# Don't read the user's ~/.rhosts and ~/.shosts files  
#IgnoreRhosts yes  
# To disable tunneled clear text passwords, change to no here!  
PasswordAuthentication yes  
#PermitEmptyPasswords no  
# GSSAPI options  
#GSSAPIAuthentication no  
#AllowAgentForwarding yes  
#AllowTcpForwarding yes  
#GatewayPorts no  
#PermitTTY yes  
#PrintMotd yes  
#PrintLastLog yes  
#TCPKeepAlive yes  
#UseLogin no  
#PermitUserEnvironment no  
#ClientAliveInterval 0  
#ClientAliveCountMax 3  
#UseDNS no  
#PidFile /var/run/sshd.pid  
#MaxStartups 10:30:100  
#PermitTunnel no  
#ChrootDirectory none  
#VersionAddendum none  
# no default banner path  
#Banner none  
# override default of no subsystems  
Subsystem sftp sftp-server.exe  
# Example of overriding settings on a per-user basis  
#Match User anoncvs  
# AllowTcpForwarding no  
# PermitTTY no  
# ForceCommand cvs server  
Match Group administrators  
       AuthorizedKeysFile __PROGRAMDATA__/ssh/administrators_authorized_keys  
Match user testuser  
       ChrootDirectory c:/temp  
even I am sure that password I am using is correct    
Check the Security eventlog for logon errors.    
Check the OpenSSH server logs for errors.     
https://github.com/PowerShell/Win32-OpenSSH/wiki/Logging-Facilities    
			 
Before trying to use scp, try logging on to the remote machine using ssh. If ssh doesn't work there's is no hope of scp succeeding.    
Are the machines in a workgroup or a domain?
											
There should be some event on the destination server that documents what it didn't like. Unknown user, bad password, account disabled, something. You have to find that error so that you know what needs fixed. We can't help you based on an error description of "permission denied". It's just too vague and we don't know anything about your environment.     
Look in the security eventlog, look in the SSH eventlogs.  
											
Update: Tried to connect on the same network i.e, both machines are now on same network and it worked fine with SSH.    

However, when source and destination are on different network, permissions denied error continue to appear.    

Will check the logs on other network...
											
Now I'm confused. Does this mean that you CAN connect to that remote host?    
The problem I see in your screenshot is that the client issued a "ssh" command and the remote host responded -- but your client (the machine running the "ssh") doesn't trust the certificate used by the server (the remote machine).    
If you're sure you're connected to the correct machine, add the key to your "known_hosts" file.    
											
Did you review the eventogs as I suggested 3 days ago?    
Is the account you are using able to log in via RDP to the destination machine?    
Did you specify a ChrootDirectory in your sshd_config file? Did you check the NTFS permissions on that folder?
											
See below information about the logs.    
YES, I can RDP using the WAN IP address of the device. User account for the RDP is SAME as I am using for the ssh. User is member of administrators group. NTFS permissions are default, I have not changed anything on NTFS permissions.    
Did you specify a ChrootDirectory in your sshd_config file <NO>    
											
The default for both the PubkeyAuthentication and PasswordAuthentication configuration values is "yes".    
While you're at it, though, I'd change the value of the LogLevel from INFO to VERBOSE.