Help: noaddresses help
Jeet Joshi
I am new to kerberos. I have two small networks connected.
I want kerberized SSH can be used from any network.
noaddressless = true; #in lib-defaults krb5.conf.
Do I have to configure more settings for using tickets in other network?
My KDC and SSH daemon are in single network.
I am searching for complete guide for kerberos NAT use.
Does someone have any link?
Thank you for help in advance.
-Jeet
Jeet Joshi
Jeet Joshi
Sorry for the repetition.
I can ssh from the same network with GSSAPI. But I am not able to login from
other network without root password.
Here are some details--
on server side-->
[root@vmainkdc ~]# /usr/local/sbin/sshd -d
debug1: sshd version OpenSSH_4.7p1
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: rexec_argv[0]='/usr/local/sbin/sshd'
debug1: rexec_argv[1]='-d'
debug1: Bind to port 22 on ::.
Server listening on :: port 22.
debug1: Bind to port 22 on 0.0.0.0.
Bind to port 22 on 0.0.0.0 failed: Address already in use.
debug1: Server will not fork when running in debugging mode.
debug1: rexec start in 4 out 4 newsock 4 pipe -1 sock 7
debug1: inetd sockets after dupping: 3, 3
Connection from 192.168.20.1 port 49818
debug1: Client protocol version 2.0; client software version OpenSSH_4.7
debug1: match: OpenSSH_4.7 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.7
debug1: permanently_set_uid: 74/74
debug1: list_hostkey_types: ssh-rsa,ssh-dss
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 root service ssh-connection method none
debug1: attempt 0 failures 0
Failed none for root from 192.168.20.1 port 49818 ssh2
debug1: userauth-request for user root service ssh-connection method
gssapi-with-mic
debug1: attempt 1 failures 1
Postponed gssapi-with-mic for root from 192.168.20.1 port 49818 ssh2
debug1: Unspecified GSS failure. Minor code may provide more information
Wrong principal in request
debug1: Got no client credentials
debug1: userauth-request for user root service ssh-connection method
gssapi-with-mic
debug1: attempt 2 failures 2
debug1: userauth-request for user root service ssh-connection method
gssapi-with-mic
debug1: attempt 3 failures 2
debug1: userauth-request for user root service ssh-connection method
keyboard-interactive
debug1: attempt 4 failures 2
debug1: keyboard-interactive devs
debug1: auth2_challenge: user=root devs=
debug1: kbdint_alloc: devices ''
debug1: userauth-request for user root service ssh-connection method
password
debug1: attempt 5 failures 3
Accepted password for root from 192.168.20.1 port 49818 ssh2
debug1: monitor_child_preauth: root has been authenticated by privileged
process
debug1: Entering interactive session for SSH2.
debug1: server_init_dispatch_20
debug1: server_input_channel_open: ctype session rchan 0 win 1048576 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 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/3
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: Setting controlling tty using TIOCSCTTY.
debug1: Received SIGCHLD.
debug1: session_by_pid: pid 4249
debug1: session_exit_message: session 0 channel 0 pid 4249
debug1: session_exit_message: release channel 0
debug1: session_pty_cleanup: session 0 release /dev/pts/3
debug1: session_by_channel: session 0 channel 0
debug1: session_close_by_channel: channel 0 child 0
debug1: session_close: session 0 pid 0
debug1: channel 0: free: server-session, nchannels 1
Connection closed by 192.168.20.1
debug1: do_cleanup
Closing connection to 192.168.20.1
[root@vmainkdc ~]#
On my gateway PC, 2 IP addresses are 192.168.20.1 and 192.168.0.4
My ssh client is on 192.168.0.14 and ssh server and kdc is on 192.168.20.20
krb5.conf on server file is
[libdefaults]
default_realm = EXAMPLE.COM
dns_lookup_realm = false
dns_lookup_kdc = false
noaddresses = true
forwardable = true
proxiable = true
[realms]
EXAMPLE.COM = {
kdc = 192.168.20.20:88
admin_server = 192.168.20.20:749
default_domain=example.com
}
[domain_realm]
.example.com = EXAMPLE.COM
[logging]
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log
default = FILE:/var/log/krb5lib.log
kinit from 192.168.0.14 is giving me ticket with
addresses = [none]
when "I do klist -a -n".
What is meaning of "Wrong principal in request"?
I am using same principal by which I am able to login from 192.168.20.1
Please Help me if any other setting is required?
Thanks
Jeet
Ken Raeburn
> What is meaning of "Wrong principal in request"?
> I am using same principal by which I am able to login from
> 192.168.20.1
> Please Help me if any other setting is required?
If you run "klist" after a successful ssh from the same network, and
the unsuccessful attempt from the other network, preferably after
getting new tickets in both cases, you do get the same service
principal listed? (Is the machine on the same network the same
machine as the ssh server?)
"Wrong principal in request" generally means there was a specific
server principal name that the server was expecting, and a different
one was used by the client for some reason. Sometimes that can be
caused by different names for the same host or address (e.g., /etc/
hosts on different machines lists different "primary" names for the
address and/or different sets of addresses).
You asked about NAT in your earlier message. Are you using NAT
between the networks this case, or was that a separate issue?
--
Ken Raeburn, Senior Programmer
MIT Kerberos Consortium
Jeet Joshi
Thanks for the reply.
Here are some details:
> If you run "klist" after a successful ssh from the same network, and
> the unsuccessful attempt from the other network, preferably after
> getting new tickets in both cases, you do get the same service
> principal listed? (Is the machine on the same network the same
> machine as the ssh server?)
Ok, here can be the problem, I am not getting any service ticket on the
other network ssh client. klist gives just krbtgt/EXAMPLE.COM ticket. But in
the same network (on the gateway) I am getting host/sshd.example.com ticket
for the ssh and so I can log in without any password.
( I can get access from same network , for this checking I am
performing ssh from the gateway PC.)
> "Wrong principal in request" generally means there was a specific
> server principal name that the server was expecting, and a different
> one was used by the client for some reason. Sometimes that can be
> caused by different names for the same host or address (e.g., /etc/
> hosts on different machines lists different "primary" names for the
> address and/or different sets of addresses).
My /etc/host contains are same on all the three PCs I am using.
Can there be any problem as I am storing other networks private IP address
in /etc/hosts ?
> You asked about NAT in your earlier message. Are you using NAT
> between the networks this case, or was that a separate issue?
Yes, I am using SNAT on the gateway.
Let me explain the setup that I have
I am currently testing on 3 PC's.
My outer Network is 192.168.0.0/24 and inner network is 192.168.20.0/24
Gateway PC has IP addresses 192.168.0.4 and 192.168.20.1 respectively.
Now my all port 88 and port 22 traffic is forwarded to address
192.168.20.20on respective port. My SSH and KDC are running on the
same PC inside the
network.
At client I am using
ssh 192.168.0.4
It is asking me password for ro...@192.168.0.4
When I enter password of inner m/c then access is granted to me for inner PC
not the gateway which I was looking for without password.
So kindly awaiting for reply.
Thanks
Jeet
jeetj...@gmail.com
I am still searching for any solution on the situation
described.
Hoping for any help.
Thank you
Jeet
Jeet Joshi
I am desperately needing help on problem I am facing for
internetwork kerberos communication. Please find previous posts at
Please, help needed as soon as possible. I have to complete it by deadline
which is this Sunday.
Thanks
Jeet
jo...@destar.net
> Jeet
Hello Jeet,
I think you need to look at cross realm authentication if you have two
separate networks. Also, you have to 'kinit' before you can login
without a password and DO NOT allow root to ssh to a box. If you allow
root to ssh and someone gets the password, with kerberos they will
have the keys to the kingdom.
Hope that helps,
Jon
Edgecombe, Jason
cross-realm authentication is the answer.
In the addressless case, your KDC must be seen from inside and outside
the NAT. I think in this case, the kdc must be dual-home on both
networks.
Put the following in the krb5.conf file in all client machines and put
the noaddresses line in the kdc config as well.
[libdefaults]
forwardable = true
noaddresses = true
In your case, all machine that people will ssh to from the gateway must
have host principals installed correctly to enable single sign-on.
If you pursue the cross-realm route, noaddresses may or may not be
necessary, but host principals are still necessary in addition to the
host principals.
Jason
Jason Edgecombe
Solaris & Linux Administrator
Mosaic Computing Group, College of Engineering
UNC-Charlotte
Phone: (704) 687-3514
Hello Everyone,
Hoping for any help.
Thank you
Jeet
________________________________________________
Kerberos mailing list Kerb...@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos