On Mon, Aug 31, 2015 at 9:02 AM, Bostjan Skufca <bostjan@xxxxxx> wrote: > On 30 August 2015 at 18:53, Nico Kadel-Garcia <nkadel@xxxxxxxxx> wrote: >> >> On Sun, Aug 30, 2015 at 6:57 AM, Bostjan Skufca <bostjan@xxxxxx> wrote: >> > those were my thoughts, exacly, except that I was thinking about using "dig >> > +short HOST | ..." which has the cleanest output of all. >> >> It can get a bit confusing with >> round-robin DNS, which can give multiple responses. > > > Care to illustrate your use case? For confusion without "round-robin DNS"? Sure. # dig +short www.google.com 63.117.14.21 63.117.14.23 63.117.14.25 63.117.14.22 63.117.14.24 63.117.14.26 63.117.14.20 63.117.14.27 That's an unordered list of not-necessarily identical targets, it's quite dynamic, and the exposed IP addresses *do not necessarily have the same SSH key*. Moreover, the resolution of the specific IP addresses when establishing a new connection is not really "round-robin". working its way through a particular order. The "round-robin" is typically a common, but subtly mistaken one. It's actually multiple A records, and that is the local libc library's problem to resolve, and the results can be.... unpredictable. A more powerful specific local example is Samba or Active Directory servers for a particular domain. The DNS domain for thei "EXAMPLE" Active Directory might be "example.com". The AD or Samba servers, both active and failover, will publish A records for themselves as "example.com", "_kerberos.tcp.example.com", and other multiple A records, no matter if they have individual host names of "samba1.example.com" and "samba2.example.com". Should those multiple AD servers have identical SSH keys, simply to prevent confusion if I look up "example.com" and need to talk to it as an admin? Or do I personally have to keep track, somehow, of which server is which and talk to its individual name, even if all I really want to do is set up a shared configuration, or even log into it to do DNS zone transfers on localhost to get configuration information for the entire domain, and I *have* the designated root SSH keys for exactly such access? > I am having difficulties imagining it: > 1. If you are managing particular host, you connect to its IP directly > (possibly via DNS entry). > 2. If that DNS entry represents a service that has a load-balanced IP > list, you should not be connecting to arbitrary host in that list, but > use dedicated IP of particular server in that list, or am I missing > something here? You're missing that what people *should* do is often not trivially available to the SSH client. There are even poorly configured load balancer environments where the load balancer exposed entry was the only to get at the SSH service directly from outside the local network That drove me *nuts* for a particular svn+ssh environment some years back, I really wanted to hit the admin who did that with a brick because it was an intermittent problem. We won't even *discuss* the problems caused because the svn+ssh setup was already split-brain with write privileges on both servers. > Additional point: > If your environment gets complicated enough, it probably justifies > usage of ProxyCommand directive with reference to dedicated > script/program that does the necessary plumbing (technical and > policy-wise) to set up your connection. > > b. Which I'd have to set up manually for every remote host target, and would have to propagate or configure on any workstation I happen to work from. Let's see, hand-tuning .ssh/config everywhere, or just throwing out hostkey based SSH verification so I don't have to spend time confirming new keys and can get on with my work.... I know which is the better security option, but I also know which is the more common "stop bothering me about this!" option. _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
