Wrong principal in request using virt interface - Kerberos

This is a discussion on Wrong principal in request using virt interface - Kerberos ; I'm currently using openssh-4.3p2 compiled with krb5-1.4.4 and the GSSAPI Key Exchange patch (gsskex-20060223). On my current system this works fine. I'm moving the server to a new cluster of RHE hosts that use virtual interfaces (eg. eth0:1) to allow ...

+ Reply to Thread
Results 1 to 7 of 7

Thread: Wrong principal in request using virt interface

  1. Wrong principal in request using virt interface

    I'm currently using openssh-4.3p2 compiled with krb5-1.4.4 and the GSSAPI
    Key Exchange patch (gsskex-20060223). On my current system this works
    fine.

    I'm moving the server to a new cluster of RHE hosts that use virtual
    interfaces (eg. eth0:1) to allow for failover to a new host while still
    maintaining the original IP address. On this new system I'm getting the
    following error when I run sshd in debug (-ddd) mode:

    Wrong principal in request

    To simplify things, I set up a virtual interface on my own Redhat
    workstation where I'm also running my own KDC. I'm able to get the same
    error.

    I have 2 IP addresses and 2 hostnames associated with the 2 interfaces
    (one of them a virtual interface) on my workstation:

    interface hostname ip
    -----------------------------------------
    eth0 gort.home.org 192.168.0.2
    eth0:1 cvs.home.org 192.168.0.200

    I've created 2 service principals and added them to /etc/krb5.keytab:

    host/gort.home.org@HOME.ORG
    host/cvs.home.org@HOME.ORG

    When I connect to the sshd server using my gssapi-with-mic/gsskex enabled
    client using the hostname gort.home.org everything works fine. But if I
    connect using the hostname cvs.home.org I get the "Wrong principal in
    request" error.

    >From the client side when I run klist it shows I have valid credentials:


    krbtgt/HOME.ORG@HOME.ORG
    host/cvs.home.org@HOME.ORG

    I can find no errors in /var/log/krb5kdc.log or /var/log/messages.

    The ssh client doesn't display any errors, even in debug mode... right
    after "Delegating credentials", the connection is closed.

    Is this a problem with Kerberos? OpenSSH?

    Does this type of configuration simply not work? Is there a way to make
    it work?

    Any help would really be appreciated, thanks.
    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  2. Re: Wrong principal in request using virt interface

    petesea@bigfoot.com wrote:
    > I'm moving the server to a new cluster of RHE hosts that use virtual
    > interfaces (eg. eth0:1) to allow for failover to a new host while
    > still maintaining the original IP address. On this new system I'm
    > getting the following error when I run sshd in debug (-ddd) mode:
    >
    > Wrong principal in request
    >
    > I have 2 IP addresses and 2 hostnames associated with the 2 interfaces
    > (one of them a virtual interface) on my workstation:
    >
    > interface hostname ip
    > -----------------------------------------
    > eth0 gort.home.org 192.168.0.2
    > eth0:1 cvs.home.org 192.168.0.200


    Can you simply fail-over using the same IP on both interfaces? (I believe there is a bonding module in Linux that can do this.)

    I don't think your setup will work b/c Kerberos relies upon proper DNS records for machines and having the machine change its hostname is bad.

    <
    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  3. Re: Wrong principal in request using virt interface

    On Mon, 29 Jan 2007, Christopher D. Clausen wrote:

    > petesea@bigfoot.com wrote:
    >
    >> I'm moving the server to a new cluster of RHE hosts that use virtual
    >> interfaces (eg. eth0:1) to allow for failover to a new host while still
    >> maintaining the original IP address. On this new system I'm getting
    >> the following error when I run sshd in debug (-ddd) mode:
    >>
    >> Wrong principal in request
    >>
    >> I have 2 IP addresses and 2 hostnames associated with the 2 interfaces
    >> (one of them a virtual interface) on my workstation:
    >>
    >> interface hostname ip
    >> -----------------------------------------
    >> eth0 gort.home.org 192.168.0.2
    >> eth0:1 cvs.home.org 192.168.0.200

    >
    > Can you simply fail-over using the same IP on both interfaces? (I
    > believe there is a bonding module in Linux that can do this.)


    The point of the virt interface is so it can be moved to a different host.
    If the virt interface has the same IP as the real interface, then it
    couldn't be moved to another host. In other words, the "fail-over" is to
    fail over to a completely separate host, not a separate interface on the
    same host.

    > I don't think your setup will work b/c Kerberos relies upon proper DNS
    > records for machines and having the machine change its hostname is bad.


    But the hostname AND IP don't change... not even if the virt interface is
    moved to a new host.

    Or do you mean the hostname the host knows itself as vs the hostname
    returned for a reverse DNS lookup of the IP associated with the virt
    interface?
    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  4. Re: Wrong principal in request using virt interface

    petesea@bigfoot.com wrote:
    > On Mon, 29 Jan 2007, Christopher D. Clausen wrote:
    >> Can you simply fail-over using the same IP on both interfaces? (I
    >> believe there is a bonding module in Linux that can do this.)

    >
    > The point of the virt interface is so it can be moved to a different
    > host. If the virt interface has the same IP as the real interface,
    > then it couldn't be moved to another host. In other words, the
    > "fail-over" is to fail over to a completely separate host, not a
    > separate interface on the same host.


    Uhh, can I ask why you are doing this? Kerberos already has a master/slave architecture. There is no need to "cluster" Kerberos servers in the manner you describe. Just setup multiple slave servers.

    I thought you wanted more reliable KDCs by having redundant network interfaces.

    <

    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  5. Re: Wrong principal in request using virt interface

    petesea@bigfoot.com wrote:
    > On Mon, 29 Jan 2007, Christopher D. Clausen wrote:
    >> petesea@bigfoot.com wrote:
    >>
    >>> I'm moving the server to a new cluster of RHE hosts that use virtual
    >>> interfaces (eg. eth0:1) to allow for failover to a new host while
    >>> still maintaining the original IP address. On this new system I'm
    >>> getting the following error when I run sshd in debug (-ddd) mode:
    >>>
    >>> Wrong principal in request
    >>>
    >>> I have 2 IP addresses and 2 hostnames associated with the 2
    >>> interfaces (one of them a virtual interface) on my workstation:
    >>>
    >>> interface hostname ip
    >>> -----------------------------------------
    >>> eth0 gort.home.org 192.168.0.2
    >>> eth0:1 cvs.home.org 192.168.0.200

    >>
    >> Can you simply fail-over using the same IP on both interfaces? (I
    >> believe there is a bonding module in Linux that can do this.)

    >
    > The point of the virt interface is so it can be moved to a different
    > host. If the virt interface has the same IP as the real interface,
    > then it couldn't be moved to another host. In other words, the
    > "fail-over" is to fail over to a completely separate host, not a
    > separate interface on the same host.


    Sorry, I think I'm missing something... These are NOT Kerberos KDCs are
    they?

    You are trying to have a clustered service that uses Kerberos for SSH?
    And can essentially be treated a multi-homed system?

    Do you have proper A and PTR records for both names? What does your
    /etc/hosts file look like? What does hostname -f return on your system?

    <

    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  6. Re: Wrong principal in request using virt interface

    On Mon, 29 Jan 2007, Christopher D. Clausen wrote:

    > petesea@bigfoot.com wrote:
    >> On Mon, 29 Jan 2007, Christopher D. Clausen wrote:
    >>> Can you simply fail-over using the same IP on both interfaces? (I
    >>> believe there is a bonding module in Linux that can do this.)

    >>
    >> The point of the virt interface is so it can be moved to a different
    >> host. If the virt interface has the same IP as the real interface, then
    >> it couldn't be moved to another host. In other words, the "fail-over"
    >> is to fail over to a completely separate host, not a separate interface
    >> on the same host.

    >
    > Uhh, can I ask why you are doing this? Kerberos already has a
    > master/slave architecture. There is no need to "cluster" Kerberos
    > servers in the manner you describe. Just setup multiple slave servers.
    >
    > I thought you wanted more reliable KDCs by having redundant network
    > interfaces.


    Sorry, I guess I wasn't very clear. The servers aren't KDCs, they are
    CVS/Subversion servers accessed via OpenSSH using GSSAPI Authentication
    and GSSAPI Key Exchange.

    In the very simplest case we would have 2 hosts -- one for CVS and one
    for Subversion. If one of the hosts fails, the service running on that
    host (eg CVS) can be moved to the other host simply by remounted the
    filesystem and moving the virtual interface. From the clients perspective
    all they will (hopefully) notice is a slight delay, after which the same
    data will be available via the same hostname and IP address.

    The reason I originally posted this to the Kerberos list is because I
    assumed it was related to the Kerberos library since that's where the
    error originated.

    But now it appears the solution is upgrading to OpenSSH 4.5p1 along with
    the associated GSSAPI Key Exchange patch. The 4.5p1 GSSKEX patch supports
    a new config option (introduced in 4.4p1) "GSSAPIStrictAcceptorCheck=no"
    which, according to the man page:

    ... If 'no' then the client may authenticate against any service key
    stored in the machine's default store. This facility is provided to
    assist with operation on multi home machines. ...

    After initial testing, it appears this will solve the problem I'm seeing.
    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  7. Re: Wrong principal in request using virt interface

    petesea@bigfoot.com wrote:
    >
    > Sorry, I guess I wasn't very clear. The servers aren't KDCs, they are
    > CVS/Subversion servers accessed via OpenSSH using GSSAPI Authentication
    > and GSSAPI Key Exchange.
    >
    > In the very simplest case we would have 2 hosts -- one for CVS and one
    > for Subversion. If one of the hosts fails, the service running on that
    > host (eg CVS) can be moved to the other host simply by remounted the
    > filesystem and moving the virtual interface. From the clients perspective
    > all they will (hopefully) notice is a slight delay, after which the same
    > data will be available via the same hostname and IP address.

    Wouldn't it be easier to have both on the same host, and then use
    different cnames in the DNS?
    Eg, if the machine is called gort.home.org, then have;

    cvs.home.org -> gort.home.org (CNAME record)
    svn.home.org -> gort.home.org (CNAME record)

    gort.home.org -> 192.186.0.2 (A record)
    192.168.0.2 -> gort.home.org (RNDS PTR record)

    That way you could have all your aliases, and be able to change the machiens easily and not have to deal with multiple IPs.


    ~Edward

    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


+ Reply to Thread