Re: [gt-user] auth problem in gt421

[Basney, Jim]

http://globus.org/toolkit/docs/4.2/4.2.1/security/gsic/admin/#id2533449

On Nov 22, 2011, at 11:44 AM, leo_cu...@lavabit.com wrote:
 I did a myproxy-init in a non-root session, but whit the myproxy service
 running in root session:
 
 --
 www-data@cliente:/tmp$ myproxy-init -C cert.pem -y key.pem -l admin_ca
 --
 
 this was the output:
 
 -
 Your identity: my subjectDN
 
 Creating proxy
  Done
 Proxy Verify OK
 Your proxy is valid until: Fri Nov 25 13:16:35 2011
 Error authenticating: GSS Major Status: Authentication Failed
 GSS Minor Status Error Chain:
 globus_gss_assist: Error during context initialization
 globus_gsi_gssapi: Unable to verify remote side's credentials
 globus_gsi_gssapi: Unable to verify remote side's credentials: Couldn't
 verify the remote certificate
 OpenSSL Error: s3_pkt.c:1102: in library: SSL routines, function
 SSL3_READ_BYTES: sslv3 alert bad certificate SSL alert number 42
 
 
 whit the correspondent /var/log/syslog output:
 
 --
 Nov 18 13:16:33 cliente myproxy-server[3699]: Connection from 127.0.1.1
 Nov 18 13:16:35 cliente myproxy-server[3699]: Error authenticating client:
 GSS Major Status: Authentication Failed GSS Minor Status Error Chain:
 globus_gsi_gssapi: SSLv3 handshake problems OpenSSL Error: s3_srvr.c:2602:
 in library: SSL routines, function SSL3_GET_CLIENT_CERTIFICATE: no
 certificate returned globus_gsi_callback_module: Could not verify
 credential globus_gsi_callback_module: Can't get the local trusted CA
 certificate: Cannot find trusted CA certificate with hash 52edec22 in
 /etc/grid-security/certificates
 Nov 18 13:16:35 cliente myproxy-server[3699]: Exiting: authentication failed
 
 
 why myproxy is creating a hash of the certificate from which I want to
 obtain a proxy certificate, and searching this hash in
 /etc/grid-security/certificates ?!

Re: [gt-user] Old-style proxies support

[Basney, Jim]

I don't think this is an OpenSSL 1.0 problem. I see the same error with a fresh 
GT 5.0.4 install on MacOS 10.6.8 when using a legacy proxy:

$ openssl version
OpenSSL 0.9.8r 8 Feb 2011
$ grid-proxy-init -q
Enter GRID pass phrase:
$ globus-url-copy /tmp/one gsiftp://localhost/tmp/two
$ grid-proxy-init -q -old
Enter GRID pass phrase:
$ globus-url-copy /tmp/one gsiftp://localhost/tmp/two
error: globus_ftp_client: the server responded with an error
530 530-globus_xio: Authentication Error
530-OpenSSL Error: 
/SourceCache/OpenSSL098/OpenSSL098-35.1/src/ssl/s3_srvr.c:2602: in library: SSL 
routines, function SSL3_GET_CLIENT_CERTIFICATE: no certificate returned
530-globus_gsi_callback_module: Could not verify credential
530-globus_gsi_callback_module: Can't get the local trusted CA certificate: 
Cannot find trusted CA certificate with hash 164e606c in 
/etc/grid-security/certificates
530 End.

I get the same error from MyProxy and GSI-OpenSSH when using legacy proxies, so 
it seems to be in the underlying GSI libraries.

On Dec 5, 2011, at 10:46 AM, Joseph Bester wrote:
 Could this be a different OpenSSL version (1.0 vs 0.9.x) requiring a 
 different CA hash? If so, 
 there's a tool in GT5 to work around that.
 
 See http://www.globus.org/toolkit/docs/5.0/5.0.4/security/gsic/pi/#id2578254
 
 Joe
 
 On Dec 5, 2011, at 8:58 AM, Sebastian Czechowski wrote:
 
 Hello,
 
 Does anyone has an answer to this one?
 
 Regards,
 Sebastian
 
  Original Message 
 Subject: [gt-user] Old-style proxies support
 Date:Mon, 14 Nov 2011 10:18:05 +0100
 From:Sebastian Czechowski sebastian.czechow...@gridwisetech.com
 To:  gt-user@lists.globus.org gt-user@lists.globus.org
 
 
 
 Hello all,
 
 Dennis van Dok from IGE Project has sent a the following question:
 
 Will old-style proxies remain supported in current and upcoming Globus
 products? Currently it seems that they aren't (see below).
 
 
 There is a failure in the authentication layer of the client-server
 interaction between a recent version of the globus client tools and a
 recent version of the globus services, when using classic (globus) proxies.
 
 Example: voms classic proxy, globus-url-copy from globus-gass-copy-5.7-1
 on Ubuntu 11.04, with globus-gridftp-server-progs-3.28-3.el5 on CentOS 5.
 
 $ voms-proxy-info -all
 subject   : /O=dutchgrid/O=users/O=nikhef/CN=Dennis van Dok/CN=proxy
 issuer: /O=dutchgrid/O=users/O=nikhef/CN=Dennis van Dok
 identity  : /O=dutchgrid/O=users/O=nikhef/CN=Dennis van Dok
 type  : proxy
 strength  : 1024 bits
 path  : /user/dennisvd/ige-voms-proxy-classic
 timeleft  : 11:47:33
 === VO ige-project.eu extension information ===
 VO: ige-project.eu
 subject   : /O=dutchgrid/O=users/O=nikhef/CN=Dennis van Dok
 issuer:
 /C=DE/O=GermanGrid/OU=TU-Dortmund/CN=host/vomrs01.grid.tu-dortmund.de
 attribute : /ige-project.eu/Role=NULL/Capability=NULL
 timeleft  : 11:47:33
 uri   : vomrs01.grid.tu-dortmund.de:15011
 
 $ globus-url-copy gsiftp://ve.nikhef.nl/etc/grid-security/grid-mapfile
 `pwd`/
 
 error: globus_ftp_client: the server responded with an error
 530 530-globus_xio: Authentication Error
 530-OpenSSL Error: s3_srvr.c:2518: in library: SSL routines, function
 SSL3_GET_CLIENT_CERTIFICATE: no certificate returned
 530-globus_gsi_callback_module: Could not verify credential
 530-globus_gsi_callback_module: Can't get the local trusted CA
 certificate: Cannot find trusted CA certificate with hash 8d759796 in
 /etc/grid-security/certificates
 530 End.
 
 Copying the same proxy file to a machine with a gLite 3.2.8 installation
 (globus-url-copy -version says globus-url-copy: 3.23) and repeating the
 command works.
 
 Initiating the voms proxy to use an RFC style proxy also works:
 
 $ voms-proxy-init --bits 1024 --rfc --voms ige-project.eu
 
 $ voms-proxy-info -all
 subject   : /O=dutchgrid/O=users/O=nikhef/CN=Dennis van Dok/CN=122854297
 issuer: /O=dutchgrid/O=users/O=nikhef/CN=Dennis van Dok
 identity  : /O=dutchgrid/O=users/O=nikhef/CN=Dennis van Dok
 type  : RFC compliant proxy
 strength  : 1024 bits
 path  : /private/home/dennis/src/globustest/ige-voms-proxy-rfc
 timeleft  : 11:43:07
 === VO ige-project.eu extension information ===
 VO: ige-project.eu
 subject   : /O=dutchgrid/O=users/O=nikhef/CN=Dennis van Dok
 issuer:
 /C=DE/O=GermanGrid/OU=TU-Dortmund/CN=host/vomrs01.grid.tu-dortmund.de
 attribute : /ige-project.eu/Role=NULL/Capability=NULL
 timeleft  : 11:43:06
 uri   : vomrs01.grid.tu-dortmund.de:15011
 
 Best regards,
 Sebastian Czechowski, IGE Project
 
 -- 
 Sebastian Czechowski   sebastian.czechow...@gridwisetech.com
 IT Project Coordinator
 GridwiseTechoffice/fax: +48 12 294 71 20
 
 The Scalability Specialist  www.gridwisetech.com
 

Re: [gt-user] sudden client rejection

[Basney, Jim]

Hi Karen,

My only guess is that your oa4mp server is configured to look in a
different store for your clients and clientApprovals than where you wrote
the clientApprovals using oa4mp-approver.jar. What are the contents of the
OA4MP config file pointed to by the oa4mp:server.config.file property and
is that the same config file you're using with oa4mp-approver.jar to
approve the client? Are you using mysql, postgresql, fileStore, or
memoryStore for clients and clientApprovals?

I'm Ccing Jeff Gaynor who may be able to provide additional assistance.

Documentation references:
http://grid.ncsa.illinois.edu/myproxy/oauth/server/configuration/server-con
figuration-file.xhtml
http://grid.ncsa.illinois.edu/myproxy/oauth/server/dtd/server-dtd.xhtml
http://grid.ncsa.illinois.edu/myproxy/oauth/server/dtd/server-dtd-content-t
ags.xhtml
http://grid.ncsa.illinois.edu/myproxy/oauth/server/manuals/manually-approvi
ng-clients.xhtml

-Jim

On 7/18/13 8:12 PM, Karen M. Fernsler kmferns...@lbl.gov wrote:
Hi,

A few weeks ago we approved globusonline as a client for use with our
oauth server.

Up until very recently it was working just fine, but suddenly the server
appears to be 
claiming that the client isn't approved:

Jul 18, 2013 6:04:35 PM edu.uiuc.ncsa.security.core.util.MyLoggingFacade
error
SEVERE: oa4mp(Thu Jul 18 18:04:35 PDT 2013): INTERNAL ERROR: Error: The
client with identifier myproxy:oa4mp,2012:/client/[] has not been
approved. Request rejected. Please contact your administrator.
Jul 18, 2013 6:04:35 PM edu.uiuc.ncsa.security.core.util.MyLoggingFacade
error
SEVERE: oa4mp(Thu Jul 18 18:04:35 PDT 2013):
edu.uiuc.ncsa.security.delegation.server.UnapprovedClientException:
Error: The client with identifier myproxy:oa4mp,2012:/client/[ ... ]
has not been approved. Request rejected. Please contact your administrator


Has anyone run into this before?
Any ideas what to look for?

We have tried re-approving the client to no avail.

thanks,
-k

Re: [gt-user] sudden client rejection

[Basney, Jim]

Karen,

Sorry, I can't explain it. I don't know why oa4mp would log that the
client has not been approved when the corresponding clientApprovals data
file contains entry key=approvedtrue/entry. My only other idea is
to try restarting your oa4mp server, if you haven't tried that already.
Please submit a bug report at https://gateways.atlassian.net/browse/OAUTH
with full details (oa4mp version, config file, log file, clientApprovals
data file).

-Jim

On 7/19/13 2:03 PM, Karen M. Fernsler kmferns...@lbl.gov wrote:
Thanks again Jim, 

Correct me if I'm misunderstanding, but in this case I think we're
looking at the latter possibility (#2) if the client id in the
error message 

  a) matches the client id with (entry key=approvedtrue/entry) in
 the clientApprovals/dataPath file and
  b) also matches the client id in the clients/dataPath file

I have confirmed they all indeed match.

I have opened a ticket with globusonline.

-k

On Fri, Jul 19, 2013 at 05:57:22PM +, Basney, Jim wrote:
 Karen,
 
 I don't know about the Json parse unterminated string message. I
suspect
 that's coming from Globus Online, not oa4mp. Maybe you should submit a
 request at https://support.globusonline.org/ about that.
 
 Since you're using oa4mp's fileStore you can check for the Globus client
 in your fileStore path. In the clientApprovals/dataPath subdirectory you
 should see a file containing the oauth_consumer_key in question (i.e.,
 matching the client identifier from the error message you quoted in your
 original message) along with:
 
 entry key=approvedtrue/entry
 
 You should also see a file containing the same oauth_consumer_key in the
 clients/dataPath subdirectory. They're just XML text files, so you can
 grep/cat them.
 
 It seems to me the only possibilities are either 1) something changed in
 your fileStore path for the Globus client or 2) Globus Online is using a
 different OAuth client identifier than it was before (i.e., different
from
 what you approved). Hopefully matching the client identifier from the
 error message to the oauth_consumer_key in clientApprovals/dataPath will
 diagnose the problem.
 
 -Jim
 
 On 7/19/13 12:40 PM, Karen M. Fernsler kmferns...@lbl.gov wrote:
 Hi Jim,
 
 Thanks for your response.
 
 We're using fileStore.
 
 In web.xml, oa4mp:server.config.file is pointing to the server
 config file that was fed to oa4mp-approver.jar in the attempt
 to re-approve.  This config file only has one config in it
 myconfig.
 
 I was able to set up a test client and approve it with this setup.
 
 The globus client which is now unapproved was approved at one
 point and we were able to use it with the oauth server to do transfers
 with gridftp.
 
 One thing we have noticed -- at the point where globusonline tries to
 redirect the user to the oauth server for authentication we have
 seen a pink error box pop up briefly posting:
 Json parse unterminated string (it's a really brief pop up and it
 doesn't always display the text).
 
 thanks,
 -k
 
 On Fri, Jul 19, 2013 at 01:26:14AM +, Basney, Jim wrote:
  Hi Karen,
  
  My only guess is that your oa4mp server is configured to look in a
  different store for your clients and clientApprovals than where you
 wrote
  the clientApprovals using oa4mp-approver.jar. What are the contents
of
 the
  OA4MP config file pointed to by the oa4mp:server.config.file property
 and
  is that the same config file you're using with oa4mp-approver.jar to
  approve the client? Are you using mysql, postgresql, fileStore, or
  memoryStore for clients and clientApprovals?
  
  I'm Ccing Jeff Gaynor who may be able to provide additional
assistance.
  
  Documentation references:
  
 
http://grid.ncsa.illinois.edu/myproxy/oauth/server/configuration/server
-c
 on
  figuration-file.xhtml
  
http://grid.ncsa.illinois.edu/myproxy/oauth/server/dtd/server-dtd.xhtml
  
 
http://grid.ncsa.illinois.edu/myproxy/oauth/server/dtd/server-dtd-conte
nt
 -t
  ags.xhtml
  
 
http://grid.ncsa.illinois.edu/myproxy/oauth/server/manuals/manually-app
ro
 vi
  ng-clients.xhtml
  
  -Jim
  
  On 7/18/13 8:12 PM, Karen M. Fernsler kmferns...@lbl.gov wrote:
  Hi,
  
  A few weeks ago we approved globusonline as a client for use with
our
  oauth server.
  
  Up until very recently it was working just fine, but suddenly the
 server
  appears to be
  claiming that the client isn't approved:
  
  Jul 18, 2013 6:04:35 PM
 edu.uiuc.ncsa.security.core.util.MyLoggingFacade
  error
  SEVERE: oa4mp(Thu Jul 18 18:04:35 PDT 2013): INTERNAL ERROR: Error:
The
  client with identifier myproxy:oa4mp,2012:/client/[] has not
been
  approved. Request rejected. Please contact your administrator.
  Jul 18, 2013 6:04:35 PM
 edu.uiuc.ncsa.security.core.util.MyLoggingFacade
  error
  SEVERE: oa4mp(Thu Jul 18 18:04:35 PDT 2013):
  edu.uiuc.ncsa.security.delegation.server.UnapprovedClientException:
  Error: The client with identifier myproxy:oa4mp,2012:/client/[ ...
]
  has not been approved. Request rejected. Please contact

Re: [gt-user] MyProxy CA with LDAP

[Basney, Jim]

Hello Fabio,

Please try the following command as root on your MyProxy CA server:

pamtester myproxy fabio authenticate

You may need to first do 'yum install pamtester'.

This will determine if the problem is due to myproxy-server or pam_ldap. If you 
experience slow authentication and timeouts with pamtester, the problem is with 
the pam_ldap configuration or the Active Directory server.

-Jim

On 2/18/14, 6:54 AM, Fabio Moreira 
souza.fab...@gmail.commailto:souza.fab...@gmail.com wrote:
Hi,

I have built a MyPoxy CA v5.9 server with authentication integrated with an 
Active Directory Server through PAM/LDAP to made the authentication of our grid 
environment. Although the certificate is issued, this authentication has been 
very slow with many time out before issuing the certificate. For instance:


Feb 18 09:26:39 globus myproxy-server[18245]: Connection from 10.0.0.1
Feb 18 09:26:39 globus myproxy-server[18245]: Authenticated client anonymous
Feb 18 09:26:42 globus myproxy-server[18245]: Received GET request for username 
fabio
Feb 18 09:27:02 globus myproxy-server[18245]: pam_ldap: ldap_result Timed out
Feb 18 09:27:02 globus myproxy-server[18245]: pam_ldap: ldap_result Timed out
Feb 18 09:27:02 globus myproxy-server[18245]: pam_ldap: ldap_result Timed out
Feb 18 09:27:22 globus myproxy-server[18245]: PAM authentication succeeded for 
fabio
Feb 18 09:27:22 globus myproxy-server[18245]: Got a cert request for user 
fabio, with pubkey hash 0x87696e4, and lifetime 43200
Feb 18 09:27:22 globus myproxy-server[18245]: Issued certificate for user 
fabio, with DN 
/O=Grid/OU=Globus/OU=simpleCA-globus.mydomain.com/OU=local/GN=fabio/CN=FABIOhttp://simpleCA-globus.mydomain.com/OU=local/GN=fabio/CN=FABIO
 MOREIRA DE SOUZA, lifetime 43200, and serial number 0x22
Feb 18 09:27:22 globus myproxy-server[18245]: Client anonymous disconnected


The server is a CentOS 6.5 with PAM configured into the file /etc/pam_ldap.conf 
as following:

host ldapcluster.mydomain.comhttp://ldapcluster.mydomain.com
ldap_version 3
base dc=mydomain,dc=com
binddn CN=admin,OU=service account,OU=IT,DC=mydomain,DC=com
bindpw mypass
pam_filter objectclass=User
pam_login_attribute sAMAccountName
ssl no


and the openldap settings into the file /etc/openldap/ldap.conf:

TLS_REQCERT allow
TLS_CHECKPEER no


The configurations from /etc/myproxy-server.config are:

pam  sufficient
sasl sufficient
certificate_issuer_cert /home/globus/.globus/simpleCA/cacert.pem
certificate_issuer_key /home/globus/.globus/simpleCA/private/cakey.pem
certificate_issuer_key_passphrase mypass
certificate_serialfile /home/globus/.globus/simpleCA/serial
certificate_out_dir /home/globus/.globus/simpleCA/newcerts
certificate_mapfile /etc/grid-security/grid-mapfile
cert_dir /etc/grid-security/certificates
pam_id myproxy
certificate_mapapp /usr/local/sbin/myproxy-mapapp-ldap


and the file /etc/pam.d/myproxy:

auth required pam_ldap.so
account   required pam_ldap.so

I'd like to ask some help because sometimes this delay reaches more than 2 
minutes.

Best Regards,

Fabio Souza

Re: [gt-user] gsissh error

[Basney, Jim]

Steven,

When you installed GT 5.2.5, did you see the following in the output?

-
/var/condor/Globus/globus-5.2.5/sbin/gpt-postinstall
running 
/var/condor/Globus/globus-5.2.5/setup/gsi_openssh_setup/setup-openssh..[
Changing to /var/condor/Globus/globus-5.2.5/setup/gsi_openssh_setup ]
Configuring gsi_openssh

Executing...

Notes:

  o Privilege separation is on.
  o GSI-OpenSSH website is http://grid.ncsa.uiuc.edu/ssh/.

Finished configuring gsi_openssh.
-

The setup-openssh script is what creates the needed
$GLOBUS_LOCATION/etc/ssh directory.

-Jim

On 4/16/14, 2:25 PM, Steven M Clark cla...@purdue.edu wrote:
After doing a basic gt5.2.5 installation from downloaded tarball the
gsissh command fails.

 $ . globus-user-env.sh
 $  which gsissh
   /var/condor/Globus/globus-5.2.5/bin/gsissh
 $ gsissh -help
   /etc/gsissh not found.


---
Steven Clark
Application Engineer for Scientific Computing

Re: [gt-user] gsissh error

[Basney, Jim]

Great! Looks like doing 'export GLOBUS_LOCATION' solved the problem.

-Jim

On 4/16/14, 3:18 PM, Steven M Clark cla...@purdue.edu wrote:
$ echo $GLOBUS_LOCATION
/var/condor/Globus/globus-5.2.5
$ $GLOBUS_LOCATION/setup/gsi_openssh_setup/setup-openssh -verbose
 
Set GLOBUS_LOCATION before running this script

Interesting.

$ export GLOBUS_LOCATION
$ $GLOBUS_LOCATION/setup/gsi_openssh_setup/setup-openssh -verbose
Configuring gsi_openssh

Executing...
Generating ssh host keys...
Linking ssh host keys...
/var/condor/Globus/globus-5.2.5/etc/ssh/ssh_host_rsa_key already
exists... skipping.
/var/condor/Globus/globus-5.2.5/etc/ssh/ssh_host_rsa_key.pub already
exists... skipping.
/var/condor/Globus/globus-5.2.5/etc/ssh/ssh_host_dsa_key already
exists... skipping.
/var/condor/Globus/globus-5.2.5/etc/ssh/ssh_host_dsa_key.pub already
exists... skipping.
Fixing paths in sshd_config...
/var/condor/Globus/globus-5.2.5/etc/ssh/sshd_config already exists...
skipping.
Copying ssh_config and moduli to their proper location...
/var/condor/Globus/globus-5.2.5/etc/ssh/ssh_config already exists...
skipping.
/var/condor/Globus/globus-5.2.5/etc/ssh/moduli already exists... skipping.
/var/condor/Globus/globus-5.2.5/sbin/SXXsshd already exists... skipping.

Notes:

  o Privilege separation is off.
  o GSI-OpenSSH website is http://grid.ncsa.uiuc.edu/ssh/.

Finished configuring gsi_openssh.

$ gsissh  
usage: ssh [-1246AaCfgKkMNnqsTtVvXxYy] [-b bind_address] [-c cipher_spec]
   [-D [bind_address:]port] [-e escape_char] [-F configfile]
   [-I pkcs11] [-i identity_file]
   [-L [bind_address:]port:host:hostport]
   [-l login_name] [-m mac_spec] [-O ctl_cmd] [-o option] [-p
port]
   [-R [bind_address:]port:host:hostport] [-S ctl_path]
   [-W host:port] [-w local_tun[:remote_tun]]
   [user@]hostname [command]


---
Steven Clark
Application Engineer for Scientific Computing

- Original Message -
From: Jim Basney jbas...@illinois.edu
To: Steven M Clark cla...@purdue.edu
Cc: globus toolkit gt-user@lists.globus.org
Sent: Wednesday, April 16, 2014 2:58:24 PM
Subject: Re: [gt-user] gsissh error

What is the output of running the following command?

$GLOBUS_LOCATION/setup/gsi_openssh_setup/setup-openssh -verbose

On 4/16/14, 2:48 PM, Steven M Clark cla...@purdue.edu wrote:
Almost.  I have 

   o Privilege separation is off.

---
Steven Clark
Application Engineer for Scientific Computing

- Original Message -
From: Jim Basney jbas...@illinois.edu
To: Steven M Clark cla...@purdue.edu
Cc: globus toolkit gt-user@lists.globus.org
Sent: Wednesday, April 16, 2014 2:32:29 PM
Subject: Re: [gt-user] gsissh error

Steven,

When you installed GT 5.2.5, did you see the following in the output?

-
/var/condor/Globus/globus-5.2.5/sbin/gpt-postinstall
running 
/var/condor/Globus/globus-5.2.5/setup/gsi_openssh_setup/setup-openssh..[
Changing to /var/condor/Globus/globus-5.2.5/setup/gsi_openssh_setup ]
Configuring gsi_openssh

Executing...

Notes:

  o Privilege separation is on.
  o GSI-OpenSSH website is http://grid.ncsa.uiuc.edu/ssh/.

Finished configuring gsi_openssh.
-

The setup-openssh script is what creates the needed
$GLOBUS_LOCATION/etc/ssh directory.

-Jim

On 4/16/14, 2:25 PM, Steven M Clark cla...@purdue.edu wrote:
After doing a basic gt5.2.5 installation from downloaded tarball the
gsissh command fails.

 $ . globus-user-env.sh
 $  which gsissh
   /var/condor/Globus/globus-5.2.5/bin/gsissh
 $ gsissh -help
   /etc/gsissh not found.


---
Steven Clark
Application Engineer for Scientific Computing

Re: [gt-user] myproxy-logon timed out

[Basney, Jim]

Do you have a myproxy-server running on tirex?

If you run 'telnet tirex 7512' do you see
'Connected to tirex or 'Connection timed out'?

What do the myproxy-server logs contain?

On 7/13/14, 1:57 PM, ti-...@tiscali.it wrote:
Hi,

I've encountered the following error while attempting login:

[quser@tirex ~]$ myproxy-logon -s tirex
Unable to connect to 212.52.82.27:7512
Unable to connect to tirex
Connection timed out

(Globus toolkit 5.2.5 on Fedora 19)

Could someone help me to fix this?

Thanks a lot.

Tiziano Re

Re: [gt-user] Problems with MyProxy and VOMS support

[Basney, Jim]

Hi Matteo,

Sorry for the slow response. Unfortunately I don't have easy access to a
VOMS environment to try to reproduce the problem you've reported.

I think the VOMS AC doesn't verify message is not a symptom of the
problem. I think you should also see that message from your working GT
5.2.4 install. I think that debug message is always printed for proxies
stored in the MyProxy repository when adding VOMS attributes. Reviewing
the code, I'd expect to see some other error thrown by the myproxy-server
if it failed to insert the VOMS attributes.

There was some re-organization of the VOMS code in the MyProxy v6.1.6
release that may have introduced a bug, but that's just an unsubstantiated
suspicion on my part. I assume you're seeing this behavior with
globus_toolkit-6.0.1421093009.tar.gz from
http://toolkit.globus.org/ftppub/gt6/installers/src. It would be helpful
to know if the same problem occurs with the original GT 6.0 tarball
(globus_toolkit-6.0.tar.gz) from September 2014 before the MyProxy v6.1.6
updates.

I opened https://github.com/globus/globus-toolkit/issues/31 to track this
issue.

Regards,
Jim

On 6/19/15, 10:00 AM, Lanati, Matteo wrote:
Hi all,

I compiled MyProxy with VOMS support from the latest source tarball
available, linking it against voms version 2.0.10 and openssl 1.0.1h.
I think the result is fine:
- if I do a $GLOBUS_LOCATION/sbin/myproxy-server -V I see myproxy-server
version MYPROXYv2 (v6.1 Jun 2015 PAM VOMS OCSP)², meaning that VOMS
support is there
- if I look at the executable, I see the dependency from libvomsapi,
libvomsapi.so.1 = /opt/voms/lib/libvomsapi.so.1².
Unfortunately, when I try to retrieve a proxy that I uploaded earlier and
ask MyProxy to sign it for me, it fails. The proxy is issued, but without
the VO signature.
On the client I do

myproxy-logon -m esr

and I see 

Enter MyProxy pass phrase:
failed to run voms-proxy-init: No such file or directory
A credential has been received for user Š

Of course I don¹t have voms-proxy-init on my client, that¹s the whole
point of using MyProxy for this task.

On the server side I see

...
Passphrase matches credentials, and PAM config is sufficient;
authentication succeeds without checking PAM.
  Owner: matteo
  Location: /var/myproxy_test/ ...
  Max. delegation lifetime: 43200 seconds
Sending OK response to client /C=...
retrieving proxy
Stored Credential is Proxy. VOMS AC doesn't verify.
retrieving VOMS User Information.
Retrieve esr VO
Contact to VOMS Server: voms.grid.sara.nl
Delegating credentials for /C=... lifetime=43200
Sending OK response to client /C=...
Client /C=... disconnected

Is the message Stored Credential is Proxy. VOMS AC doesn't verify² the
symptom of a problem?
In the config file I defined

allow_voms_attribute_requests true
voms_userconf /etc/vomses

and it seems that my VO (esr) and the VOMS server have been identified.

The whole setup used to work with GT 5.2.4 (compiled from scratch).
Is there any suggestion?

Best,

Matteo




Matteo Lanati
Distributed Resources Group
Leibniz-Rechenzentrum (LRZ)
Boltzmannstrasse 1
85748  Garching b. München (Germany)
Phone: +49 89 35831 8724

Re: [gt-user] gsisshd and X11 forwarding

[Basney, Jim]

Hi Matteo,

I suggest:

1. Check the server's debug output for any X11-related messages. (See
http://grid.ncsa.illinois.edu/ssh/ts_server.html for instructions.) You
may find an error related to xauth indicating that you need to pass a
./configure --with-xauth option when compiling from source.

2. Do you see the same problem using server binaries from Globus or do you
only see the problem when compiling the server from source?

3. Do you see the same problem using our latest GSI-OpenSSH pre-release
from https://github.com/globus/gsi-openssh/releases? Any help testing our
pre-release is much appreciated.

-Jim

On 1/25/16, 5:53 AM, Lanati, Matteo wrote:
>Hi all,
>
>I¹ve a gsissh server compiled from sources version 6.0.1433516164.
>In the config file of the daemon I set ŒX11Forwarding' to Œyes'.
>However, when I connect from my machine and I try to start a graphical
>application, I get the following error
>
>xterm Xt error: Can't open display:
>xterm:  DISPLAY is not set
>
>If I set the variable, (i.e., connecting via ssh and getting a display),
>things work as expected.
>The daemon is using the correct config file, since in the verbose output
>of the client I see
>
>X11 forwarding request accepted on channel 0
>
>while, if the X11Forwarding option were disabled, I¹d expect the message
>"X11 forwarding request failed on channel 0².
>The behaviour doesn¹t depend on the client platform, I tested it on OSX
>and on Debian (both Globus 6, precompiled from the official repository).
>Are there further suggestions?
>Thanks in advance,
>
>Matteo

[gt-user] GridFTP CEDPS Logging format

[Basney, Jim]

Hi,

I'm looking for a reference on the GridFTP logging format.
http://toolkit.globus.org/toolkit/docs/latest-stable/gridftp/admin/ points
to http://cedps.net/index.php/LoggingBestPractices for "more details on
the CEDPS Logging format" but that site seems to no longer be for the
Center for Enabling Distributed Petascale Science but is now for Computer
Experience and Development of Personal Skills which seems to be mostly
about links to VPN services.

Is there an updated GridFTP CEDPS Logging format reference I can use?

Thanks,
Jim

Re: [gt-user] trust roots in Mac OS

[Basney, Jim]

Does one system have OpenSSL version 1.x and the other have OpenSSL version 
0.x? The hashes are different for the different OpenSSL versions. Some details 
at: http://www.cilogon.org/openssl1

On 1/26/16, 6:21 PM, José Luis Gordillo Ruiz wrote:
Hi,

I’m trying to setup some globus clients on a Mac OS (el capitan).

Initially, I’ve nothing on /etc/grid-security/certificates nor 
.globus/certificates

$ myproxy-get-trustroots -s condor -v
MyProxy v6.1 Jan 2016 PAM OCSP
Attempting to connect to 132.248.83.81:7512
Successfully connected to condor:7512
Expecting non-standard server DN 
"/O=Grid/OU=GlobusTest/OU=simpleCA-condor.super.unam.mx/CN=condor.super.unam.mx"
using trusted certificates directory /Users/jlgr/.globus/certificates
no valid credentials found -- performing anonymous authentication
Error authenticating: GSS Major Status: Authentication Failed
GSS Minor Status Error Chain:
globus_gss_assist: Error during context initialization
OpenSSL Error: 
/BuildRoot/Library/Caches/com.apple.xbs/Sources/OpenSSL098/OpenSSL098-59/src/ssl/s3_clnt.c:998:
 in library: SSL routines, function SSL3_GET_SERVER_CERTIFICATE: certificate 
verify failed
globus_gsi_callback_module: Could not verify credential
globus_gsi_callback_module: Can't get the local trusted CA certificate: 
Untrusted self-signed certificate in chain with hash 63167cb

The CA that signed the myproxy-server's certificate is untrusted.
If you want to trust the CA, re-run with the -b option.
———

so, I know I have to run it con ‘-b’ option. However, my concern is that when I 
run the same command on a Linux box (under the same circumstances, with the 
same user certificate) I got:

$ myproxy-get-trustroots -s condor -v
MyProxy v6.1 Dec 2015 PAM SASL KRB5 LDAP VOMS OCSP
Attempting to connect to 132.248.83.81:7512
Successfully connected to condor:7512
Expecting non-standard server DN 
"/O=Grid/OU=GlobusTest/OU=simpleCA-condor.super.unam.mx/CN=condor.super.unam.mx"
using trusted certificates directory /home/staff/jlgr/.globus/certificates
no valid credentials found -- performing anonymous authentication
Error authenticating: GSS Major Status: Authentication Failed
GSS Minor Status Error Chain:
globus_gss_assist: Error during context initialization
OpenSSL Error: s3_clnt.c:1172: in library: SSL routines, function 
SSL3_GET_SERVER_CERTIFICATE: certificate verify failed
globus_gsi_callback_module: Could not verify credential
globus_gsi_callback_module: Can't get the local trusted CA certificate: 
Untrusted self-signed certificate in chain with hash a6589a6c

The CA that signed the myproxy-server's certificate is untrusted.
If you want to trust the CA, re-run with the -b option.
———

So, you can se that the ‘untrusted self-signed’ certificates have different 
hashes, but the request was made to the same my-proxy server

Why could be that?

My real concern is that I can’t run globus clientes (globus-ftp, globusrun, 
etc) from MacOS but I can from Linux (with same user certificate, same servers, 
etc). I’ve been tracking down differences bt the clients and I found this 
difference in setting trust roots.


saludos,

José Luis Gordillo Ruiz
Coordinación de Supercómputo - DGTIC

Re: [gt-user] trust roots in Mac OS

[Basney, Jim]

OK sorry my guess didn't help. Maybe someone else on the list has another 
idea...

-Jim

On 1/26/16, 6:32 PM, José Luis Gordillo Ruiz wrote:
version 1.x on both of them:

Linux: $ openssl version
OpenSSL 1.0.1e-fips 11 Feb 2013

MacOS: $ openssl version
OpenSSL 1.0.1i 6 Aug 2014


saludos,

José Luis Gordillo Ruiz
Coordinación de Supercómputo - DGTIC


On mar, ene 26, 2016 at 6:28 p.m., Basney, Jim 
<jbas...@illinois.edu<mailto:jbas...@illinois.edu>> wrote:
Does one system have OpenSSL version 1.x and the other have OpenSSL version 
0.x? The hashes are different for the different OpenSSL versions. Some details 
at: 
http://www.cilogon.org/openssl1<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.cilogon.org_openssl1=BQMFaQ=8hUWFZcy2Z-Za5rBPlktOQ=X-ngvEywj1r-yPTxcarA51KnpKNQOkBmvkP2StSnkJY=v0wghE3ea74IhF5BKwwOUAMTpTP41pMTw8r7chc7FWQ=8QYdbx2q3tg36922xVt3NeqYMPPCWgBzX0F9WoXlnXE=>

On 1/26/16, 6:21 PM, José Luis Gordillo Ruiz wrote:
Hi,

I’m trying to setup some globus clients on a Mac OS (el capitan).

Initially, I’ve nothing on /etc/grid-security/certificates nor 
.globus/certificates

$ myproxy-get-trustroots -s condor -v
MyProxy v6.1 Jan 2016 PAM OCSP
Attempting to connect to 132.248.83.81:7512
Successfully connected to condor:7512
Expecting non-standard server DN 
"/O=Grid/OU=GlobusTest/OU=simpleCA-condor.super.unam.mx/CN=condor.super.unam.mx"
using trusted certificates directory /Users/jlgr/.globus/certificates
no valid credentials found -- performing anonymous authentication
Error authenticating: GSS Major Status: Authentication Failed
GSS Minor Status Error Chain:
globus_gss_assist: Error during context initialization
OpenSSL Error: 
/BuildRoot/Library/Caches/com.apple.xbs/Sources/OpenSSL098/OpenSSL098-59/src/ssl/s3_clnt.c:998:
 in library: SSL routines, function SSL3_GET_SERVER_CERTIFICATE: certificate 
verify failed
globus_gsi_callback_module: Could not verify credential
globus_gsi_callback_module: Can't get the local trusted CA certificate: 
Untrusted self-signed certificate in chain with hash 63167cb

The CA that signed the myproxy-server's certificate is untrusted.
If you want to trust the CA, re-run with the -b option.
———

so, I know I have to run it con ‘-b’ option. However, my concern is that when I 
run the same command on a Linux box (under the same circumstances, with the 
same user certificate) I got:

$ myproxy-get-trustroots -s condor -v
MyProxy v6.1 Dec 2015 PAM SASL KRB5 LDAP VOMS OCSP
Attempting to connect to 132.248.83.81:7512
Successfully connected to condor:7512
Expecting non-standard server DN 
"/O=Grid/OU=GlobusTest/OU=simpleCA-condor.super.unam.mx/CN=condor.super.unam.mx"
using trusted certificates directory /home/staff/jlgr/.globus/certificates
no valid credentials found -- performing anonymous authentication
Error authenticating: GSS Major Status: Authentication Failed
GSS Minor Status Error Chain:
globus_gss_assist: Error during context initialization
OpenSSL Error: s3_clnt.c:1172: in library: SSL routines, function 
SSL3_GET_SERVER_CERTIFICATE: certificate verify failed
globus_gsi_callback_module: Could not verify credential
globus_gsi_callback_module: Can't get the local trusted CA certificate: 
Untrusted self-signed certificate in chain with hash a6589a6c

The CA that signed the myproxy-server's certificate is untrusted.
If you want to trust the CA, re-run with the -b option.
———

So, you can se that the ‘untrusted self-signed’ certificates have different 
hashes, but the request was made to the same my-proxy server

Why could be that?

My real concern is that I can’t run globus clientes (globus-ftp, globusrun, 
etc) from MacOS but I can from Linux (with same user certificate, same servers, 
etc). I’ve been tracking down differences bt the clients and I found this 
difference in setting trust roots.


saludos,

José Luis Gordillo Ruiz
Coordinación de Supercómputo - DGTIC

Re: [gt-user] Globus ³strict mode² coming March 2016 - Action Required

[Basney, Jim]

Hi,

Did this change happen as planned? Is the transition going OK for everyone?

In my role as CA operator, I know we've been issuing a lot of host certs
with multiple subjectAltNames in preparation for this transition, so
hopefully everyone has the certs they need.

-Jim

On 2/4/16, 5:21 PM, Stuart Martin wrote:
>Hi All,
>
>Here is a reminder about this deadline and upcoming change.
>
>Admins should check their host certificates and update them if necessary.
> Replace any incompatible certificates by Mar 1, 2016.
>
>To allow a bit of a buffer between the service-side certificate update
>deadline and clients beginning to use strict mode, updates will be made
>to the Globus Toolkit to default the client-side algorithm to strict mode
>on Tuesday, April 5, 2016.
>
>- The Globus Team
>
>> On Dec 1, 2015, at 2:50 PM, Stuart Martin  wrote:
>> 
>> Dear All,
>> 
>> Globus is planning to change the default client-side algorithm for
>>checking the server¹s identity used by GridFTP, MyProxy, GSI-OpenSSH,
>>and GRAM.  The new algorithm performs identity matching as described in
>>section 3.1 of RFC 2818
>>(https://tools.ietf.org/html/rfc2818#section-3.1), the standard
>>describing TLS use with HTTP.   This involves a change in the
>>globus-gssapi-gsi library, and will apply to any application that uses
>>the updated library.
>> 
>> The new ³strict mode² algorithm will be more strict in its enforcement,
>>checking that the server¹s certificate identity matches the hostname
>>that the client uses to contact the service.  Once clients are
>>configured for strict mode, client authentication (of any Globus
>>service) would fail if the service is using a certificate that does not
>>match the hostname that the client used to contact the service.
>> 
>> This change will bring our identity checking algorithm in line with RFC
>>2818, and will also close the door to reverse DNS lookup related attack
>>vectors. As an example of why relying on reverse DNS for making security
>>related decisions is not recommended, see this link:
>>https://cwe.mitre.org/data/definitions/350.html.
>> 
>> The Globus team has checked the host certificates used for a number of
>>GridFTP endpoints and found that many are _not_ RFC 2818 compatible.
>>These incompatible certificates will need to be replaced prior to
>>clients defaulting to the new strict mode algorithm.
>> 
>> We are reaching out to request that Globus service admins check their
>>host certificates and update them if necessary.  We are asking admins to
>>replace any incompatible certificates by Mar 1, 2016.  After March 1, we
>>will release updated Globus Toolkit components that will change the
>>default client authorization algorithm to strict mode.  At that time,
>>the Globus.org transfer service will also update its identity checking
>>algorithm.  This should ensure no service disruptions for the Globus
>>community.
>> 
>> Note: Globus Connect Server installations that use the Globus provided
>>certificate are not affected and do not have to make any changes to
>>their Globus Connect Server endpoint(s).
>> 
>> We have created a page where additional details about this change will
>>be communicated:
>>  https://docs.globus.org/security-bulletins/2015-12-strict-mode/
>> The above page includes common reasons for incompatibilities and how to
>>check for compatibility.
>> 
>> If you have any questions or concerns regarding this planned change,
>>please contact us at supp...@globus.org.
>> 
>> - The Globus team