On Sunday 29 December 2019 18:09:35 Nathan Stratton Treadway wrote:

> On Sun, Dec 29, 2019 at 15:38:01 +1100, duluxoz wrote:
> >     /usr/sbin/amssl --client --create-client-cert myclient --common
> > myclient --server myserver
> >
> > And received this output:
> >
> >     Connecting to server... amssl: failed connect or ssl handshake:
> > No route to host,IO::Socket::IP configuration failed at
> > /usr/sbin/amssl line 180.
> >
> > Both server and client are Centos 7 freshly updated, and both are
> > using the latest amanda repository. Both servers can ping each other
> > via both (internal) DNS and direct IP Address.
>
> I am not familiar with amssl and don't know how it works overall, but
> /usr/sbin/amssl [looking in v3.5.1] line 180 appears to be simply
> using the value passed in by the "--server" option on the command line
> as the host name for a network connection it tries to make.
>
> Normally the "No route to host" message would make me think the remote
> host is competely down, but if you are sure your client can ping the
> server using the host name given on the amsll command line, I suppose
> my next guess would be some sort of firewalling is causing an explicit
> "no route" ICMP message to come back to the client when it attempts to
> initiate that specific connection.
>
> Depending on the details of the firewall rules, you may be able to
> work around it by specifying an (allowed-by-the-firewall) port number
> using the "--port" command (on both the client and server side,
> presumably). (The default port used by amssl is 10081.)
>
> In any case I don't believe the "No route to host" message here is
> anything Amanda specific: at least based on looking at the code
> without actually trying to run anything, it appears to be the error
> message raised by the Perl IO::Socket::IP library when the Perl
> IO::Socket::SSL library is first trying to establish the network
> connection to the server, before any actual certificate-related
> processing can happen.
>
>                                               Nathan

Never having heard of it till now, and I've been using amanda since late 
1998, I have to assume someone wrote it and added it to amanda to 
address a problem either as a way to encode intermachine comm to battle 
a perceived MITM attack or as a lockin means (Zmanda?) or solving some 
sort of a local access problem?  Wasting cpu cycles only makes sense if 
some portion of the path to the client machine has to traverse the 
public net, otherwise its wasted time and cycles to do it. Since nothing 
I do with amanda here ever gets out of the private 192.168.xx.yy block I 
could care less and will likely never use it. I would consider it a 
solution in search of a problem that does not exist here unless someone 
can find and identify that problem.

Thanks Nathan, for any more in depth discussion.

> ----------------------------------------------------------------------
>------ Nathan Stratton Treadway  -  [email protected]  -  Mid-Atlantic
> region Ray Ontko & Co.  -  Software consulting services  -  
> http://www.ontko.com/ GPG Key:
> http://www.ontko.com/~nathanst/gpg_key.txt   ID: 1023D/ECFB6239 Key
> fingerprint = 6AD8 485E 20B9 5C71 231C  0C32 15F3 ADCD ECFB 6239

Copyright 2019 by Maurice E. Heskett
Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>

  • AMSSL duluxoz
    • Re: AMSSL Nathan Stratton Treadway
      • Re: AMSSL Gene Heskett

Reply via email to