LinuxQuestions.org
Review your favorite Linux distribution.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Security
User Name
Password
Linux - Security This forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.

Notices


Reply
  Search this Thread
Old 01-30-2017, 08:54 AM   #16
sundialsvcs
LQ Guru
 
Registered: Feb 2004
Location: SE Tennessee, USA
Distribution: Gentoo, LFS
Posts: 9,078
Blog Entries: 4

Rep: Reputation: 3187Reputation: 3187Reputation: 3187Reputation: 3187Reputation: 3187Reputation: 3187Reputation: 3187Reputation: 3187Reputation: 3187Reputation: 3187Reputation: 3187

Carefully consider the role of the "host key fingerprint." It is a random nonce that is generated by one host and securely sent to another so that the other side may recognize it ... or not. It is therefore intended to be both recognizable and recognized: connecting clients remember the fingerprints they've encountered (which you told them that "you recognize"), and warn you when they encounter for the first time any fingerprint that you do not.

I see no good reason why "the fingerprint (of the remote) should change with each reboot," because this simply defeats the purpose of the signature: if you can't anticipate what the next value of the signature will be, you can never use it for its intended purpose. (And, you're just filling-up your authorized_keys file, uselessly.)

Frankly, I'm not entirely sure that you read the cited article all the way to its conclusion, or that you fully understood it, if you did.

I sincerely and respectfully believe that your scheme is both mis-guided and unnecessary. Let me now explain why a single public key provides security (provided that you do not allow sshd to "fall back" to less-secure alternatives such as passwords).

Every public key that you generate, public though it may be, corresponds to something that only you possess: your private key. You can distribute your public key far and wide because it is only able to decrypt something that was encrypted using your (unknown to them) private key. Likewise, that public key can be used to encrypt messages that only you can decrypt.

So, our MITM, in possession of your public key, successfully decrypts his intercept and changes it. Now, he has a problem: he cannot re-encrypt the modified intercept in a way that the final party will be able to decrypt it. (Because he has not stolen your private key. Therefore, only you can do this.)

Public/Private keys are used as an un-forgeable form of identification that is employed during the per-conversation negotiation of an initial "session key" (through the Diffie-Hellman process referred to by the referenced web site). The public key is acceptable proof that any message which it is capable of decrypting must have come from you: that the other-side, no matter which one of "your" public keys he is using, must be negotiating a session-key with you.

Last edited by sundialsvcs; 01-30-2017 at 08:59 AM.
 
Old 01-30-2017, 12:23 PM   #17
atelszewski
Member
 
Registered: Aug 2007
Distribution: Slackware
Posts: 907

Original Poster
Rep: Reputation: Disabled
Hi,

Let's put the blame on me, saying that I'm not explicit enough ;-)

The system I need to connect to is an rescue Linux, managed by the server provider.
Whenever the rescue system is rebooted, the host key fingerprint changes. This is the way they designed it. I have no control over that.
Once I do my business within the rescue system, I will boot my system. This system will not change the host key fingerprint with reboots.
But first, I really need to use the rescue system.

I have the possibility of securely uploading my public key, that then is available to the rescue OS.
I plan to upload two public keys:
- one that I will use to login myself,
- one that I will use to authenticate the host.

This second public key could be whatever file containing enough random data, but it so happens that I am only able to upload file in the form of SSH public key.

EDIT:
I want to use separate, fresh, unknown second public key just a safer approach. It'll be removed as soon as I get the job done, i.e. authenticate the host.
Probably the main (first) public key would be enough, but I'm lost, and can't recall if it's transmitted during the negotiation or not (the answer is probably somewhere over here ;-)), so I'm not sure if it's completely secret. And somebody might actually have my main public key.

Quote:
Originally Posted by sundialsvcs
So, our MITM, in possession of your public key, successfully decrypts his intercept and changes it. Now, he has a problem: he cannot re-encrypt the modified intercept in a way that the final party will be able to decrypt it. (Because he has not stolen your private key. Therefore, only you can do this.)
Does it basically mean he is not able to send a message to the server, that the server would understand and interpret?
So it would mean he wasn't able to execute anything on the server?
Then that would be the answer I expect :-)

--
Best regards,
Andrzej Telszewski

Last edited by atelszewski; 01-30-2017 at 01:32 PM.
 
Old 01-30-2017, 03:12 PM   #18
ntubski
Senior Member
 
Registered: Nov 2005
Distribution: Debian, Arch
Posts: 3,590

Rep: Reputation: 1908Reputation: 1908Reputation: 1908Reputation: 1908Reputation: 1908Reputation: 1908Reputation: 1908Reputation: 1908Reputation: 1908Reputation: 1908Reputation: 1908
Quote:
Originally Posted by ntubski View Post
Assuming[...] MITM pubkey analysis is correct (I haven't completely digested it yet, but at first glance it looks okay)
I took another look, and I believe it's correct. However, there is a caveat that could be problematic for your use case, see below.

Quote:
Originally Posted by sundialsvcs View Post
So, our MITM, in possession of your public key, successfully decrypts his intercept and changes it. Now, he has a problem: he cannot re-encrypt the modified intercept in a way that the final party will be able to decrypt it. (Because he has not stolen your private key. Therefore, only you can do this.)

Public/Private keys are used as an un-forgeable form of identification that is employed during the per-conversation negotiation of an initial "session key" (through the Diffie-Hellman process referred to by the referenced web site). The public key is acceptable proof that any message which it is capable of decrypting must have come from you: that the other-side, no matter which one of "your" public keys he is using, must be negotiating a session-key with you.
I would just like to put in a minor nitpick here, you don't decrypt anything with a public key. Public keys are for encrypting, or (in this case) verifying signatures. Private keys are for decrypting, or (in this case) generating signatures.

Quote:
Originally Posted by atelszewski View Post
Let's put the blame on me, saying that I'm not explicit enough ;-)
I admire your patience

Quote:
The system I need to connect to is an rescue Linux, managed by the server provider.
Whenever the rescue system is rebooted, the host key fingerprint changes. This is the way they designed it. I have no control over that.
Does this rescue system also allow password authentication? If it does, and the attacker can obtain the password (e.g., by brute force guessing) they would be able to setup a MITM situation with you connected to them by pubkey auth, and they connect to the server by password auth.
 
Old 01-30-2017, 05:03 PM   #19
haertig
Senior Member
 
Registered: Nov 2004
Distribution: Debian, Ubuntu, LinuxMint, Slackware, SysrescueCD, Raspbian, Arch
Posts: 2,285

Rep: Reputation: 354Reputation: 354Reputation: 354Reputation: 354
Quote:
Originally Posted by atelszewski View Post
The system I need to connect to is an rescue Linux, managed by the server provider.
Whenever the rescue system is rebooted, the host key fingerprint changes. This is the way they designed it. I have no control over that.
Did they really "design" it this way, because that would be very non-standard, or did they just screw up and unknowingly and accidentally have the server regenerate keys on reboot? Can you contact them and ask? You never know, they might say, "Hey, thanks for pointing out our screw-up, we'll fix it right away!" Problem solved.
 
Old 01-30-2017, 06:31 PM   #20
atelszewski
Member
 
Registered: Aug 2007
Distribution: Slackware
Posts: 907

Original Poster
Rep: Reputation: Disabled
Hi,

Quote:
Originally Posted by ntubski
Does this rescue system also allow password authentication? If it does, and the attacker can obtain the password (e.g., by brute force guessing) they would be able to setup a MITM situation with you connected to them by pubkey auth, and they connect to the server by password auth.
Yes, it allows password auth.
But I'm going to be there only for a few hours, so that should not be a problem.
Actually, I can change the password after login, for something stupid strong.
And no, I will not connect with password, I will connect using pubkey.

Quote:
Originally Posted by haertig
Did they really "design" it this way, because that would be very non-standard, or did they just screw up and unknowingly and accidentally have the server regenerate keys on reboot? Can you contact them and ask? You never know, they might say, "Hey, thanks for pointing out our screw-up, we'll fix it right away!" Problem solved.
It's an Online.net's Dedibox server.
And yes, they designed it like that. I don't know what were their motives.
I contacted the technical assistance long time ago, suggested that they should at least make the host key fingerprint available on Web interface.
Unfortunately, nothing changed.
I was once confirming the fingerprint by asking the technical assistance, but it is lengthy and troublesome process.
And I don't know how were they obtaining the fingerprint themselves;-)

BTW, when the rescue OS boots, it downloads the public keys for root account from here.
This way the staff can access my server for assistance, when in rescue mode.


I hope you finally have the complete picture.
This whole mess is going to be temporary.
It will actually last long enough to login and cat authorized_keys.
So, do you think I can do it this way?

I know @haertig gave sensible reason against in Discovering remote SSH public keys: possible? thread, but:
  • I need to trust sshd. If you can confirm me that sshd does not leak user's public keys by design, then I'm going to stick with this,
  • it seems you have already confirmed MITM is not possible, but hell, ok, you have confirmed.

Can I connect now, please? :-)

--
Best regards,
Andrzej Telszewski
 
Old 01-30-2017, 08:29 PM   #21
ntubski
Senior Member
 
Registered: Nov 2005
Distribution: Debian, Arch
Posts: 3,590

Rep: Reputation: 1908Reputation: 1908Reputation: 1908Reputation: 1908Reputation: 1908Reputation: 1908Reputation: 1908Reputation: 1908Reputation: 1908Reputation: 1908Reputation: 1908
Quote:
Originally Posted by atelszewski View Post
  • I need to trust sshd. If you can confirm me that sshd does not leak user's public keys by design, then I'm going to stick with this,
  • it seems you have already confirmed MITM is not possible, but hell, ok, you have confirmed.

Can I connect now, please? :-)
I think you're fine, assuming you find the risk of an attacker breaking the default password acceptable.
 
Old 01-31-2017, 03:36 AM   #22
atelszewski
Member
 
Registered: Aug 2007
Distribution: Slackware
Posts: 907

Original Poster
Rep: Reputation: Disabled
Hi,

Quote:
Originally Posted by ntubski View Post
I think you're fine, assuming you find the risk of an attacker breaking the default password acceptable.
The password is different every reboot and it's already quite complex.
I can make it even more complex just after login.
I don't think anyone will have the chance to break it.

--
Best regards,
Andrzej Telszewski
 
Old 01-31-2017, 07:10 AM   #23
ntubski
Senior Member
 
Registered: Nov 2005
Distribution: Debian, Arch
Posts: 3,590

Rep: Reputation: 1908Reputation: 1908Reputation: 1908Reputation: 1908Reputation: 1908Reputation: 1908Reputation: 1908Reputation: 1908Reputation: 1908Reputation: 1908Reputation: 1908
Quote:
Originally Posted by atelszewski View Post
The password is different every reboot and it's already quite complex.
Ah, that sounds pretty safe then.
 
Old 02-02-2017, 08:27 AM   #24
sundialsvcs
LQ Guru
 
Registered: Feb 2004
Location: SE Tennessee, USA
Distribution: Gentoo, LFS
Posts: 9,078
Blog Entries: 4

Rep: Reputation: 3187Reputation: 3187Reputation: 3187Reputation: 3187Reputation: 3187Reputation: 3187Reputation: 3187Reputation: 3187Reputation: 3187Reputation: 3187Reputation: 3187
Quote:
Originally Posted by ntubski View Post
I would just like to put in a minor nitpick here, you don't decrypt anything with a public key. Public keys are for encrypting, or (in this case) verifying signatures. Private keys are for decrypting, or (in this case) generating signatures.
Well, that's actually backwards. The private key encrypts to produce a signature, and the public key decrypts it (and finds that it is able to do so). The important point is that it is able to do so: therefore, this (known) public key has to be derived from the (unknown) private key that must be in the possession of the corresponding party.

Quote:
Does this rescue system also allow password authentication? If it does, and the attacker can obtain the password (e.g., by brute force guessing) they would be able to setup a MITM situation with you connected to them by pubkey auth, and they connect to the server by password auth.
In everything SSH, you must make sure that it does not ... as it will do by default ... "ratchet down to the least-secure available authentication method: passwords."

If you can be assured of the physical integrity of the rescue machine ... if you can be confident that no one can log on to it directly and tamper with SSH keys ... then I believe that you can simply install one of your public keys onto it and thereby achieve the authentication requirements of your situation. If you know which key your ssh-agent negotiates, and if you know that this key exists only there, then you can be assured of the identity of the machine by virtue of the fact that you are able to log in to it using this key.

Only someone in possession of the corresponding private key can do such a thing. That means, "you." (And you must take steps to ensure that it does mean "you.")

An intruder who wanted to launch an MITM attack would have to steal your private key, since only this key can authenticate against that public key. If he is not in possession of your private key, he cannot generate traffic to "replay" to the real system. Alternatively, he would have to install a second key of his own.

For further proof, consider encrypting a copy of the ~/.ssh/authorized_keys file using GPG and a passphrase (or, much(!) better yet, a certificate) known/possessed only by you. Place this file on the rescue system. Upon connecting, compare the decrypted content to the existing file. You should be able to decrypt the file and its contents should exactly match. Now you know that you must be talking to the right system, and that no SSH keys have been substituted.

A known SHA1 signature of the encrypted file, combined with the fact that it is there, can be used as a "quick check."

- - -
Other strategies can be considered, if you know of a third-party secure machine that is known to be available to both your machine and the rescue. The rescue machine could be set up to establish a VPN tunnel (with client-to-client), using certificates, with a third-party server machine to which you also can connect. The rescue machine will accept incoming connections from no other network source. Now, you can connect to the same trusted third-party server and securely reach the rescue machine. This necessarily depends upon the rescue's ability to negotiate and automatically establish that connection, and upon the actual integrity of the third-party machine.

Last edited by sundialsvcs; 02-02-2017 at 08:34 AM.
 
Old 02-02-2017, 10:06 AM   #25
ntubski
Senior Member
 
Registered: Nov 2005
Distribution: Debian, Arch
Posts: 3,590

Rep: Reputation: 1908Reputation: 1908Reputation: 1908Reputation: 1908Reputation: 1908Reputation: 1908Reputation: 1908Reputation: 1908Reputation: 1908Reputation: 1908Reputation: 1908
Quote:
Originally Posted by sundialsvcs View Post
Well, that's actually backwards. The private key encrypts to produce a signature, and the public key decrypts it (and finds that it is able to do so). The important point is that it is able to do so: therefore, this (known) public key has to be derived from the (unknown) private key that must be in the possession of the corresponding party.
Please don't confuse signing with encryption (or verification with decryption).

https://en.wikibooks.org/wiki/Crypto...tal_signatures
Quote:
Many early explanations of public-key signature algorithms describe public-key signing algorithms as "encrypt a message with a private key". Then they describe public-key message verify algorithms as "decrypt with the public key". Many people prefer to describe modern public-key cryptosystems as having 4 independent high-level functions -- encrypt, decrypt, sign, verify -- since none of them (if properly padded to avoid chosen-ciphertext attacks) can be substituted for any of the others.[3] [4] [5] [6] [7] [8] [9] [10] [11] [12]
 
Old 02-02-2017, 11:21 AM   #26
sundialsvcs
LQ Guru
 
Registered: Feb 2004
Location: SE Tennessee, USA
Distribution: Gentoo, LFS
Posts: 9,078
Blog Entries: 4

Rep: Reputation: 3187Reputation: 3187Reputation: 3187Reputation: 3187Reputation: 3187Reputation: 3187Reputation: 3187Reputation: 3187Reputation: 3187Reputation: 3187Reputation: 3187
Wow ... that's a seriously messed-up(!) WikiPedia page, and I hope that someday someone takes a closer look at it.

When we talk about SSH in this context, we're actually not talking about "message signing" at all, and I now realize that I erred by using this terminology. I actually used the wrong term.

What I meant to say has nothing whatsoever to do with "host signatures" and so on. Rather, it has to do (only) with "the connection, itself," and with the significance of your ability to successfully make that connection (at all) using a certificate.

Even though you can generate public keys and install them on whatever target-system you wish to be able to connect to "password free," only you will be able to use those keys to do so, because only you possess(!) the corresponding, secret(!), private key.

"And that" ... (ahem, koff koff) ... "is the key."

If you are able to place a public key onto the rescue system, then you, and you alone, will be able to connect to it using that key.

If you need to be paranoid, then the suggestion of separately encrypting the authorized-keys file (and maybe by noting and settling-for a sha1sum of that file or of the GPG-file or both) provides a further means of verification that the SSH connection that you have now established must be the one that you intended – because it could not be any other.

----
FYI:™ "Message signing" is an unrelated concept that consists of making a secure hash (SHA1) of the content of some message, then encrypting the hash-value with the sender's private key. The recipient decrypts the signature (finding, first of all, that he is able to do so at all ... thus confirming the sender's identity), then verifies the hash to confirm that the message has not been altered.

Last edited by sundialsvcs; 02-02-2017 at 11:25 AM.
 
Old 02-02-2017, 12:08 PM   #27
ntubski
Senior Member
 
Registered: Nov 2005
Distribution: Debian, Arch
Posts: 3,590

Rep: Reputation: 1908Reputation: 1908Reputation: 1908Reputation: 1908Reputation: 1908Reputation: 1908Reputation: 1908Reputation: 1908Reputation: 1908Reputation: 1908Reputation: 1908
Quote:
Originally Posted by sundialsvcs View Post
FYI: "Message signing" is an unrelated concept that consists of making a secure hash (SHA1) of the content of some message, then encrypting the hash-value with the sender's private key. The recipient decrypts the signature (finding, first of all, that he is able to do so at all ... thus confirming the sender's identity), then verifies the hash to confirm that the message has not been altered.
Mixing up message signing with "private key encryption" like this only kind of works for RSA because in toy implementations all of signature, verification, encryption, and decryption operations are just modular exponentiation. But with Elliptic Curve keys, for example, message signing does not use encryption.
 
Old 02-02-2017, 06:31 PM   #28
sundialsvcs
LQ Guru
 
Registered: Feb 2004
Location: SE Tennessee, USA
Distribution: Gentoo, LFS
Posts: 9,078
Blog Entries: 4

Rep: Reputation: 3187Reputation: 3187Reputation: 3187Reputation: 3187Reputation: 3187Reputation: 3187Reputation: 3187Reputation: 3187Reputation: 3187Reputation: 3187Reputation: 3187
Quote:
Originally Posted by ntubski View Post
Mixing up message signing with "private key encryption" like this only kind of works for RSA because in toy implementations all of signature, verification, encryption, and decryption operations are just modular exponentiation. But with Elliptic Curve keys, for example, message signing does not use encryption.
I hereby graciously concede the point. Thank you for the clarification.
 
Old 02-07-2017, 05:08 AM   #29
atelszewski
Member
 
Registered: Aug 2007
Distribution: Slackware
Posts: 907

Original Poster
Rep: Reputation: Disabled
Hi,

Although the original question hasn't been answered, I received satisfactory answers.
Marking this one as solved.

Thanks!

--
Best regards,
Andrzej Telszewski
 
Old 02-07-2017, 08:50 AM   #30
ntubski
Senior Member
 
Registered: Nov 2005
Distribution: Debian, Arch
Posts: 3,590

Rep: Reputation: 1908Reputation: 1908Reputation: 1908Reputation: 1908Reputation: 1908Reputation: 1908Reputation: 1908Reputation: 1908Reputation: 1908Reputation: 1908Reputation: 1908
Quote:
Originally Posted by atelszewski View Post
Although the original question hasn't been answered,
I thought you answered your original question in post#14.
 
  


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
[SOLVED] ssh hangs when trying to secure shell to one particular host jjanderson5 Linux - Networking 3 10-21-2016 12:19 PM
Advise on secure remote ssh accessible 24/7 server in home network fritzxy Linux - Security 7 08-10-2014 08:48 PM
ssh: authenticity of host can't be established question opens x dialog joe_2000 Linux Mint 2 05-10-2014 06:09 AM
Is there a way to prevent this message:The authenticity of host can't be established. abefroman Linux - Server 8 11-27-2009 02:52 PM
no ssh logging in /var/log/secure mberd Linux - Security 4 05-27-2009 07:55 AM

LinuxQuestions.org > Forums > Linux Forums > Linux - Security

All times are GMT -5. The time now is 04:21 AM.

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