Your best friend for file transfer.

4.0.2: kerberos stopped connecting under Mac OS X (2 posts)
- Started 21 years ago by irwin
- Latest reply 21 years ago from Jim Matthews
-
irwin Member
-
Jim Matthews Administrator
What a great bug report! Thanks for all the information.
There was a change between Fetch 4.0.1 and 4.0.2 in the way it requests Kerberos tickets. Fetch makes a connection to the server, then asks the Domain Name System to turn that address into a hostname, and then asks the GSS/Kerberos software for a ticket for that hostname. The change was in the call used to turn the address into a hostname. It looks like, in your case, the new call is not working -- it is returning an empty string. That's why Fetch is asking for a ticket for "ftp@" -- it should be something like "ftp@xxx.princeton.edu".
Is it possible that the address you are connecting to is not associated with a name in the domain name system? Could you email me the server's hostname (send it to support@fetchsoftworks.com)?
Thanks,
Jim Matthews
Fetch Softworks
- Page 1
Topic closed
This topic has been closed.
When I upgraded from 4.0.1 to 4.0.2, I found that connecting using GSS stopped working (to a Kerberos version 5 server) in the Mac OS X environment.
Steps to reproduce:
1. Obtain a Kerberos ticket from Kerberos v5 server, using the
MIT Kerberos for Mac OX X, version 4.0 client.
2. Launch Fetch 4.0.2.
3. In the "New Connection" dialog, I've entered the fully-qualified canonical hostname, and a userid.
Security is GSS, encrypt session is enabled. After I hit "OK" in the New Connection dialog, instead of
getting a successful connection, an alert appears, saying "GSSAPI error: An invalid name was supplied
Hostname cannot be canonicalized (OK)"
If I quit Fetch 4.0.2 and repeat the test using Fetch 4.0.1 on the same computer
(no change to Fetch preferences, using the same shortcut, etc), it works fine.
Platform:
Mac OS X 10.1.4
No personal firewall or NAT installed.
ftp server is a Solaris 8 system running from MIT Kerberos 5 version 1.2.4.
No firewall, NAT or proxy sever between the ftp client and server.
Fetch relevent Preferences
Security:
do not warn before sending password insecurely
do warn before sending cleartext password to secure server
do not check protoection level on incoming data
do not make Kerberos v5 tickets forwardable
do send dummy password to Kerberos servers
do specify GSS channel bindings (only present in 4.0.2) (changing to do not makes no difference)
Here are copies of transcripts from 4.0.1 followed by 4.0.2.
(I've xxx'd out some identifying info.)
Fetch 4.0.1 works:
System Version = 0x1014
Connecting to xxxxx.princeton.edu port 21 (5/10/02 3:32:04 PM)
220 xxxxx.Princeton.EDU FTP server (Version 5.60) ready.
ADAT
503 Must identify AUTH type before ADAT
AUTH GSSAPI
334 Using authentication type GSSAPI; ADAT must follow
ADAT
235 ADAT=xxxxxxxxxxxxxx....
USER xxxxxxx
232 GSSAPI user xxxxxx@PRINCETON.EDU is authorized as xxxxxx
PBSZ 131072
200 PBSZ=131072
PROT P
200 Data channel protection level set to private.
PWD
257 "/home/xxxxxx" is current directory.
SYST
215 UNIX Type: L8
PWD
257 "/home/xxxxx" is current directory.
MACB ENABLE
500 'MACB ENABLE': command not understood.
CWD tmp
250 CWD command successful.
PWD
257 "/home/xxxx/tmp" is current directory.
Kerberos
Fetch 4.0.2 fails:
Fetch 4.0.2 System 0x1014 Serial xxxxxx
Connecting to xxxxxx.princeton.edu port 21 (5/10/02 3:36:18 PM)
220 xxxxxx.Princeton.EDU FTP server (Version 5.60) ready.
ADAT
503 Must identify AUTH type before ADAT
AUTH GSSAPI
334 Using authentication type GSSAPI; ADAT must follow
gss_send_tok_buff = ftp@
gss_send_tok_buff = host@
Connecting to xxxxxx.princeton.edu port 21 (5/10/02 3:36:29 PM)
220 xxxxxx.Princeton.EDU FTP server (Version 5.60) ready.
ADAT
503 Must identify AUTH type before ADAT
AUTH GSSAPI
334 Using authentication type GSSAPI; ADAT must follow
gss_send_tok_buff = ftp@
gss_send_tok_buff = host@
Posted 21 years ago #