Enabling authentication for incoming TCP/IP connections

You can set up an authenticated communication by using a private and public keypair when you use the TCPIP option from the TEST runtime options.

Note: The steps related to generating the certificate and uploading to the host are the same as in Enabling secure communication between z/OS Debugger and the remote debugger for incoming debug sessions.

Preform the following steps:

Add a client certificate by exporting a copy of the client certificate from the keystore that the remote debugger uses.
This client certificate is used by z/OS Debugger TCP/IP server (remote debugger) during Debug Daemon authentication. If the remote debugger has a secure connection setup, this certificate can be reused for authentication. Otherwise, you can use the Java™ runtime utility to create a keystore, certificate, and export a client certificate.
- Create a keystore and a certificate by using the following command:
```
keytool -genkey
```
- Export a client certificate by using the following command:
```
keytool -export
```
Note: Refer to the appropriate Java documentation for the full set of parameters required for the keytool command.

Each Eclipse IDE user must configure the debug daemon to start a port with the location and password of the keystore created previously. To configure the debug daemon, go to Run/Debug > Debug Daemon preference page. For more information, see the Debug Daemon preferences section in Setting debug preferences.
Upload the certificate to z/OS in binary mode and store it as a z/OS Unix file or a sequential dataset with HLQ as your username. For example, IBMUSER.DEBUG.CERT.
Pass the certificate location as a parameter to your debug session by providing a EQACERT DD pointing to the certificate location.
For example:
```
//EQACERT DD *
IBMUSER.DEBUG.CERT
```

To debug z/OS Unix programs, you can substitute EQACERT DD with an environment variable.

export EQACERT=/u/ibmuser/debug.cert

z/OS debugger v 17.0.0 defines a new TEST suboption TCPAUTH&ip_address%port similar to TCPIP& suboption. However, it requires a remote connection to be authenticated.

After the authentication is successful, the HLQ of the certificate dataset or the owner of the certificate Unix file is considered to be the debug user, and the username is verified for access to debugging load modules during the debugger authorization checks. To force authentication on all TCP connections, even when using TCPIP suboptions, a SAF/RACF profile EQAAUTH.TCP must be defined with access NONE in the FACILITY class. If the profile is undefined or defined with READ or above access, the TCPIP option does not require authentication.

Note: Certain security products may return access NONE for undefined profiles thus forcing authenticated TCPIP. If you want to continue using TCPIP without authentication define EQAAUTH.TCP with access READ or above.

Note: TCP/IP authentication is not supported for CICS and IMS debugging.