0

I followed the common practice to only allow public key login with SSH into Debian, then somehow I accidentally changed the permission of ~/.ssh/ folder (I think it got owned by root), after that openSSH refused to log me in! (and server was in a different country, with no remote/KVM console)

I find this setup quite fragile. Is there a way to prevent this, and maybe just give me a warning on next login?

If there is no solution then I will have to setup a strong login password as a backup, no matter what everyone else says.

Found similar lockout question but iptable/configuration change was the root cause: Prevent being locked out when configuring SSH and iptables I didn't change the configuration so I wasn't expecting a lockout.

Eva4684
  • 1
  • The solution is to have out of band access - remote kvm/console. Maybe have a periodic job run to set the ownership/perms to the correct values. Be more careful. – user9517 Feb 21 '23 at 11:46
  • Yeah cron is a good idea, but doesn't protect against deleting authorized_keys, is there a small alternative to corporate management consoles (IPMI, iLO, DRAC) that don't use SSH? – Eva4684 Feb 21 '23 at 12:12
  • Use a better provider, keep a copy of the keys elsewhere to be copied in by cron, use a configuration management tool ... – user9517 Feb 21 '23 at 12:32
  • Management consoles generally use either ssh or https. Since the management console has its own authentication separate from the system's why do you want a different protocol? – doneal24 Feb 22 '23 at 00:08

1 Answers1

1

Hosts need an alternate access method if they are to be recovered. ssh over the internet requires things to be working normally: network access, firewall allow rule, running and configured sshd, secured key files. Any one of these breaks, cannot get in. The most reliable out of band access does not rely on IP networking in the host to be working.

If it is a VM, perhaps shut it down, and attach the disk to some other working instance to repair it. Not ideal, but only requires you have access to the disk.

An off-host backup of the data allows creating a new replacement host. May seem silly to destroy and rebuild just because ssh access was lost, but it remains a recovery option.

As to preventing the problem in the first place, a syntax check of sshd configuration (sshd -T -f for OpenSSH) will not catch everything. End to end testing could be done by starting another sshd, on a different port, with everything the same but the port number. Connect to this remotely to test that things are working. Unfortunately, even taking such care is not going to catch unintentional things, like a permissions change on home directories that accidentally makes ssh files unsecured. Or a change in IP that could alter the effective ssh_config due to Match keywords.

Passwords remain a terrible authentication mechanism.

John Mahowald
  • 32,050
  • 2
  • 19
  • 34