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-..."
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
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@fastmail.us 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-..."
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@lists.fedoraproject.org To unsubscribe send an email to users-leave@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@fastmail.us 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-..."
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@lists.fedoraproject.org To unsubscribe send an email to users-leave@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
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@redhat.com 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@fastmail.us 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-..."
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@lists.fedoraproject.org To unsubscribe send an email to users-leave@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@lists.fedoraproject.org To unsubscribe send an email to users-leave@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, 12:51 Frank Pikelner, frank.pikelner@gmail.com wrote:
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@redhat.com 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@fastmail.us
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-... "
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 _______________________________________________
You can enable 2FA as well, add AllowUsers to your sshd_config for additional security.
Details on 2FA and Fedora can be found here https://fedoramagazine.org/two-factor-authentication-ssh-fedora/
On Fri, Feb 21, 2020 at 6:05 AM Bob Goodwin bobgoodwin@fastmail.us 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-... "
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?
Besides the other suggestions, for the more "mechanical" part of the process I highly recommend ssh-copy-id.
It will check that you have correct permissions in ~/.ssh before copying the public key over to the remote system. If course you'll need to leave password auth turned on until you complete this.
Thanks, Richard
On Fri, 21 Feb 2020 08:17:27 -0600 Richard Shaw wrote:
It will check that you have correct permissions in ~/.ssh before copying the public key over to the remote system. If course you'll need to leave password auth turned on until you complete this.
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 Fri, Feb 21, 2020 at 07:00:51 -0500, Bob Goodwin bobgoodwin@fastmail.us 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-..."
Suggestions, thoughts?
I like to require both a key and a password. (Key first to prevent password guessing without access to a valid key.) I use a seperate key for each device. It's not quite 2 factor, since the keys can be copied from a compromised device. But it still provides protection in some cases where just using a password could fail.
On 2/21/20 4:00 AM, Bob Goodwin wrote:
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.
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).
-
Bob Goodwin -
Bruno Wolff III -
Earl A Ramirez -
Frank Pikelner -
Michal Schorm -
Richard Shaw -
Samuel Sieb -
Tom Horsley