Take care with " backdoors", not a good idea. Port scanners ie "nmap" will find obfuscated servers running on different ports. On Fri, Feb 21, 2020 at 7:21 AM Michal Schorm <mschorm(a)redhat.com&gt; wrote: > > > In doing this is their danger of making an error and locking myself out > > of my computer, if so what to avoid? > > You can use dummy account for that, on both ends. > > You can force SSH (client) to only use keyes, instead of passwords. > > You can run SSH in a container, to learn how to set it up. If you > break thy system inside of the container, you can just restart it and > try again. > > You can try (never did this one) to run another SSH server on > different port - as a "backdoor". (Allow that port in firewall) > > Once you are confident, you can start using your intended client, > still with dummy server (either in a container or a dummy user > account). > After everything will work, you can attempt to switch to "production". > > If you are locking root account, set sudo permissions to another user account. > > Restart both devices on both ends (at once) to make sure you have > correct permanent configuration. > > > > > > > > > > > > > > > -- > > Michal Schorm > Software Engineer > Core Services - Databases Team > Red Hat > > -- > > On Fri, Feb 21, 2020 at 1:05 PM Bob Goodwin <bobgoodwin(a)fastmail.us&gt; wrote: > > > > I've been reading the thread about detecting hack attempts and I am > > interested in in setting up "key based authentication" as described > > [perhaps] in > > "https://docs.fedoraproject.org/en-US/Fedora/14/html/Deployment_Guide/s2-ssh-configuration-keypairs.html" > > > > In doing this is their danger of making an error and locking myself out > > of my computer, if so what to avoid? I've made some catastrophic errors > > in the not very distant past that required a new system re-installation > > and would prefer not repeating that. > > > > Suggestions, thoughts? > > > > Bob > > > > -- > > Bob Goodwin - Zuni, Virginia, > > Fedora Linux-31 XFCE > > _______________________________________________ > > users mailing list -- users(a)lists.fedoraproject.org > > To unsubscribe send an email to users-leave(a)lists.fedoraproject.org > > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > > List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org > _______________________________________________ > users mailing list -- users(a)lists.fedoraproject.org > To unsubscribe send an email to users-leave(a)lists.fedoraproject.org > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org

Key based authentication works well in small environments, you generate the keys (recommend you consider ed25519 instead of RSA, etc), distribute them across the servers (public keys) and update the authorized keys file. On the server side you configure SSHD to use keys vs. passwords (disable password based authentication). As long as you do not lose the keys you are good. If you have console access to the server, then you can always reconfigure SSHD back to passwords in the event you lose your keys. For larger environments, this may not be the ideal choice and you may want to consider ssh certificates (not the same as x.509 certificates). If you are going to be using ssh certificate authentication (highly recommended) you will need to ensure the certificates do not expire and so need to renew them ahead of time. As long as you have console access to the remote server (most cloud providers have this) you can always reconfigure sshd to allow yourself back in in the event the certificates have expired. As you will be issuing the certs, you have control on their duration. Frank On Fri, Feb 21, 2020 at 7:05 AM Bob Goodwin <bobgoodwin(a)fastmail.us&gt; wrote: > > I've been reading the thread about detecting hack attempts and I am > interested in in setting up "key based authentication" as described > [perhaps] in > "https://docs.fedoraproject.org/en-US/Fedora/14/html/Deployment_Guide/s2-ssh-configuration-keypairs.html" > > In doing this is their danger of making an error and locking myself out > of my computer, if so what to avoid? I've made some catastrophic errors > in the not very distant past that required a new system re-installation > and would prefer not repeating that. > > Suggestions, thoughts? > > Bob > > -- > Bob Goodwin - Zuni, Virginia, > Fedora Linux-31 XFCE > _______________________________________________ > users mailing list -- users(a)lists.fedoraproject.org > To unsubscribe send an email to users-leave(a)lists.fedoraproject.org > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org

On Fri, 21 Feb 2020 08:17:27 -0600 Richard Shaw wrote: That's the important bit. You can leave password enabled while testing public keys and only disable it when you verify the public key setup works. At home, I have a sshd_config file that enables highly insecure access just for my local network, and requires public key for outside connections. Here's the magic bit at the end of the file: Match Address 127.0.0.1,192.168.1.* Banner /etc/nohamster.txt GSSApiAuthentication yes KerberosAuthentication no PasswordAuthentication yes KbdInteractiveAuthentication no PermitRootLogin yes

On 2/21/20 4:00 AM, Bob Goodwin wrote: You could only lock yourself out if ssh is the only way to access the system. But I assume this is a computer that you normally have console access on (graphical interface).