Ah... ok. So do you have a unique IP address that is assigned exclusively for your use? This would not be the standard service -- it would likely be an additional option/cost.
Depends where I am connected, now I'm in Toronto server, I paid for the pro service
What do you mean by this??
Critically, a commercial VPN service does not typically give subscribers a dedicated IP address (I.e. one that belongs solely to the individual subscriber). The IP address is usually shared by many subscribers via masquerading. Unless Proton has provided you with one that is exclusively for your use, what you are trying to do will not be possible because that IP address is shared across many users.
It is pretty clear now that this is not an OpenWrt related issue. It is specifically one of your VPN endpoint -- unless you can guarantee/prove that the IP is yours and only yours, of course.
I don't have a dedicated IP with them, which I had with torguard. You are right.
I can use any server I want
Right... so that means that you cannot use it an an entry point for ssh (or any other services). That is why you are getting the error... when you attempt to ssh to your system via that IP address, it's not actually able to get to your machine because that IP isn't exclusively yours. You would need either a port-forward or an exclusive IP -- both of these things are not standard for most commercial VPN services.
As an outbound IP, yes... but not as an inbound one. This further proves that what you are attempting to do will not work. This is not related to OpenWrt.
If your problem is solved, please consider marking this topic as [Solved]. See How to mark a topic as [Solved] for a short how-to.
Thanks! 
But if I remove my ddns setting and the package, everything will work again, cause it worked this morning
Ok... then let's rewind...
- Why did you add ddns?
- From where are you trying to the computer? Is it on the same network as the OpenWrt router itself or is in some remote location?
- What is the IP address of the target computer (the address it uses on your lan)?
- What is the IP address of the router itself (the lan address)?
I added it to use acme and to have an encrypted certificate with zerossl.
no remote location
When you attempt to connect to your ssh server, the IP address that resolves is your 'apparent' wan address, but there is no ingress access via that address to your computer. Therefore, it's never going to connect.
So if there is no remote location, why even worry about the certificate? I mean, if you are an enterprise network, that's a different story... but with a home network, you should be able to ensure that you're connecting to the right machine. Besides, the ssh signature will help with that verification, and you can always use a standard ssh key exchange instead of a username and password.
The TL;DR here is that you've added unnecessary complications to your setup resulting in the inability to connect. Instead of using the ddns method and certificates, simply use the local hostname or even the numeric IP address within your lan.
yeah I know, 
it's only because a friend of mine is using adguardhome like me and he likes to be very (over) secure, so his setup with adguardhome, it is the certificate and encrypted dns etc.. I wanted to try it.
The only way this will work is if the certificate and dns resolution correspond to the local address on your lan.
I remove my vpn right now and it is not working, I can do that ;
scp root@192.168.1.1:/tmp/backup-*.tar.gz james@pop-os:/media/james/E/openWrt_backup
but not that;
root@james:/tmp# scp backup-main-2024-12-28.tar.gz james@pop-os:/media/james/D/myfiles
It's not the VPN... although that is part of it.
The hostname is resolving to the incorrect (and unreachable) address.
Remove all of the ddns related stuff entirely.
Meanwhile, this isn't necessary:
The file is local, right? So it should be:
scp backup-main-2024-12-28.tar.gz james@pop-os:/media/james/D/myfiles
But pop-os is probably not resolving correctly. So instead, use its local IP address (i.e. 192.168.1.x or whatever it is on your local network).
that is working;
scp backup-main-2024-12-28.tar.gz james@192.168.1.178:/media/james/D/myfiles
Great! And as expected.
As I have explained in several posts already, the problem was self-inflicted insofar as you complicated your setup with unnecessary additions that offer very little if any security benefit (especially from a practical standpoint where you're not likely to have unknown or malicious actors/hosts locally on your network).
So... can we consider this solved now?