It looks like that's just a generic error message. For me, this websocket message is received when the error appears:
{"error":true,"body":"Your credit balance is too low to access the Anthropic API. Please go to Plans & Billing to upgrade or purchase credits.","done":false,"id":"XXXXXXXX","type":"cf_agent_use_chat_response"}
After the recent hacker news "invasion", I have now determined that the page can handle up to 1536 users before running out of RAM, meaning that the IP camera surprisingly is fully sufficient for its purpose. In other words, I will not be moving the forum in the near future as 32 MB of RAM seem to be enough to run it
Is the certificate for that domain pinned? If not, just host it locally. In fact, I'm going to try doing that. Have you already checked the Docs? Somebody probably already published a gist somewhere with the needed path
Hover over the "minutes ago" string on any of those comments & you'll see the original timestamp. I guess this is a repost, comments got merged, and the "minutes ago" strings are cached/pre-generated from the old thread?
Experienced this too. Having SSH access enabled on the Synology saved the day. There's no 2FA prompt on SSH, so you can SSH in and manually fix the time.
SSH and the web UI are two different interfaces running on separate ports that can be firewalled differently. You might, for instance, expose the web UI on an external port on your router while restricting SSH access to the NAS's subnet. In that case, the MFA is a critical extra layer of security.
If your private SSH key is password protected, it is encrypted symmetrically with that password.
If somebody steals your password protected private key file, having the password protection there means they have to bruteforce the password. It does not 'do nothing'. Its an extra layer. If your password is secure enough, it can protect you from having the ssh private key decrypted.
It's an extra layer, but is that really another 'factor'? MFA would prevent someone with a compromised key from logging in. Password protected keys do not.
I think the point is about parallel vs serial layers of security. In a typical website account that is protected by password and SMS OTP, both of them need to be compromised for a bad actor to gain access. If they have just the password, they'll get stuck at the SMS token, and if they intercept an SMS OTP, they won't be able to get to the form where they can enter it. In contrast, a password-protected SSH key isn't pure MFA. If they have the password, they still need to get the private key file before they can use it to get the private key. However, if they have the private key, then they don't need the password at all. The password only protects you from people stealing the file, not from the stealing the key itself.
Compromised, meaning someone has the key in an unprotected format, or they somehow got your password. Say someone manages to MITM you somehow and get your password to the file, or they manage to crack it, or phish it out of you. Then they can just take the key and use it freely to log into your things. With MFA, there's no way that any key can be used to log in as long as the other factor exists. If you have to push OK on your cell phone to log in for example, the key is useless without physical access to your phone.
I'm not saying the password protection does nothing, it makes the key harder to crack but it's not another factor. It's simply an extension of the existing key. In other words, it's just a longer password.
> I have a 400mm x 500mm x 80mm drawer for screws and bolts.
(thinking for a while)
"Please provide drawer dimensions to continue."
reply