SSH connection using Kerberos

rysic · January 7, 2012, 4:25pm

Hello!

I’m trying to configure SSH connections using Kerberos.
I can see that in SSH server /var/log/messages

an  7 15:26:43 testvis sshd[5065]: Invalid user test from 10.50.10.122
Jan  7 15:27:47 testvis sshd[5069]: pam_krb5[5069]: error resolving user name 'test' to uid/gid pair
Jan  7 15:27:47 testvis sshd[5069]: pam_krb5[5069]: error getting information about 'test'
Jan  7 15:27:47 testvis sshd[5069]: gkr-pam: error looking up user information for: test
Jan  7 15:28:28 testvis sshd[5069]: pam_unix2(sshd:auth): conversation failed
Jan  7 15:28:28 testvis sshd[5069]: error: ssh_msg_send: write

Masz nową pocztę w /var/mail/root

I can kinit test user and klist test user ticket, so there is no connection problem i think.

In SSH server config file (/etc/ssh/sshd_config) I have extra options:


PasswordAuthentication no
KerberosAuthentication yes
KerberosTicketCleanup yes
GSSAPIAuthentication yes
GSSAPICleanCredentials yes
AllowTcpForwarding
UsePAM yes
X11Forwarding yes

/etc/pam.d/common-auth

auth sufficient pam_krb5.so use_first_pass forwardable

/etc/pam.d/common-session

session sufficient pam_krb5.so

I am using OpenSUSE 11.4 and mit Kerberos.

What can be wrong?

Thank you in advance for help!

Mr_Manor · January 8, 2012, 9:59am

I have just started messing with kerberos so I am no expert. But following the documentation, I had no problem with ssh. The fun part started with NFS

questions:

Is the user test
able to login locally on the ssh server?
have you created Service Principals with host names and exported this to the machine.
does dns work both way i.e. is both server and client able to ping using host names.

rysic · January 8, 2012, 5:36pm

I didn’t add local user in SSH server. Is it necessary? There is no like in Active Directory that user is created when he exist in Kerberos?

2 and 3 - yes

Thank you for you reply!

Mr_Manor · January 8, 2012, 9:07pm

An AD is really a Kerberos and a LDAP (and some more) in one package, so if you want to have a central user database for several machines you need to add a LDAP server (or use NIS if security is not an issue). Usernames, and which groups the user belongs to, is then distributed to all ldap clients. I would say that if you dont need NFS4 then you might not need kerberos at all. Username and password can be distributed entirely using LDAP.

But anyway - setting up an LDAP using Yast is not a big deal as Yast can do all the basic work for you.

rysic · January 8, 2012, 10:33pm

LDAP will be next step. Now I try to do Kerberos + SSH working - to check if next steps -> LDAP, NFS, EMAIL are possible.

So… I used command

useradd test

and still cant login via SSH.

That is output from SSH:


# ssh -vvv test@testvis.testit.pl
OpenSSH_5.8p1, OpenSSL 1.0.0c 2 Dec 2010
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to testvis.testit.pl [10.50.10.199] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug3: Incorrect RSA1 identifier
debug3: Could not load "/root/.ssh/id_rsa" as a RSA1 public key
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug3: key_read: missing keytype
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug2: key_type_from_name: unknown key type '-----END'
debug3: key_read: missing keytype
debug1: identity file /root/.ssh/id_rsa type 1
debug1: identity file /root/.ssh/id_rsa-cert type -1
debug1: identity file /root/.ssh/id_dsa type -1
debug1: identity file /root/.ssh/id_dsa-cert type -1
debug1: identity file /root/.ssh/id_ecdsa type -1
debug1: identity file /root/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.8
debug1: match: OpenSSH_5.8 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.8
debug2: fd 3 setting O_NONBLOCK
debug3: load_hostkeys: loading entries for host "testvis.testit.pl" from file "/root/.ssh/known_hosts"
debug3: load_hostkeys: found key type ECDSA in file /root/.ssh/known_hosts:3
debug3: load_hostkeys: loaded 1 keys
debug3: order_hostkeyalgs: prefer hostkeyalgs: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-rsa-cert-v01@openssh.com,ssh-dss-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-dss-cert-v00@openssh.com,ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: first_kex_follows 0 
debug2: kex_parse_kexinit: reserved 0 
debug2: kex_parse_kexinit: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: first_kex_follows 0 
debug2: kex_parse_kexinit: reserved 0 
debug2: mac_setup: found hmac-md5
debug1: kex: server->client aes128-ctr hmac-md5 none
debug2: mac_setup: found hmac-md5
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA 2a:99:6d:a5:4c:d5:56:9c:1c:e3:cd:6b:a7:b5:f1:97
debug3: load_hostkeys: loading entries for host "testvis.testit.pl" from file "/root/.ssh/known_hosts"
debug3: load_hostkeys: found key type ECDSA in file /root/.ssh/known_hosts:3
debug3: load_hostkeys: loaded 1 keys
debug3: load_hostkeys: loading entries for host "10.50.10.199" from file "/root/.ssh/known_hosts"
debug3: load_hostkeys: found key type ECDSA in file /root/.ssh/known_hosts:2
debug3: load_hostkeys: loaded 1 keys
debug1: Host 'testvis.testit.pl' is known and matches the ECDSA host key.
debug1: Found key in /root/.ssh/known_hosts:3
debug1: ssh_ecdsa_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /root/.ssh/id_rsa (0xb780d5c8)
debug2: key: /root/.ssh/id_dsa ((nil))
debug2: key: /root/.ssh/id_ecdsa ((nil))
debug1: Authentications that can continue: publickey,gssapi-with-mic,keyboard-interactive
debug3: start over, passed a different list publickey,gssapi-with-mic,keyboard-interactive
debug3: preferred gssapi-with-mic,publickey,keyboard-interactive
debug3: authmethod_lookup gssapi-with-mic
debug3: remaining preferred: publickey,keyboard-interactive
debug3: authmethod_is_enabled gssapi-with-mic
debug1: Next authentication method: gssapi-with-mic
debug2: we sent a gssapi-with-mic packet, wait for reply
Connection closed by 10.50.10.199

when SSH is connecting, in /var/log/messages


Jan  8 23:33:34 testvis sshd[6420]: Authorized to test, krb5 principal test@TESTIT.PL (krb5_kuserok)

In SSH client I have initiated Kerberos user (and also host appears when try to connect to SSH server):


# klist 
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: test@TESTIT.PL

Valid starting     Expires            Service principal
01/08/12 23:32:08  01/09/12 23:32:07  krbtgt/TESTIT.PL@TESTIT.PL
01/08/12 23:32:54  01/09/12 23:32:07  host/testvis.testit.pl@TESTIT.PL

What else can I check?

rysic · January 9, 2012, 1:33am

Vert, vert, vert strange!!!
I commented in /etc/pam.d/common-session


session    required    pam_krb5.so

and in /etc/pam.d/common-account


account    require    pam_krb5.so    use_first_pass

And it is working! I’m so happy! I’m fighting many days with this!
Thank you for help!

Mr_Manor · January 10, 2012, 9:09pm

Glad you made it.

Just for reference… when I did my Kerberos setup I did not touch any files in /tec/pam. I enabled Kerberos via Yast and I guess it did the necessary modifications to my workstations.