Linux - NetworkingThis forum is for any issue related to networks or networking.
Routing, network cards, OSI, etc. Anything is fair game.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Distribution: Mint 18.3 Cinnamon, Gallium, Ubuntu Armbian (headless), Arch (learning)
Posts: 138
Rep:
SSH keys deleted off client...
Long story (as always). Short version is my SSH keys are deleted off my client (desktop) and I cannot login to my server. I really am still learning this whole key stuff. Pretty much where to I go from here?
Thanks guys.....
~T
Code:
ssh -v server@192.168.1.110
OpenSSH_7.2p2 Ubuntu-4ubuntu2.4, OpenSSL 1.0.2g 1 Mar 2016
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to 192.168.1.110 [192.168.1.110] port 22.
debug1: Connection established.
debug1: identity file /home/mint18/.ssh/id_rsa type 1
debug1: key_load_public: No such file or directory
debug1: identity file /home/mint18/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/mint18/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/mint18/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/mint18/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/mint18/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/mint18/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/mint18/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.2p2 Ubuntu-4ubuntu2.4
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.2p2 Ubuntu-4ubuntu2.4
debug1: match: OpenSSH_7.2p2 Ubuntu-4ubuntu2.4 pat OpenSSH* compat 0x04000000
debug1: Authenticating to 192.168.1.110:22 as 'nextserver'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256@libssh.org
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:W2XfkFmsZliqf0yjUu0feY3sYA9ue+M/6jRdbgXCU5w
debug1: Host '192.168.1.110' is known and matches the ECDSA host key.
debug1: Found key in /home/mint18/.ssh/known_hosts:1
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<rsa-sha2-256,rsa-sha2-512>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/mint18/.ssh/id_rsa
debug1: Authentications that can continue: publickey
debug1: Trying private key: /home/mint18/.ssh/id_dsa
debug1: Trying private key: /home/mint18/.ssh/id_ecdsa
debug1: Trying private key: /home/mint18/.ssh/id_ed25519
debug1: No more authentication methods to try.
Permission denied (publickey).
Just grab them from your one of your several backup copies.
If they weren't worth backing up, you can go in via the console and paste or hand-type a new public key into the authorized_keys file. Either way be careful with the line breaks. Ed25519 are shortest if you have to type it in by hand.
Distribution: Mint 18.3 Cinnamon, Gallium, Ubuntu Armbian (headless), Arch (learning)
Posts: 138
Original Poster
Rep:
Quote:
Originally Posted by Turbocapitalist
Just grab them from your one of your several backup copies.
If they weren't worth backing up, you can go in via the console and paste or hand-type a new public key into the authorized_keys file. Either way be careful with the line breaks. Ed25519 are shortest if you have to type it in by hand.
Yes, didn't back them up because still playing around with this stuff.
Please forgive my dumb question I am about to ask, but if I create a new key, will it mess with the one already on the server?
This is why I enjoy using a password over keys, seems more foolproof. I am sure once I get used to all this key crap it will be easier.... Until then.. :/
... if I create a new key, will it mess with the one already on the server?
You can add new keys to the authorized_keys file without disturbing the old ones. Just add the new keys, one per line (and one line per key).
The keys are straight forward but only once you get used to them. I recall having a lot of confusion about them when I first tried them. There wasn't much beyond the manual pages at the time. So ended up wasting a lot of effort in testing. Keep asking here when you have questions or get stuck.
If you are dealing with large numbers of machines, then SSH certificates are the way to go instead of SSH keys. Those require a third way of thinking.
Distribution: Mint 18.3 Cinnamon, Gallium, Ubuntu Armbian (headless), Arch (learning)
Posts: 138
Original Poster
Rep:
Quote:
Originally Posted by Turbocapitalist
You can add new keys to the authorized_keys file without disturbing the old ones. Just add the new keys, one per line (and one line per key).
The keys are straight forward but only once you get used to them. I recall having a lot of confusion about them when I first tried them. There wasn't much beyond the manual pages at the time. So ended up wasting a lot of effort in testing. Keep asking here when you have questions or get stuck.
If you are dealing with large numbers of machines, then SSH certificates are the way to go instead of SSH keys. Those require a third way of thinking.
Thank you... I am going to give that a try for a little bit. I appreciate the help!!!
Distribution: Mint 18.3 Cinnamon, Gallium, Ubuntu Armbian (headless), Arch (learning)
Posts: 138
Original Poster
Rep:
I hooked up the monitor and keyboard to the server. Is there an easier way to just delete the key and get it where I can just ssh back in and then set the keys back up? This is turning out to be a HUGE PITA right now....
Distribution: Mint 18.3 Cinnamon, Gallium, Ubuntu Armbian (headless), Arch (learning)
Posts: 138
Original Poster
Rep:
-OK! I was able to FINALLY change settings around in the sshd_config file so I can ssh in. I guess now I can go ahead and find the tutorial again on how to setup these keys....
The whole point is that it is supposed to be difficult if not impossible to get back in if you do not have the keys.
About sshd if you have other ports available and not filtered, then you don't need to modify sshd_config itself to make a one-off change. You can launch a second instance of sshd, overriding the Port and PasswordAuthentication directives.
That will allow you in once on port 22022 while leaving the regular server on port 22 untouched. The -d puts it into debug mode so that it runs in the foreground for just a single session and logs to stderr instead of the system logs.
Then you will have more information by which to evaluate the tutorials you find. Most tutorials I've seen are out of date, wrong, or inapplicable. But otherwise I would agree in principle a tutorial would be a good way.
Distribution: Mint 18.3 Cinnamon, Gallium, Ubuntu Armbian (headless), Arch (learning)
Posts: 138
Original Poster
Rep:
Quote:
Originally Posted by Turbocapitalist
The whole point is that it is supposed to be difficult if not impossible to get back in if you do not have the keys.
About sshd if you have other ports available and not filtered, then you don't need to modify sshd_config itself to make a one-off change. You can launch a second instance of sshd, overriding the Port and PasswordAuthentication directives.
That will allow you in once on port 22022 while leaving the regular server on port 22 untouched. The -d puts it into debug mode so that it runs in the foreground for just a single session and logs to stderr instead of the system logs.
Then you will have more information by which to evaluate the tutorials you find. Most tutorials I've seen are out of date, wrong, or inapplicable. But otherwise I would agree in principle a tutorial would be a good way.
HEY!!! OPTIONS!!!! Ok, awesome thank you! I was able to setup a new 4096 (bit?) key and pushed it to the server. All is back on track now. For my next trick, I am going to look into what you are talking about because I NEED OPTIONS! LOL!
Now- to PREVENT this "tourette's dance" from happening again, what's the best way to backup this key? I understand that it is in the hidden ~/.ssh folder. I know that I passphrased mine for security. I am kind of at a loss on how to back that sucker up and restore it if I suffer another "deadend moment".
Thank you for taking the time to extend your hand to help me out. I appreciate the explanation of what's what! I get flustered about these keys because I am still trying to grasp it all and figure it all out in my head (how it works and how to PROPERLY apply it to security principles). I am still a Padawan with these things. I have only been diving in (completely) to Linux since October, so I am making progress- it's just not as fast as I want it to be, LOL!
Thanks again,
~T
Last edited by mr.travo; 05-26-2018 at 03:10 AM.
Reason: Spellllering
If you did not name the key pair using the -f option, it is probably in the directory you were in when you ran ssh-keygen and named id_rsa and id_rsa.pub. You can rename them and in fact that is often a good idea so you can remember what they are for once you have a few keys or enough time passes. Just be sure that the names match. See -f, -t, and -C in "man ssh-keygen"
With OpenSSH the manual pages are a close match to the source code and are well written. So be sure to check the structure of the four key ones so you have an idea where to find things. Also read up on the options you use a lot or plan to use:
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.