I just tested this properly with a 1.3.4 implementation I built for someone else
recently; I was incorrect. The only time that the KDC is not queried is if you
do not have tickets to begin with. If you have valid realm tickets but try to
log in with something like "ssh -l fakename valid.host.com",
On Sep 21, 2004, at 17:29, rachel elizabeth dillon wrote:
1. Are you trying to ssh as a user that exists on the other machine?
If the user does not exist in the other machine's /etc/passwd, then
I don't believe the KDC will ever be queried.
That sounds like an undesirable leak of information from t
I am not entirely sure what your situation or problem is, but here
are some things you might try:
1. Are you trying to ssh as a user that exists on the other machine?
If the user does not exist in the other machine's /etc/passwd, then
I don't believe the KDC will ever be queried.
2. ssh -v -v -v
If you are going to use a different realm you need to also use a
different admin principal.
Kerberos mailing list [EMAIL PROTECTED]
https://mailman.mit.edu/mailman/listinfo/kerberos
--On Montag, 20. September 2004 11:14 -0700 Tyson Oswald
<[EMAIL PROTECTED]> wrote:
Norbert Klasen <[EMAIL PROTECTED]> wrote:
--On Freitag, 17. September 2004 10:26 -0700 Tyson Oswald
wrote:
I have successult gotten SEAM -> AD to work on our Solaris 8 machines,
and am now trying to get it to wo
Do a "ssh -v hostname 2> ssh-log" and send that along so we can see the
errors. The "2> ssh-log" part will re-direct standard error to a file
called ssh-log.
You should double check that each machine has the correct keytab.
"k5srvutil list" will show the tickets on the local machine's keytab
On Tue, 2004-09-21 at 17:09 +, Ken Hornstein wrote:
> >3. From an strace, I've managed to find out that the Kerberos library
> >opens the replay cache, reads it, and then tries to open a file with the
> >empty string as file name (which explains the ENOENT). It then closes
> >the replay cache.
Hi people,
> I dont understand your answer
Sorry.. i will try to explain better...
> Le mardi 21 Septembre 2004 01:31, Ghe Rivero a écrit :
>> El lun, 20-09-2004 a las 15:27 -0500, Luis Daniel Lucio Quiroz escribió:
>> > do you have your host/fqdn.server2 realm done? or your
>> > ssh/fqdn.se
Tom Yu wrote:
>>"schommer" == Derrick Schommer <[EMAIL PROTECTED]> writes:
>
>
> schommer> Its only 28 blocks, but if I repeat the authentication over
> schommer> and over it grows quickly. It seems that when I get a
> schommer> forwarded tgt (krb5_fwd_tgt() ) and call krb5_rd_cred() it
> sc
And how about this one, I think this is one of the last issues I've got
lined up:
==20711== 28 bytes in 1 blocks are definitely lost in loss record 8 of 10
==20711==at 0x1B902A90: malloc (vg_replace_malloc.c:131)
==20711==by 0x13CA8F: krb5_copy_principal (in /usr/lib/libkrb5.so.3.2)
==207
Is there anyone on this list using the Authen::Krb5::Admin Perl
extension?
It works for me when I don't use Authen::Krb5::Admin::Config to try
and set which realm to go against and the defaults from /etc/krb5.conf
are used.
I need to write a web based utility that will perform operations
against
>3. From an strace, I've managed to find out that the Kerberos library
>opens the replay cache, reads it, and then tries to open a file with the
>empty string as file name (which explains the ENOENT). It then closes
>the replay cache.
>
>I've linked against the MIT Krb5 libraries, version 1.2.7.
>
Thanks to Microsoft we have an answer to this question.
Apparently, Windows does not use UTF-8 for the DES string to key
operations. UTF-8 is only used for RC4-HMAC.
In the DES string to key operations, the current locally defined
OEM Code Page is used.
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSe
Folk,
I am pretty sure I already know the answer to this, but wanted to verify
it "for certain". I know that last failed attempt and last successful
attempt are not usable if you have slave kerberos servers. Is that also
true of failed password attempts? (I think yes, it is) In an ideal
wor
14 matches
Mail list logo
