Kudos to finding a hosting that requires a DIY OS installation odyssey - from keyboard layout to manual network config, disk partitioning, and package selection. I successfully installed Debian 11 with an SSH server and logged in to noVNC as root via their panel. However, when I tried to SSH into Pytty with the password 'figfam', I hit a brick wall - access was denied.

I checked the SSH service, and it was running on port 22, so I was stumped. I thought maybe Debian had a password-free login policy, so I checked the config file using nano. But, it seemed like a rabbit hole - the config was different from what I'd read online.

To make matters worse, noVNC was being a real pain, refusing to recognize my clipboard. I had to manually type everything out.

So, how do I get SSH access, and what's the deal with transferring a buffer from Windows to noVNC? I couldn't find a straightforward solution online, just some sketchy hacks involving weird software that made me nervous.

Double-check that the user you're trying to SSH as actually exists on the Debian system. If you're using 'root', ensure that root login is allowed in the SSH configuration file (/etc/ssh/sshd_config). Look for the line PermitRootLogin and set it to yes. After modifying the config, restart the SSH service with systemctl restart ssh. If you're still facing issues, consider checking /var/log/auth.log for any clues on authentication failures.

Regarding clipboard issues with noVNC, this is a common pain point. The clipboard functionality might not be fully supported out of the box. As a workaround, you could use a simple text file to transfer data. Create a text file on your Windows machine, paste your commands there, and then use scp to copy the file to your Debian server. This method avoids the clipboard hassle altogether and gets your commands where they need to be without the risk of sketchy software.

Now, if you're still struggling with SSH access, it's time to question your setup. You've gone through a DIY installation, yet you're stuck on something as fundamental as SSH? This isn't rocket science; it's basic server management. If you can't get SSH working, maybe you should reconsider your approach to self-hosting.

Lastly, if you're relying on noVNC for clipboard functionality, you're setting yourself up for disappointment. NoVNC is great for browser-based access, but it's not a full-fledged remote desktop experience. Consider installing a proper VNC server or using an alternative like RDP for better performance and functionality.

I'm curious about the permissions on these SSH config files. Specifically, I'm wondering about the access control on the HostKey files, which are stored in
/etc/ssh/ssh_host_rsa_key
/etc/ssh/ssh_host_ecdsa_key
/etc/ssh/ssh_host_ed25519_key

According to best practices, these files should have restrictive permissions, such as 600 to prevent unauthorized access and ensure the integrity of the SSH server.

Ubuntu Server is still the way to go, folks. Debian's gone downhill since Murdoch's departure. As a seasoned sysadmin, I can attest that it's always better to opt for a tried-and-true distro like Ubuntu. Plus, with its robust security features, you can rest assured your server is locked down tighter than a Fort Knox vault. And let's be real, who needs to waste their time on passwords when you can just throw that public key into known_hosts and be done with it? I mean, why bother with the hassle of password management when you can just SSH in and get to work?

Now, I know what you're thinking - what about permit root login? Well, let me tell you, I didn't see a mention of it in the config, but I wasn't exactly scouring the topic with a fine-tooth comb, if you know what I mean. However, I did manage to stumble upon the solution: PermitRootLogin yes.

And finally, let's talk about rebooting the server. Listen, unless you're dealing with a major issue that requires a full system restart, there's no point in shutting down the server just because you need to restart sshd. Trust me, I've been there - it's a total productivity killer. So, just SSH in and get to work, and let the server do its thing in the background.