I was scrolling through social media today and came across this post.
I have been getting DVDs by mail from Netflix for over 20 years and lamenting the upcoming end of the service. My queue is down to limited set of movies, as often when I think of a movie I’m interested in seeing, they no longer offer it. I decided to check out what it would cost to upgrade to get a bunch of the movies from my list at once.
It’s funny to recognize that even the plan I’m currently on is not an option anymore. It would cost me $2 more a month for the same plan. Back when I first joined, I was on a 4 disk at a time plan. I found I was much more likely to misplace a disk back then.
Much as I’ve loved the service, I don’t want a bunch of disks arriving at once or trying to game the system to get the movies I most want to see arriving when the end is near so will just continue with my current service for the final month.
Important changes to your Google Domains account: Squarespace announces purchase of domain registrations
Squarespace recently announced that it entered into an agreement to purchase all domain name registrations and related customer accounts from Google Domains. As a valued customer we wanted to make you aware of the following important information.
What happens now?
There is nothing you need to do at this time. Your domain will continue to operate and be managed by Google until it is time to move to Squarespace. That won’t happen until after the transaction closes and the migration process begins, which will likely take place over the next few months.
What happens next?
All customers will be moved to Squarespace Domains in the coming months. You will be notified once your domain has moved. Squarespace Domains is an independent domain registrar service provided by Squarespace.
Squarespace has publicly committed to continue to utilize Google Cloud DNS infrastructure, meaning reliability and performance regarding DNS will remain unchanged during the migration.
The purchase is currently subject to regulatory approval and other customary closing conditions. Upon the closing of the transaction, your domain account will be owned by Squarespace but you will continue to manage your domain(s) via Google Domains as you do today, with Google’s Privacy Policy and Terms of Service continuing to apply.
Learn more about Squarespace’s plan for domains here.
Squarespace and Google are committed to a seamless transition. For a limited period of time post-close until your account is migrated to Squarespace, your account will be managed by Squarespace utilizing Google’s infrastructure. After this migration period Squarespace will be solely responsible for providing domain services to you. During the migration period after the closing of the transaction, your customer and, if applicable, billing information will be migrated to Squarespace. Upon migration – which will be at least 30 days from today – your data will be governed by Squarespace’s Privacy Policy and Squarespace’s Terms of Service will apply. Additionally, if you have a Google Workspace subscription billed by Google Domains, billing and support services for such subscription will be transitioned to Squarespace. Following closing of the transaction, you will receive instructions from Squarespace on how to manage your domain(s) via a Squarespace account (including DNS, WHOIS, and renewal settings).
You will continue to have the ability to transfer your domain(s) to another registrar prior to such migration or at any time thereafter.
In the meantime, if you need help with anything related to your domain please contact us. You can also learn more about Squarespace here.
I like using the google domains management interface. Google was charging a reasonable cost ($12 per year) for .com domains and including DNS hosting and not pushing other services. I’d migrated from GoDaddy, which always made simple renewal of my domains slightly complicated as they tried to upsell me to other services they offered. There are several services I’m using from google that are included in the interface and I’m not sure if Squarespace is going to continue to support.
Email forwarding
DNSSEC
Dynamic DNS Records
Both IPv6 and IPv4 records.
Looking at the information Squarespace had online didn’t give me the answers to my questions about dynamic dns and I didn’t find information online in various searches. I know that future prices on anything on the internet are not guaranteed, but Squarespace explicitly promising to not change prices for 12 months leaves me questioning what will happen in twelve months.
WordPress has also been advertising that it’s a good place to move my registry and DNS settings. It is one more service that is focused on website building and while I happily host my blog on WordPress, I have been registering domains on the internet for over thirty years and prefer to keep certain things separate.
In my searching I found that Cloudflare offers registrar services and DNS services. https://www.cloudflare.com/products/registrar/. I’d known about their primary service of website caching and DDoS protection for many years but didn’t know they also provided registrar services. The very nature of their primary services requires a robust DNS infrastructure. They explicitly advertise at-cost pricing, meaning that my .com domains should cost me less than $10 per year at present rates. I came across information online explaining how to set up dynamic DNS entries using Cloudflare, as well as recognizing that my current dynamic DNS software ddclient has built in support for working with Cloudflare. Cloudflare also handles my simple email forwarding requirements for the domain, both with specific email forwarding rules and a catch all setting.
This past weekend I transferred one of my domain names to Cloudflare to be able to test everything out. Parts of the transfer were as smooth as I could hope for with the instructions on the web site being easy to follow. It was definitely important that I’d captured all of the email forwarding rules I’d set up in Google Domains before initiating the transfer. The configuration of dynamic dns hosts wasn’t as obvious as I’d hoped, made more difficult by the fact that my Raspberry Pi devices running Raspberry Pi OS 11 (bullseye) and ddclient version 3.9.1 support a more limited number of Cloudflare authentication options than the ddclient version 3.10.0 that’s installed on Debian GNU/Linux 12 (bookworm).
Based on what I’ve learned so far, I plan to move the rest of my domains from Google Domains to Cloudflare before the end of the month. The biggest frustration is that I’ll have to go to each of my machines that has been updating its address using ddclient and manually update it to use the new service.
I’ve had a Pepwave Max Transit on my boat for a couple of years and have generally been happy with it. The main thing I’ve been trying to get working and not been able to figure out has been IPv6 support. I find their user support forums nearly impossible to navigate, and haven’t really come across other support options beyond possible paid options. As an individual with a single unit I just want it to work and am not supporting a fleet of systems.
The picture above is the main dashboard that’s presented when you log in. You can reorder the network priority with a drag and drop interface. I recently added a T-Mobile home internet gateway for use when I’m at my home marina. It’s plugged into the Pepwave directly via an ethernet cable.
The T-Mobile internet also is a WiFi hotspot and I was able to see that my machines connected to it were getting IPv6 addresses.
I finally figured out that the way to enable IPv6 on the Pepwave is under a slightly strange location in their interface.
When you click on the network tab at the top, it has a menu of items down the left starting with LAN and some bullets below that. LAN is not selectable, and the first bullet is selected by default. The thing I’d never figured out was that WAN is selectable, and it has a few more options, including the ability to enable IPv6, which I’ve now enabled. The modification option for IPv6 has a drop down menu for the WAN connection, but it only shows the currently enabled network. I’ve not yet had time to test what happens when I power down the T-Mobile internet. It should invalidate all of the globally scoped addresses on my inside network, but I’m not sure if it will support IPv6 traffic on the Google Fi interface.
A nice thing is that this change was able to work without power cycling the modem.
I spun up a virtual machine in Azure running the Debian Linux version from their catalog. I was able to SSH to the server from my Windows 11 terminal prompt without issues. I wanted to also be able to connect from my copy of SecureCRT that I’ve had for several years and mainly use when I’m connecting to several machines and don’t want to remember the exact hostnames or addresses. My SecureCRT connection attempts were getting rejected.
I found that the new Debian uses JournalCtl instead of looking directly at log files.
wim@WimAzureVM:~$ journalctl | grep sshd
Aug 03 18:27:13 WimAzureVM sshd[24546]: userauth_pubkey: signature algorithm ssh-rsa not in PubkeyAcceptedAlgorithms [preauth]
Aug 03 18:27:14 WimAzureVM sshd[24546]: userauth_pubkey: signature algorithm ssh-rsa not in PubkeyAcceptedAlgorithms [preauth]
Aug 03 18:27:19 WimAzureVM sshd[24546]: error: Received disconnect from 172.56.104.234 port 28331:14: Unable to authenticate using any of the configured authentication methods. [preauth]
Aug 03 18:27:19 WimAzureVM sshd[24546]: Disconnected from authenticating user wim 172.56.104.234 port 28331 [preauth]
Aug 03 18:28:35 WimAzureVM sshd[24551]: userauth_pubkey: signature algorithm ssh-rsa not in PubkeyAcceptedAlgorithms [preauth]
Aug 03 18:28:35 WimAzureVM sshd[24551]: userauth_pubkey: signature algorithm ssh-rsa not in PubkeyAcceptedAlgorithms [preauth]
Aug 03 18:28:48 WimAzureVM sshd[24551]: userauth_pubkey: signature algorithm ssh-rsa not in PubkeyAcceptedAlgorithms [preauth]
Aug 03 18:28:58 WimAzureVM sshd[24551]: userauth_pubkey: signature algorithm ssh-rsa not in PubkeyAcceptedAlgorithms [preauth]
Aug 03 18:29:09 WimAzureVM sshd[24551]: userauth_pubkey: signature algorithm ssh-rsa not in PubkeyAcceptedAlgorithms [preauth]
Aug 03 18:29:17 WimAzureVM sshd[24551]: userauth_pubkey: signature algorithm ssh-rsa not in PubkeyAcceptedAlgorithms [preauth]
Aug 03 18:29:17 WimAzureVM sshd[24551]: error: maximum authentication attempts exceeded for wim from 172.56.104.234 port 52165 ssh2 [preauth]
Aug 03 18:29:17 WimAzureVM sshd[24551]: Disconnecting authenticating user wim 172.56.104.234 port 52165: Too many authentication failures [preauth]
Looking at that section showed that my old version of SecureCRT was using an old ssh-rsa signature algorithm during the handshake. Some web searching indicated that I could allow that handshake by adding PubkeyAcceptedAlgorithms=+ssh-rsa to /etc/ssh/sshd_config. I looked at the config file and saw that it included whatever is located in the directory /etc/ssh/sshd_config.d/ so I created a file /etc/ssh/sshd_config.d/10-allow-old-securecrt.conf with the single line PubkeyAcceptedAlgorithms=+ssh-rsa and restarted the sshd service. I’m now slightly less secure, but I can use my older tool.
WimsWorld 