Menu
▾
▴
#70 Stronger SSH peer identity binding
open
nobody
None
2019-09-24
2016-03-05
Anonymous
No
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.
Originally posted by: djmitche
In this scenario, how does amandad determine the remote hostname that it wants to verify?
Originally posted by: Hawk777
Actually, now that I’ve had some time to think more about this, I have a new opinion on the right behaviour.
Let’s consider the behaviour right now. According to the
amanda-authman page, Amanda takes the IP address from the$SSH_CONNECTIONenvironment variable and does a reverse DNS lookup to find the corresponding hostname. Let’s further break this down into two cases and analyze the security of each case.Case 1 (non-security-critical environment): The administrator just lists acceptable keys in
authorized_keys, and nothing else. That means any incoming connection from an authorized machine can execute an arbitrary command as the Amanda user. This command line could be something along the lines ofSSH_CONNECTION=something amandad args. That means the connection can claim to be from any possible host, and Amanda will believe it. No need to attack the DNS infrastructure at all.Case 2 (security-critical environment): The administrator lists acceptable keys in
authorized_keysalong with thecommand=option for each key. That means that incoming connections can runamandad argsand nothing else. Thus there is no opportunity for the client to muck with$SSH_CONNECTION. The identity of the remote host is as strong as the reverse DNS lookup or ability of the remote host to switch its IP address, which is better than nothing but usually not very strong.Now let’s consider what happens if we dump the DNS lookups altogether and just pass the hostname on the command line.
Case 1: The peer can ask for whatever hostname it wants. Amanda will accept it. This is no worse than what we already have.
Case 2: The peer’s hostname is tightly bound to the choice of key used to authenticate, because it’s part of the
command=option inauthorized_keys. This is much better than what we already have.Originally posted by: djmitche
In case 1, the user is relying on the secrecy of the SSH private key, and any network-based access controls in place. For many environments this is sufficient, and the improvement is to go to case 2. However, your suggestion to inject a malicious
SSH_CONNECTIONis a new attack vector that weakens this case, and Amanda's documentation does recommend including "command=" inauthorized_keys. Perhaps we could change "marginal increase in security" to some stronger language.For case 2, though, you seem to be suggesting that the hostname should be determined from the SSH key used. Since all of these attacks assume disclosure of the SSH private key, this accomplishes nothing more than disabling host verification.
Defense in depth is good, but it requires that each layer be separate. We have that now (assuming case 2 without your suggested modification): layer 1 is the SSH private key, and layer 2 is the forward and reverse DNS. The first is pretty strong, and the second is substantially weaker but still useful as an independent layer.
If you want a more secure configuration, you will need to add an additional layer, and that must begin in some fundamental characteristic of the Amanda server that is different from its filesystem contents (containing the SSH private key) and its IP address. That doesn't leave much! I can see a few related ideas, but I see them as negligible increments in system security and/or bringing high usability costs:
- server password -- comes from the same filesystem containing the private key
- challenge/response using some external cryptographic verification (so, verify the server has access to an HSM of some sort) -- very difficult to use, and easy to abuse given filesystem access on the Amanda server
Originally posted by: Hawk777
I think you might be misunderstanding my point. I’m not talking about a host that has stolen someone else’s SSH key. Rather I’m talking about one authorized host impersonating a different but also authorized host.
To be more concrete:
A.example.comis the Amanda server. It takes backups ofB.example.comandC.example.com. Thus,A(and nobody else) is authorized to log intoBandCto do dumps, andBandCare both authorized to log intoAto do restores. Let’s assumerecovery-limit same-host. Let’s further assume thatA,B, andCeach possess their own SSH private keys, and that nobody has stolen anyone else’s.Today, in case 1 (no
command=field),Bcan read outC’s backup data by logging intoAusing its own (B’s) key, but running a custom command line that changes$SSH_CONNECTIONto containC’s IP address. Amanda will dutifully perform a reverse DNS lookup on the IP address from$SSH_CONNECTION, conclude that the remote peer must beC, and grant access to the dump data.Given my proposed change, in case 1,
Bcan still readC’s backup data, only this time it does so by passingC’s hostname on the Amanda command line instead of changing the$SSH_CONNECTIONenvironment variable. No change inB’s attack capabilities.Today, in case 2 (
command=field provided), ifBchanges its IP address to matchC(or mucks with DNS resolution) and then connects toA, it can use its own (B’s) key, but$SSH_CONNECTIONwill naturally end up containingC’s IP address (or an address which maps toC’s hostname), which Amanda will reverse-DNS toC’s hostname, resulting in granting access toC’s dump data.Given my proposed change, in case 2,
B’s IP address and DNS records are completely irrelevant: becauseBis logging in using its own (B’s) key,A’sauthorized_keysfile will runamandad -authenticated-hostname B.example.com(due to itscommand=entry), which will denyBaccess toC’s dump data.Naturally, in all cases,
D.example.comcan’t log intoA.example.combecause its (D’s) key isn’t inA’sauthorized_keysfile. This hasn’t changed at all.Originally posted by: djmitche
Ah, I see -- I was thinking only of the server-to-client connections. So the proposal is to add an option to the amandad command line giving the remote hostname, then recommend using distinct keys for each client and configuring authorized_keys to map those keys to the corresponding hostnames.
I think that would be valuable. Ironically, your suggestion of overriding SSH_CONNECTION would allow you to implement this without any code changes in Amanda:
The quoting here would be interesting, and I'm not suggesting this is the right solution -- just that it's possible now, and could be made a lot easier with a little code change.
Originally posted by: Hawk777
Yes, that’s what I was proposing. Each client is a different machine, so I assumed it would have its own unique key.
Actually, I did think of your idea, overriding
$SSH_CONNECTIONIn thecommand=string. The problem with that is that$SSH_CONNECTIONcontains IP addresses, so you’re still relying on DNS not lying to you. It’s better than nothing (it defeats the change-my-IP-address attack), but it doesn’t go as far as passing the hostname directly.Originally posted by: chassell
from telecom, I can say that the only real sure solution is widespread certificates / openssl and/or in-reverse connections.
Ticket changed by: chassell
Originally posted by: Hawk777
It’s perfectly reasonable for a set of mutually untrusting machines to all be backed up by the same central backup server, and the facility exists for this to be done via SSH. The question being discussed here is file restoration, for which connections are made from the Amanda client to the Amanda server machine. Multiple mutually untrusting people can have accounts on the same server; Alice is prevented from accessing Bob’s user account by having different SSH keys. If you look at something like Github or Gitlab or any of the self-hosted Git hosting systems, they generally tend to all share a single user (usually named
git, hencegit@github.com), and yet, again, by use of SSH keys, different clients can be distinguished and given access to exactly the things they should have access to, and no more. There is no fundamental difference between Amanda and these other systems here. There is nothing missing from the cryptography and authentication. There is only a tiny missing piece, which is the ability to pass on that strong authentication data to Amanda itself. Please re-open this issue.Originally posted by: djmitche
@Hawk777 would you consider making a PR to change amandad to allow this?
Originally posted by: Hawk777
Eventually, I suppose? I don’t have a lot of time. I thought the point of leaving the issue open was to document that a solution exists but hasn’t been implemented yet. But eventually I might get around to it.
Originally posted by: chassell
I understand, but that's not the technique that Amanda is built around. It's interesting but it is different and we don't have a host-host style association between clients and servers at all (coming from VOIP and server-server network security). If we did, security between those two could be a nicer link for convenience.
TL;DR:
SSH is designed to repeat (after a trusted first time) one specific anonymous-client-to-fixed-server authentication test. This validates a DNS lookup or IP with the correct server-key once in a trusted session. Repeating that one-way link doesn't validate the client. It's not a host-host association and never will be, but is only a remote credential authentication done into a single verified-one-sided-endpoint.
A host-host association for Amanda is an excellent idea but it's not possible with an SSH-client link. Any client can be spoofed if it has the credentials and that's okay.
WHAT DO WE HAVE NOW?
Amanda's central idea (which becomes more important with IPv6) is ...
Each storage point (each DLE-included disk client) allows authentication (via shared secrets) with its own client-software listener
Restoration is done in reverse by the client reaching a central-server address (some address) and requesting restores from its known-DLE name over a range of time from a set available.1
NOTE: This is a somewhat reasonable technique, mostly because (for older systems / tapes / network links) plans for a nighttime-or-downtime backup needed coordination and needed a single low-buffering stream to store data into storage media. Backup shouldn't require buffering everything then writing out... because that's a waste of bandwidth. On the other hand, restoration must occur at any time at all and be, in some fashion, totally distinct and carefully guarded.
The backup itself is the highest amount of security needed, but the restore is a critical-to-get-right situation. Both are caring for the 'family-jewels' and any impersonation or malware-takeover of either side can make the entire storage security system useless. Most of the time, of course, this is entirely within highly secured networks or data-centers anyway.
We don't really have requirements placed on the restore to come from the same host, though it makes the most sense if we had a different style of DLE-client-to-server sort of association. Currently we don't.
On 9/16/19 8:03 PM, Christopher Head wrote:
It’s perfectly reasonable for a set of mutually untrusting machines to all be backed up by the same central backup server, and the facility exists for this to be done via SSH. The question being discussed here is file restoration, for which connections are made from the Amanda client to the Amanda server machine. Multiple mutually untrusting people can have accounts on the same server; Alice is prevented from accessing Bob’s user account by having different SSH keys. If you look at something like Github or Gitlab or any of the self-hosted Git hosting systems, they generally tend to all share a single user (usually named git, hence git@github.comgit@github.com), and yet, again, by use of SSH keys, different clients can be distinguished and given access to exactly the things they should have access to, and no more. There is no fundamental difference between Amanda and these other systems here. There is nothing missing from the cryptography and authentication. There is only a tiny missing piece, which is the ability to pass on that strong authentication data to Amanda itself. Please re-open this issue.
—
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=AG4RPLW32MRJ7V3ROHB5RQ3QKA3FRA5CNFSM4B5H2EM2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD63BIBY#issuecomment-532026375, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AG4RPLSOALDDQ4AKQHVINK3QKA3FRANCNFSM4B5H2EMQ.
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.
Originally posted by: chassell
We certainly can consider it when we see it. There are some who would like SSH-based everything and I trust SSH quite a lot myself.
On 9/16/19 8:54 PM, Dustin J. Mitchell wrote:
@Hawk777https://github.com/Hawk777 would you consider making a PR to change amandad to allow this?
—
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=AG4RPLV5RAO7GBBCJCUZS3DQKBBFLA5CNFSM4B5H2EM2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD63DXSY#issuecomment-532036555, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AG4RPLWLOW63SPVCXYOBVOTQKBBFLANCNFSM4B5H2EMQ.
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.
Ticket changed by: chassell
Originally posted by: chassell
We can consider maybe an alternative to simplistic-SSH ... but something host-host based would be nice for restore.
Originally posted by: Hawk777
I don’t entirely understand. What exactly is SSH missing, cryptographically speaking? A connection is opened from machine FOO to machine BAR. The question is, can machine BAZ pretend to be either FOO or BAR. The answer is no. If BAZ tries to pretend to be FOO, it will not be able to: pubkey authentication would be used, BAR’s
authorized_keyswould have an entry for FOO, and only FOO would have the corresponding private key in itsid_rsa; if BAZ tries to pretend to be FOO, then either there will be no entry in BAR’sauthorized_keysfor BAZ’sid_rsa, so it will not even be able to connect, or there will be such an entry, but it will properly identify the connection as coming fromBAZ(by means of thecommand=field). On the other hand, if BAZ tries to pretend to be BAR, it will also not be able to: when FOO tries to connect to BAR but actually connects to BAZ, BAZ will present its hostkey, which will not match the legitimate hostkey for BAR, so FOO will reject the connection attempt.This sounds a lot like mutual authentication to me. So what exactly is missing? You said “Any client can be spoofed if it has the credentials and that's okay,” but that sounds kind of vacuous—can’t any authentication scheme be spoofed if the attacker steals the credentials from the legitimate entity? I’m sorry, I simply don’t understand what exactly is missing.
Originally posted by: Hawk777
Oh, and please don’t take me as someone “who would like SSH-based everything.” While I do like the fact that using SSH reduces attack surface (my machines will be listening on SSH for remote access anyway, so putting Amanda behind it with authentication required before running Amanda means no increase in attack surface, while having Amanda do the authentication itself with something like TLS would mean another listening service), honestly, what I care most about is Amanda being secure (both requiring authentication of the peer before doing anything, and not sending data over the Internet in cleartext). At the time I didn’t realize
auth sslexisted; is it kind of new? I was only familiar withbsd,bsdtcp, andbsdudp(insecure),krb5(not really usable in a decentralized environment),local(not usable over the Internet at all),rsh(insecure), andssh(what seemed like the only option that was even slightly secure, with the exception of this issue).Originally posted by: chassell
Keys can be copied between clients. Very simple. I do it all day long.
From: Christopher Head notifications@github.com
Sent: Tuesday, September 17, 2019 8:39 PM
To: zmanda/amanda amanda@noreply.github.com
Cc: Chris Hassell Chris.Hassell@betsol.com; State change state_change@noreply.github.com
Subject: EXTERNAL: Re: [zmanda/amanda] Stronger SSH peer identity binding (#70)
* WARNING: External Email*
A host-host association for Amanda is an excellent idea but it's not possible with an SSH-client link. Any client can be spoofed if it has the credentials and that's okay.
I don’t entirely understand. What exactly is SSH missing, cryptographically speaking? A connection is opened from machine FOO to machine BAR. The question is, can machine BAZ pretend to be either FOO or BAR. The answer is no. If BAZ tries to pretend to be FOO, it will not be able to: pubkey authentication would be used, BAR’s authorized_keys would have an entry for FOO, and only FOO would have the corresponding private key in its id_rsa; if BAZ tries to pretend to be FOO, then either there will be no entry in BAR’s authorized_keys for BAZ’s id_rsa, so it will not even be able to connect, or there will be such an entry, but it will properly identify the connection as coming from BAZ (by means of the command= field). On the other hand, if BAZ tries to pretend to be BAR, it will also not be able to: when FOO tries to connect to BAR but actually connects to BAZ, BAZ will present its hostkey, which will not match the legitimate hostkey for BAR, so FOO will reject the connection attempt.
This sounds a lot like mutual authentication to me. So what exactly is missing? You said “Any client can be spoofed if it has the credentials and that's okay,” but that sounds kind of vacuous—can’t any authentication scheme be spoofed if the attacker steals the credentials from the legitimate entity? I’m sorry, I simply don’t understand what exactly is missing.
—
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=AG4RPLVPX3YUIUELDDHKF7LQKGIDNA5CNFSM4B5H2EM2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD66THEI#issuecomment-532493201, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AG4RPLQN27BA3GB3XMNUI63QKGIDNANCNFSM4B5H2EMQ.
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.
Originally posted by: Hawk777
Well… uh… of course they can. So can TLS private keys. So can any authentication credential. I’m really not seeing the point. If the clients don’t trust each other because they’re operated by different administrators, then neither administrator would be willing to share the client key with the other administrator, so said copying won’t happen. If the clients are operated by the same administrator but they’re not supposed to trust each other for isolation reasons, then an administrator who copies a key from one to the other is being, to put it bluntly, pretty dumb. If the clients trust each other, then it doesn’t matter if the key is copied from one to the other, because they trust each other.
Originally posted by: chassell
That’s not a host key, nor something tied to any unique quality of a host/server. That’s the client-user creds only. Case closed. There’s no host-host mutual IP-tied infrastructure for SSH. It’s one way .. client to server, where the server has an open port and a known IP… that’s fixed.
The only secure way is to get reverse connections confirmed. That’s important enough in all other spheres of critical data queries/transfer, if you don’t have a public central server.
From: Christopher Head notifications@github.com
Sent: Tuesday, September 17, 2019 11:43 PM
To: zmanda/amanda amanda@noreply.github.com
Cc: Chris Hassell Chris.Hassell@betsol.com; State change state_change@noreply.github.com
Subject: EXTERNAL: Re: [zmanda/amanda] Stronger SSH peer identity binding (#70)
* WARNING: External Email*
Keys can be copied between clients. Very simple. I do it all day long.
Well… uh… of course they can. So can TLS private keys. So can any authentication credential. I’m really not seeing the point. If the clients don’t trust each other because they’re operated by different administrators, then neither administrator would be willing to share the client key with the other administrator, so said copying won’t happen. If the clients are operated by the same administrator but they’re not supposed to trust each other for isolation reasons, then an administrator who copies a key from one to the other is being, to put it bluntly, pretty dumb. If the clients trust each other, then it doesn’t matter if the key is copied from one to the other, because they trust each other.
—
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=AG4RPLQ4REVCGNYFCLZLBZ3QKG5W7A5CNFSM4B5H2EM2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD663V4I#issuecomment-532527857, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AG4RPLTMUGOWKDTWVHBUBPDQKG5W7ANCNFSM4B5H2EMQ.
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.
Originally posted by: Hawk777
Please, please, PLEASE help me understand what I’m missing here. The “client key” is tied to the host, because each host has a different one. Because if you’re running your box, and I’m running my box, guess what? I’m not going to share my box’s key with you to put on your box. My box’s client key is unique to my box, because I’m not willing to share it with anyone else, and I’m not silly enough to put it on a different one of my boxes.
Originally posted by: Hawk777
Having slept on it, I think we might be having trouble understanding each other (or at least I might be having trouble understanding you) because we’re talking about things in a bit of a vague way.
If I understand correctly, you’re of the opinion that SSH authentication is insecure in some way (maybe not totally insecure, but not totally secure either). That means you think there’s some sort of attack which is possible against SSH authentication, as I’ve proposed it to be used here (presumably an attack which would be protected against by some other form of authentication, but I think that’s not too relevant to figure out right now). Do you think we could talk in more concrete terms? Would you mind listing out the steps to perform the attack you think is possible? Then I would have to either (1) admit that the attack is possible, (2) identify one step and say why I think it’s impossible, or (3) admit that what you say is possible but say why I don’t consider it an attack.
Thanks! I’d like to understand what your concern is, because if I (or anyone else) implements this, I’d like it to be as secure as possible.
Originally posted by: chassell
@Hawk777 there's definitely a miscommunication in what you think I think..
https://jameshfisher.com/2018/03/16/how-to-create-an-ssh-certificate-authority/
Here's a good lineup of what needs to be conquered ... but SSH is not good enough on its own to do a large number of systems that securely can be contacted and authenticated-on-first-use. This is the problem with "trust-on-first-use" and it really gets to be an issue outside of a small network. A reboot or an upgrade outside your knowledge... can make all your SSH targets mistrust each other and become a security risk again.
Here's a quote: "TOFU has the weakness that a man-in-the-middle attack can be performed each time an employee tries to SSH to a machine for the first time. With more employees and more servers, the opportunities for a man-in-the-middle attack grow quadratically. Despite this weakness, TOFU is used by SSH clients by default, and thus by most organizations."
So to be clear again ....
1) SSH is an excellent way to authenticate an unknown-addr client into a well-known-addr server and to maintain a bidirectional link afterward for a long time. Repeating that original link (same direction), after it is established once and externally validated, is quite secure. (There could even be a weird-and-nonstandard "one-credential-for-each-IP" if desired ... but that's added on to SSH.)
2) SSH is NOT an excellent way to authenticate and secure first-time-secure connections easily into a server known only by DNS queries. Any DNS-discovered certificate and trust association (i.e. keys that sign keys that sign keys etc...) will need a new system to transmit, validate, update and pre-share things in advance.
3) SSH is NOT an excellent system for reversing the connection and making a pure and authenticated connection into a previously-seen client address from the server that was connected earlier. There's no requirement anyone can ever get back to the same client as called it before, and you'd never know for certain (by design) that that client was anything related to the first ... even if it correctly "backwards-sent" some sort of authentication that matched.
Those are the only two issues with SSH.
Originally posted by: chassell
Maybe the best thing to clarify is that SSH is what could be called a good layer-4 secure protocol. Once you have gotten down through layer-5 ... (i.e. picked a address/port that's verified valid) ... you can establish a new layer-4 that is excellent and secure, over and over and over.
To be more exact, layer-6 destinations (changing users/roles and URLs into access) can be handled by SSH because they are a one-way link from a role into a service. That's what layer 6 is, like a phone call.
Layer-1 == one way byte sequences getting through to a device
Layer-2 == N-way byte sequences received into one address/kernel when desired
Layer-3 == multi-hop routing of packets of a 'reasonable' length from kernel-to-kernel (anywhere)
Layer-4 == bidirectional streams of bytes from a program (passed by kernels) to another program
Layer-5 == finding/detecting a destination and initiating a layer-4 connection
....
Originally posted by: Hawk777
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.
Well, no, that’s meant to be solved by populating
known_hostsandauthorized_keyson each machine with the other machine’s keys (i.e. treating it was two unidirectional links, after which you get the same net effect).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?