LinuxQuestions.org
Help answer threads with 0 replies.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Networking
User Name
Password
Linux - Networking This forum is for any issue related to networks or networking.
Routing, network cards, OSI, etc. Anything is fair game.

Notices


Reply
  Search this Thread
Old 05-26-2018, 12:35 AM   #1
mr.travo
Member
 
Registered: Oct 2017
Location: All over the US
Distribution: Mint 18.3 Cinnamon, Gallium, Ubuntu Armbian (headless), Arch (learning)
Posts: 138

Rep: Reputation: 10
Unhappy 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).
 
Old 05-26-2018, 12:39 AM   #2
Turbocapitalist
LQ Guru
 
Registered: Apr 2005
Distribution: Linux Mint, Devuan, OpenBSD
Posts: 7,258
Blog Entries: 3

Rep: Reputation: 3713Reputation: 3713Reputation: 3713Reputation: 3713Reputation: 3713Reputation: 3713Reputation: 3713Reputation: 3713Reputation: 3713Reputation: 3713Reputation: 3713
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.
 
Old 05-26-2018, 12:48 AM   #3
mr.travo
Member
 
Registered: Oct 2017
Location: All over the US
Distribution: Mint 18.3 Cinnamon, Gallium, Ubuntu Armbian (headless), Arch (learning)
Posts: 138

Original Poster
Rep: Reputation: 10
Quote:
Originally Posted by Turbocapitalist View Post
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.. :/
 
Old 05-26-2018, 01:16 AM   #4
Turbocapitalist
LQ Guru
 
Registered: Apr 2005
Distribution: Linux Mint, Devuan, OpenBSD
Posts: 7,258
Blog Entries: 3

Rep: Reputation: 3713Reputation: 3713Reputation: 3713Reputation: 3713Reputation: 3713Reputation: 3713Reputation: 3713Reputation: 3713Reputation: 3713Reputation: 3713Reputation: 3713
Quote:
Originally Posted by mr.travo View Post
... 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.
 
Old 05-26-2018, 01:20 AM   #5
mr.travo
Member
 
Registered: Oct 2017
Location: All over the US
Distribution: Mint 18.3 Cinnamon, Gallium, Ubuntu Armbian (headless), Arch (learning)
Posts: 138

Original Poster
Rep: Reputation: 10
Quote:
Originally Posted by Turbocapitalist View Post
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!!!

~T
 
Old 05-26-2018, 01:34 AM   #6
ondoho
LQ Addict
 
Registered: Dec 2013
Posts: 19,872
Blog Entries: 12

Rep: Reputation: 6053Reputation: 6053Reputation: 6053Reputation: 6053Reputation: 6053Reputation: 6053Reputation: 6053Reputation: 6053Reputation: 6053Reputation: 6053Reputation: 6053
just my 2ct:
ssh key questions are much better answered by reading a dedicated article.

also +1 for backups.
and +1 for physical access.

also, ssh keys are secure, so if you lose them, you are, by definition, locked out.
keep that in mind.
 
Old 05-26-2018, 02:02 AM   #7
mr.travo
Member
 
Registered: Oct 2017
Location: All over the US
Distribution: Mint 18.3 Cinnamon, Gallium, Ubuntu Armbian (headless), Arch (learning)
Posts: 138

Original Poster
Rep: Reputation: 10
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....
 
Old 05-26-2018, 02:13 AM   #8
mr.travo
Member
 
Registered: Oct 2017
Location: All over the US
Distribution: Mint 18.3 Cinnamon, Gallium, Ubuntu Armbian (headless), Arch (learning)
Posts: 138

Original Poster
Rep: Reputation: 10
-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....
 
Old 05-26-2018, 02:25 AM   #9
Turbocapitalist
LQ Guru
 
Registered: Apr 2005
Distribution: Linux Mint, Devuan, OpenBSD
Posts: 7,258
Blog Entries: 3

Rep: Reputation: 3713Reputation: 3713Reputation: 3713Reputation: 3713Reputation: 3713Reputation: 3713Reputation: 3713Reputation: 3713Reputation: 3713Reputation: 3713Reputation: 3713
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.

Code:
sudo /usr/sbin/sshd -d -p 22022 -o PasswordAuthentication=yes
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.


Here is some background reading on SSH keys:

https://en.wikibooks.org/wiki/OpenSS...Authentication

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.
 
1 members found this post helpful.
Old 05-26-2018, 03:05 AM   #10
mr.travo
Member
 
Registered: Oct 2017
Location: All over the US
Distribution: Mint 18.3 Cinnamon, Gallium, Ubuntu Armbian (headless), Arch (learning)
Posts: 138

Original Poster
Rep: Reputation: 10
Quote:
Originally Posted by Turbocapitalist View Post
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.

Code:
sudo /usr/sbin/sshd -d -p 22022 -o PasswordAuthentication=yes
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.


Here is some background reading on SSH keys:

https://en.wikibooks.org/wiki/OpenSS...Authentication

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
 
Old 05-26-2018, 03:14 AM   #11
Turbocapitalist
LQ Guru
 
Registered: Apr 2005
Distribution: Linux Mint, Devuan, OpenBSD
Posts: 7,258
Blog Entries: 3

Rep: Reputation: 3713Reputation: 3713Reputation: 3713Reputation: 3713Reputation: 3713Reputation: 3713Reputation: 3713Reputation: 3713Reputation: 3713Reputation: 3713Reputation: 3713
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:

Code:
man ssh
man ssh_config
man sshd
man sshd_config
 
1 members found this post helpful.
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
LXer: Complete Tutorial On How To Setup SSH Keys & SSH Connections LXer Syndicated Linux News 0 05-10-2018 12:30 AM
Way to hide keys in .ssh from login user but still accessible via ssh. MikeyCarter Linux - Software 4 03-29-2018 10:44 AM
SSH host keys are not being read correctly from .ssh/known_hosts. bartonski Linux - Software 3 10-29-2009 04:40 PM
SSH host keys VS SSH keys kenneho Linux - Security 3 09-11-2008 06:03 AM
Configuring SSH to accept only keys (already have keys) fr0st Linux - Security 3 11-04-2003 03:31 AM

LinuxQuestions.org > Forums > Linux Forums > Linux - Networking

All times are GMT -5. The time now is 04:36 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration