Kerberized ssh only works on KDC - Kerberos

This is a discussion on Kerberized ssh only works on KDC - Kerberos ; I have set up MIT-kerberos on an old Sun Ultra10 I had lying around, and I am attempting to get a sort of single sign-on working. I got kerberized ssh logins working on the KDC itself, i.e. I run kinit, ...

+ Reply to Thread
Results 1 to 6 of 6

Thread: Kerberized ssh only works on KDC

  1. Kerberized ssh only works on KDC

    I have set up MIT-kerberos on an old Sun Ultra10 I had lying around, and I
    am attempting to get a sort of single sign-on working.



    I got kerberized ssh logins working on the KDC itself, i.e. I run kinit,
    ssh to the KDC and it works fine, here is what the KDC says when I
    connect:

    --KDC SSHD--
    ultra10# sshd -dDp2222
    debug1: sshd version OpenSSH_3.8.1p1 Debian-krb5 3.8.1p1-10
    debug1: read PEM private key done: type RSA
    debug1: private host key: #0 type 1 RSA
    debug1: read PEM private key done: type DSA
    debug1: private host key: #1 type 2 DSA
    debug1: Bind to port 2222 on ::.
    Server listening on :: port 2222.
    debug1: Bind to port 2222 on 0.0.0.0.
    debug1: Server will not fork when running in debugging mode.
    Connection from ::ffff:192.168.183.2 port 42351
    debug1: Client protocol version 2.0; client software version OpenSSH_4.3
    debug1: match: OpenSSH_4.3 pat OpenSSH*
    debug1: Enabling compatibility mode for protocol 2.0
    debug1: Local version string SSH-2.0-OpenSSH_3.8.1p1 Debian-krb5 3.8.1p1-10
    debug1: list_hostkey_types: ssh-rsa,ssh-dss
    debug1: GSSAPI mechanism Kerberos (gss-group1-sha1-toWM5Slw5Ew8Mqkay+al2g==) supported
    debug1: GSSAPI mechanism Kerberos (gss-group1-sha1-Se3H81ismmOC3OE+FwYCiQ==) supported
    debug1: SSH2_MSG_KEXINIT sent
    debug1: SSH2_MSG_KEXINIT received
    debug1: kex: client->server aes128-cbc hmac-md5 none
    debug1: kex: server->client aes128-cbc hmac-md5 none
    debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received
    debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent
    debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT
    debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent
    debug1: SSH2_MSG_NEWKEYS sent
    debug1: expecting SSH2_MSG_NEWKEYS
    debug1: SSH2_MSG_NEWKEYS received
    debug1: KEX done
    debug1: userauth-request for user andy service ssh-connection method none
    debug1: attempt 0 failures 0
    debug1: PAM: initializing for "andy"
    debug1: PAM: setting PAM_RHOST to "bloo.eeble.net"
    debug1: PAM: setting PAM_TTY to "ssh"
    Failed none for andy from ::ffff:192.168.183.2 port 42351 ssh2
    debug1: userauth-request for user andy service ssh-connection method gssapi-with-mic
    debug1: attempt 1 failures 1
    Postponed gssapi-with-mic for andy from ::ffff:192.168.183.2 port 42351 ssh2
    debug1: Got no client credentials
    Authorized to andy, krb5 principal andy@EEBLE.NET (krb5_kuserok)
    Accepted gssapi-with-mic for andy from ::ffff:192.168.183.2 port 42351 ssh2
    debug1: Entering interactive session for SSH2.
    debug1: server_init_dispatch_20
    debug1: server_input_channel_open: ctype session rchan 0 win 65536 max 16384
    debug1: input_session_request
    debug1: channel 0: new [server-session]
    debug1: session_new: init
    debug1: session_new: session 0
    debug1: session_open: channel 0
    debug1: session_open: session 0: link with channel 0
    debug1: server_input_channel_open: confirm session
    debug1: server_input_channel_req: channel 0 request x11-req reply 0
    debug1: session_by_channel: session 0 channel 0
    debug1: session_input_channel_req: session 0 req x11-req
    debug1: X11 forwarding disabled in server configuration file.
    debug1: server_input_channel_req: channel 0 request pty-req reply 0
    debug1: session_by_channel: session 0 channel 0
    debug1: session_input_channel_req: session 0 req pty-req
    debug1: Allocating pty.
    debug1: session_pty_req: session 0 alloc /dev/pts/1
    debug1: server_input_channel_req: channel 0 request shell reply 0
    debug1: session_by_channel: session 0 channel 0
    debug1: session_input_channel_req: session 0 req shell
    debug1: temporarily_use_uid: 1000/1000 (e=0/0)
    debug1: No credentials stored
    debug1: restore_uid: 0/0
    debug1: PAM: setting PAM_TTY to "/dev/pts/1"
    debug1: PAM: establishing credentials
    debug1: Setting controlling tty using TIOCSCTTY.


    what I notice especially are these lines:
    debug1: GSSAPI mechanism Kerberos (gss-group1-sha1-toWM5Slw5Ew8Mqkay+al2g==) supported
    debug1: GSSAPI mechanism Kerberos (gss-group1-sha1-Se3H81ismmOC3OE+FwYCiQ==) supported

    so, that works fine, but when I go to connect to other machines on the
    network, that are NOT KDCs, (but can use kinit just fine), I get the
    following log from sshd:

    --nonKDC sshd--
    noodles:~# sshd -dD -p2222
    debug1: sshd version OpenSSH_3.8.1p1 Debian-krb5 3.8.1p1-10
    debug1: read PEM private key done: type RSA
    debug1: private host key: #0 type 1 RSA
    debug1: read PEM private key done: type DSA
    debug1: private host key: #1 type 2 DSA
    debug1: Bind to port 2222 on 0.0.0.0.
    Server listening on 0.0.0.0 port 2222.
    socket: Address family not supported by protocol
    debug1: Server will not fork when running in debugging mode.
    Connection from 192.168.183.2 port 35952
    debug1: Client protocol version 2.0; client software version OpenSSH_4.3
    debug1: match: OpenSSH_4.3 pat OpenSSH*
    debug1: Enabling compatibility mode for protocol 2.0
    debug1: Local version string SSH-2.0-OpenSSH_3.8.1p1 Debian-krb5 3.8.1p1-10
    debug1: list_hostkey_types: ssh-rsa,ssh-dss
    debug1: Miscellaneous failure
    No such file or directory

    debug1: no credentials for GSSAPI mechanism Kerberos
    debug1: Miscellaneous failure
    No such file or directory

    debug1: no credentials for GSSAPI mechanism Kerberos
    debug1: SSH2_MSG_KEXINIT sent
    debug1: SSH2_MSG_KEXINIT received
    debug1: kex: client->server aes128-cbc hmac-md5 none
    debug1: kex: server->client aes128-cbc hmac-md5 none
    debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received
    debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent
    debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT
    debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent
    debug1: SSH2_MSG_NEWKEYS sent
    debug1: expecting SSH2_MSG_NEWKEYS
    debug1: SSH2_MSG_NEWKEYS received
    debug1: KEX done
    debug1: userauth-request for user andy service ssh-connection method none
    debug1: attempt 0 failures 0
    debug1: PAM: initializing for "andy"
    debug1: PAM: setting PAM_RHOST to "bloo.eeble.net"
    debug1: PAM: setting PAM_TTY to "ssh"
    Failed none for andy from 192.168.183.2 port 35952 ssh2
    debug1: userauth-request for user andy service ssh-connection method gssapi-with-mic
    debug1: attempt 1 failures 1
    debug1: Miscellaneous failure
    No such file or directory

    Failed gssapi-with-mic for andy from 192.168.183.2 port 35952 ssh2
    debug1: userauth-request for user andy service ssh-connection method gssapi-with-mic
    debug1: attempt 2 failures 1
    Failed gssapi-with-mic for andy from 192.168.183.2 port 35952 ssh2
    debug1: userauth-request for user andy service ssh-connection method publickey
    debug1: attempt 3 failures 1
    debug1: test whether pkalg/pkblob are acceptable
    debug1: temporarily_use_uid: 1000/1000 (e=0/0)
    debug1: trying public key file /home/andy/.ssh/authorized_keys
    debug1: matching key found: file /home/andy/.ssh/authorized_keys, line 1
    Found matching DSA key: e5:30:ac:82:e3:3e:56:aa:0a:5f:63:0e:66:9c:ae:59
    debug1: restore_uid: 0/0
    Postponed publickey for andy from 192.168.183.2 port 35952 ssh2


    the lines I'm seeing here that concern me are:
    debug1: Miscellaneous failure
    No such file or directory

    debug1: no credentials for GSSAPI mechanism Kerberos
    debug1: Miscellaneous failure
    No such file or directory

    debug1: no credentials for GSSAPI mechanism Kerberos

    I have searched many places for information on why this is occuring but
    with no success.

    (All systems are running debian sarge stable/testing) Any help is greatly
    appreciated!
    --Andrew

  2. Re: Kerberized ssh only works on KDC

    Andrew Bovill writes:

    > when I go to connect to other machines on the network, that are NOT
    > KDCs, (but can use kinit just fine), I get the following log from sshd:


    > --nonKDC sshd--
    > noodles:~# sshd -dD -p2222
    > debug1: sshd version OpenSSH_3.8.1p1 Debian-krb5 3.8.1p1-10
    > debug1: read PEM private key done: type RSA
    > debug1: private host key: #0 type 1 RSA
    > debug1: read PEM private key done: type DSA
    > debug1: private host key: #1 type 2 DSA
    > debug1: Bind to port 2222 on 0.0.0.0.
    > Server listening on 0.0.0.0 port 2222.
    > socket: Address family not supported by protocol
    > debug1: Server will not fork when running in debugging mode.
    > Connection from 192.168.183.2 port 35952
    > debug1: Client protocol version 2.0; client software version OpenSSH_4.3
    > debug1: match: OpenSSH_4.3 pat OpenSSH*
    > debug1: Enabling compatibility mode for protocol 2.0
    > debug1: Local version string SSH-2.0-OpenSSH_3.8.1p1 Debian-krb5 3.8.1p1-10
    > debug1: list_hostkey_types: ssh-rsa,ssh-dss
    > debug1: Miscellaneous failure
    > No such file or directory


    > debug1: no credentials for GSSAPI mechanism Kerberos
    > debug1: Miscellaneous failure
    > No such file or directory


    > debug1: no credentials for GSSAPI mechanism Kerberos


    Do those other systems have a keytab in /etc/krb5.keytab?

    --
    Russ Allbery (rra@stanford.edu)

  3. Re: Kerberized ssh only works on KDC

    On Sat, 04 Nov 2006 12:04:13 -0800, Russ Allbery wrote:

    > Andrew Bovill writes:
    >
    >> when I go to connect to other machines on the network, that are NOT
    >> KDCs, (but can use kinit just fine), I get the following log from sshd:

    >
    >> --nonKDC sshd--
    >> noodles:~# sshd -dD -p2222
    >> debug1: sshd version OpenSSH_3.8.1p1 Debian-krb5 3.8.1p1-10
    >> debug1: read PEM private key done: type RSA
    >> debug1: private host key: #0 type 1 RSA
    >> debug1: read PEM private key done: type DSA
    >> debug1: private host key: #1 type 2 DSA
    >> debug1: Bind to port 2222 on 0.0.0.0.
    >> Server listening on 0.0.0.0 port 2222.
    >> socket: Address family not supported by protocol
    >> debug1: Server will not fork when running in debugging mode.
    >> Connection from 192.168.183.2 port 35952
    >> debug1: Client protocol version 2.0; client software version OpenSSH_4.3
    >> debug1: match: OpenSSH_4.3 pat OpenSSH*
    >> debug1: Enabling compatibility mode for protocol 2.0
    >> debug1: Local version string SSH-2.0-OpenSSH_3.8.1p1 Debian-krb5 3.8.1p1-10
    >> debug1: list_hostkey_types: ssh-rsa,ssh-dss
    >> debug1: Miscellaneous failure
    >> No such file or directory

    >
    >> debug1: no credentials for GSSAPI mechanism Kerberos
    >> debug1: Miscellaneous failure
    >> No such file or directory

    >
    >> debug1: no credentials for GSSAPI mechanism Kerberos

    >
    > Do those other systems have a keytab in /etc/krb5.keytab?


    Not that I know of... how would I go about doing that?


  4. Re: Kerberized ssh only works on KDC

    On Sat, 04 Nov 2006 12:04:13 -0800, Russ Allbery wrote:

    > Andrew Bovill writes:
    >
    >> when I go to connect to other machines on the network, that are NOT
    >> KDCs, (but can use kinit just fine), I get the following log from sshd:

    >
    >> --nonKDC sshd--
    >> noodles:~# sshd -dD -p2222
    >> debug1: sshd version OpenSSH_3.8.1p1 Debian-krb5 3.8.1p1-10
    >> debug1: read PEM private key done: type RSA
    >> debug1: private host key: #0 type 1 RSA
    >> debug1: read PEM private key done: type DSA
    >> debug1: private host key: #1 type 2 DSA
    >> debug1: Bind to port 2222 on 0.0.0.0.
    >> Server listening on 0.0.0.0 port 2222.
    >> socket: Address family not supported by protocol
    >> debug1: Server will not fork when running in debugging mode.
    >> Connection from 192.168.183.2 port 35952
    >> debug1: Client protocol version 2.0; client software version OpenSSH_4.3
    >> debug1: match: OpenSSH_4.3 pat OpenSSH*
    >> debug1: Enabling compatibility mode for protocol 2.0
    >> debug1: Local version string SSH-2.0-OpenSSH_3.8.1p1 Debian-krb5 3.8.1p1-10
    >> debug1: list_hostkey_types: ssh-rsa,ssh-dss
    >> debug1: Miscellaneous failure
    >> No such file or directory

    >
    >> debug1: no credentials for GSSAPI mechanism Kerberos
    >> debug1: Miscellaneous failure
    >> No such file or directory

    >
    >> debug1: no credentials for GSSAPI mechanism Kerberos

    >
    > Do those other systems have a keytab in /etc/krb5.keytab?


    Thanks! With your suggestion I was able to modify my search on google, found exactly what I needed!
    It works perfectly now. I really appreciate it


  5. Re: Kerberized ssh only works on KDC

    On Sat, 04 Nov 2006 21:00:35 +0000, Andrew Bovill wrote:

    >> Do those other systems have a keytab in /etc/krb5.keytab?

    >
    > Thanks! With your suggestion I was able to modify
    > my search on google, found exactly what I needed!
    > It works perfectly now. I really appreciate it


    Just a quick question though. for the keytab on the
    KDC, do I have to add all the host principals to it?
    or just the host principal for the KDC?


  6. Re: Kerberized ssh only works on KDC

    Andrew Bovill writes:
    > On Sat, 04 Nov 2006 21:00:35 +0000, Andrew Bovill wrote:


    >>> Do those other systems have a keytab in /etc/krb5.keytab?

    >>
    >> Thanks! With your suggestion I was able to modify
    >> my search on google, found exactly what I needed!
    >> It works perfectly now. I really appreciate it


    > Just a quick question though. for the keytab on the
    > KDC, do I have to add all the host principals to it?
    > or just the host principal for the KDC?


    Only the host principal for the KDC. A system's keytab should contain
    only its own keys; this is true of every system that uses a keytab,
    including the KDC. Logging into the KDC shouldn't be any different than
    logging into any other host.

    --
    Russ Allbery (rra@stanford.edu)

+ Reply to Thread