Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
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.
Recently I setup an additional server - just data storage, no other "server" sort of uses. The hardware was almost the same as my existing server so I followed this shortcut process:
From the original server "taylor14" I made a Clonezilla image of the OS drive (CentOS 7 with Mate desktop). The server also has 5 data drives, they were not imaged.
I restored this image to a new hard drive of the same size.
On the new hard drive I deleted the entries for the 5 data drives mounts from /etc/fstab and /etc/exports. I changed /etc/hostname to read "taylor18" the name of the new server.
I booted the new server from the cloned drive. I reserved the IP address 192.168.0.118 in my router. taylor18 now receives that address when it boots.
I made the appropriate entry in /etc/hosts on my desktop PC (192.168.0.118 taylor18) I can now ping taylor18 and it resolves to 192.168.0.118 as expected.
For my next trick - and this is what gets interesting - I opened a terminal on the desktop and entered ssh taylor18. I received the normal message about the key not being recognized and I allowed it to be accepted and saved. And then...
I was logged into taylor18 WITHOUT being prompted for a password!
I have a "Personal" Secure Shell Key for taylor14 (the server from which I cloned taylor18) which I setup in Seahorse 2.28.1. I have not yet setup a key for taylor18. Which makes me wonder... How did ssh and the Gnome Keyring (which I believe underlies Seahorse) determine which credentials to use to gain access to taylor18?
It APPEARS that ~/.ssh/known_hosts must contain the same server side key entry under taylor14 and taylor18. Is that causing this phenomenon? That ALMOST makes sense except that...
I have another (ancient) computer taylor09 which I can connect to with ssh. I do NOT have a "Personal" Secure Shell Key created via Seahorse. When I ssh to taylor09 I am prompted for my taylor09 password. Yes, I did receive the unknown key message the FIRST time I connected to taylor09 and accepted it when prompted.
I am close to wrapping my head around this but not quite. I was hoping that by describing the situation I would figure it out but I am still missing something. Where is the password for taylor18 being saved? Can anyone help me clear up what is going on?
TIA,
Ken
p.s. I guess I can change my password on taylor18 and see if the ssh connection prompts me or barfs. I will try that.
Check in your home directory on the new server for a file .ssh/authorized_keys. That may have a copy of your rsa public key, which allows passwordless login.
If taylor14 was set up with passwordless shared key, and you cloned taylor18 from taylor14, then taylor18 will have the same shared key and the same passwordlesss login from the same remote systems. It does not know or care what its hostname is.
The password is not stored anywhere - only the shared key is used. If the key was created with a passphrase then you will be prompted for that passphrase by the remote system itself, not the server.
Why would you expect it to be different?
Last edited by astrogeek; 08-30-2016 at 03:04 PM.
Reason: Typos, caps and added comment...
That was it exactly. In fact, I just copied the .ssh/authorized_keys file from taylor18 to taylor09 and I can now connect taylor09 it without a password prompt.
And thank you astrogeek,
I guess I did not know exactly WHAT to expect as I had never dug into the process in enough detail. I have experienced issues if I setup more than 5 ssh keys in Seahorse. It has been a while since this happened as I do not setup keys for test machines etc. just for that reason. As I recall I would get messages to the effect "too many login attempts" when trying to connect to the 6th computer. I think it is now time to get back to basics and learn exactly which key gets put where and when - and then manage them by hand.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.