#70 Stronger SSH peer identity binding

[Anonymous]

Originally created by: Hawk777

As mentioned in the amanda-auth manual page:

When accepting an incoming conneciton, the SSH daemon gives Amanda information about the remote system in the $SSH_CONNECTION environment variable. Amanda parses this information to determine the remote address, and then performs a similar check to that done by the BSD authentications: the forward and reverse DNS entries for the remote host must match. As such, while SSH authentication can cryptographically ensure that the remote system is recognized (since it had a recognized secret key), its assurances about the remote host's identity are weaker and depend on the integrity of the DNS.

Clearly, this is not ideal, given that SSH provides us with cryptographically strong authentication. I would like to propose the following alternative:

In addition to the check already described, Amanda will also optionally accept (either in an environment variable or as a parameter to a command-line option) a hostname. Amanda will do all the validation she already does, but will also, in addition, absolutely demand that the hostname used in access control checks is equal to the one thus provided.

Of course, sometimes users can control the command line being executed via SSH. In this case, obviously there is no improvement in security since the user can provide whatever hostname they want in this option. There is no degradation, though, because Amanda should still perform all existing checks.

What this means, though, is that a security-conscious administrator has the option of locking down a specific key to a specific fixed command line in the Amanda user’s authorized_keys file, and that fixed command line can include the hostname to whom the key belongs. This prevents that host from impersonating any other host, because their key can only ever execute amandad with its own name passed in.

If this is a good idea, I could try to put together a patch, if that would help, though it might take me a while. I’d also be happy if someone else did it.

[Anonymous]

Originally posted by: chassell

It's not only TOFU ... but the number of things it doesn't have directly. We'd need to add on to SSH to get it up to SSL.

Do you feel SSL is a bad solution (not SSL+HTTP) somehow?

If it is bad, then is it bad enough to prefer SSH-with-extra-added-shared-secrets-and-shared-credentials-and-shared-global-ip-addresses?

I genuinely am looking at two infrastructures ... and we are talking about how to enhance layer-5 and layer-4 security.

Not decrease it!

On 9/23/19 8:16 PM, Christopher Head wrote:
Ah, that is the part I was missing about your opinion of SSH. I don’t use it that way. I actually check the fingerprint. After all, it only takes a few seconds to copy and paste the host key fingerprint from one machine, and the fingerprint query from the other machine, into a vim instance on two consecutive lines and see that they’re the same. The page you linked to did say, “Jim says yes. Everyone always does,” which I suppose makes me nobody 😉 though I accept the premise that most people don’t care enough about security and therefore don’t bother to actually check the fingerprints.
Checking fingerprints is an added pre-shared key.
Well, no, that’s meant to be solved by populating known_hosts and authorized_keys on each machine with the other machine’s keys (i.e. treating it was two unidirectional links, after which you get the same net effect).
That's more pre-shared keys mixed with a two-server exposed-port solution.

It sounds like you’re not inherently opposed to this improvement being made in Amanda, you just feel like you would prefer to operate your own systems in a different way?

No. I want anything that is Amanda-based ... to be secure out of the box and in nearly every standard use.

If we hand out a system with a huge "set of things you have to do on your own" ... it's a great way to build a huge "turn the brakes to manual" switch. The real question for the "let's add in a system that's not built into SSH and make sure SSH is in there somehow" ....

... is, why? No offense. But really?

—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHubhttps://github.com/zmanda/amanda/issues/70?email_source=notifications&email_token=AG4RPLTJCPET7V5N4UXTL5TQLF2AHA5CNFSM4B5H2EM2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD7M2SUA#issuecomment-534358352, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AG4RPLVS7BHGRCVAC6ONGCLQLF2AHANCNFSM4B5H2EMQ.

Confidentiality Notice | The information transmitted by this email is intended only for the person or entity to which it is addressed. This email may contain proprietary, business-confidential and/or privileged material. If you are not the intended recipient of this message, be aware that any use, review, re-transmission, distribution, reproduction or any action taken in reliance upon this message is strictly prohibited. If you received this in error, please contact the sender and delete the material from all computers.

[Anonymous]

Originally posted by: djmitche

Not to be a wet blanket, but this conversation is for naught if nobody implements it. At the moment there's not a lot of developer bandwidth on the project, and there's plenty of work queued. So perhaps it's best to set this conversation aside for the moment and focus on more actionable work?

[Anonymous]

Originally posted by: chassell

Yeah I'm being a little snide and don't need to be.

Just being a curmudgeon.

On 9/23/19 9:02 PM, chassell wrote:
* WARNING: External Email*
It's not only TOFU ... but the number of things it doesn't have directly. We'd need to add on to SSH to get it up to SSL.

Do you feel SSL is a bad solution (not SSL+HTTP) somehow?

If it is bad, then is it bad enough to prefer SSH-with-extra-added-shared-secrets-and-shared-credentials-and-shared-global-ip-addresses?

I genuinely am looking at two infrastructures ... and we are talking about how to enhance layer-5 and layer-4 security.

Not decrease it!

On 9/23/19 8:16 PM, Christopher Head wrote:
Ah, that is the part I was missing about your opinion of SSH. I don’t use it that way. I actually check the fingerprint. After all, it only takes a few seconds to copy and paste the host key fingerprint from one machine, and the fingerprint query from the other machine, into a vim instance on two consecutive lines and see that they’re the same. The page you linked to did say, “Jim says yes. Everyone always does,” which I suppose makes me nobody 😉 though I accept the premise that most people don’t care enough about security and therefore don’t bother to actually check the fingerprints.
Checking fingerprints is an added pre-shared key.
Well, no, that’s meant to be solved by populating known_hosts and authorized_keys on each machine with the other machine’s keys (i.e. treating it was two unidirectional links, after which you get the same net effect).
That's more pre-shared keys mixed with a two-server exposed-port solution.

It sounds like you’re not inherently opposed to this improvement being made in Amanda, you just feel like you would prefer to operate your own systems in a different way?

No. I want anything that is Amanda-based ... to be secure out of the box and in nearly every standard use.

If we hand out a system with a huge "set of things you have to do on your own" ... it's a great way to build a huge "turn the brakes to manual" switch. The real question for the "let's add in a system that's not built into SSH and make sure SSH is in there somehow" ....

... is, why? No offense. But really?

—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHubhttps://github.com/zmanda/amanda/issues/70?email_source=notifications&email_token=AG4RPLTJCPET7V5N4UXTL5TQLF2AHA5CNFSM4B5H2EM2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD7M2SUA#issuecomment-534358352https://github.com/zmanda/amanda/issues/70?email_source=notifications&email_token=AG4RPLTJCPET7V5N4UXTL5TQLF2AHA5CNFSM4B5H2EM2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD7M2SUA#issuecomment-534358352, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AG4RPLVS7BHGRCVAC6ONGCLQLF2AHANCNFSM4B5H2EMQhttps://github.com/notifications/unsubscribe-auth/AG4RPLVS7BHGRCVAC6ONGCLQLF2AHANCNFSM4B5H2EMQ.

Confidentiality Notice | The information transmitted by this email is intended only for the person or entity to which it is addressed. This email may contain proprietary, business-confidential and/or privileged material. If you are not the intended recipient of this message, be aware that any use, review, re-transmission, distribution, reproduction or any action taken in reliance upon this message is strictly prohibited. If you received this in error, please contact the sender and delete the material from all computers.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHubhttps://github.com/zmanda/amanda/issues/70?email_source=notifications&email_token=AG4RPLVGN5E7DLEIRE7CCRTQLF7OHA5CNFSM4B5H2EM2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD7M44HQ#issuecomment-534367774, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AG4RPLSWZXG3TUOSZQS2NFTQLF7OHANCNFSM4B5H2EMQ.

Confidentiality Notice | The information transmitted by this email is intended only for the person or entity to which it is addressed. This email may contain proprietary, business-confidential and/or privileged material. If you are not the intended recipient of this message, be aware that any use, review, re-transmission, distribution, reproduction or any action taken in reliance upon this message is strictly prohibited. If you received this in error, please contact the sender and delete the material from all computers.

[Anonymous]

Originally posted by: Hawk777

@chassel From my perspective, SSH and TLS are both very strong, secure protocols (at least, when used properly, which SSH without fingerprint checks is not IMO). So, for me, how would I choose which one I consider more secure? Well, here’s how: if Amanda speaks TLS, then Amanda is listening on a network port and doing network communication itself, directly (presumably with a TLS library). If Amanda speaks SSH, then it’s behind an SSH server which does the network communication. Given that both protocols are cryptographically secure, and given that I’m going to be running an SSH server anyway so that I have remote login capabilities, I would prefer the deployment option that reduces the unauthenticated Internet-facing attack surface: that’s SSH, since Amanda only comes into the picture once authentication is complete. This isn’t really even related to the protocols; it’s more an accident of their historical implementation (SSH as a separate process and TLS as a library) which still exists today.

Anyway, the fact is that Amanda over SSH already exists, is convenient, and has certain advantages. What’s wrong with making it better, when it’s so close to being fully securable?

@djmitche Improving security is a topic I care about. As I said in a previous message, I may have time to work on this sometime. Therefore, in my opinion, it makes sense to continue this conversation; if we just set this whole thing aside, then I wouldn’t bother working on it knowing that my work might end up being for nought anyway because we didn’t finish deciding what we wanted.

As for working on more actionable items… well… I tried that one time, when I had issue [#69]. That… didn’t go well. I stared at tape_action for IIRC about 3 hours and ended up confused and no closer to a solution. This is open source, so there are areas where each of us understand more or less, and, honestly, areas where each of us care more or less. Saying that I shouldn’t work on this particular issue because it’s not very important is unlikely to result in me working on something else. Given that my Amanda install isn’t hitting those other issues, it’s more likely to result in me not working on Amanda at all.