We are in the process of converting all FTP mainframe jobs to SFTP. I used the ssh-keygen -f id_dsa_userid command to create the key pairs. Sent the public key to client to be copied into their authorized_keys file. When job is executed, I get the following error.

EZYXW11E XtlibError: invalidDisplay xtInitialize XtToolkitError
Can't open display: MVSDMC1
FOTS1370 Host key verification failed.
lost connection.

Client is using CrushFTP software which I know nothing about. What are we missing?

  • If you're the one providing the service, why is your client copying your public key to their authorized_keys file, not vice versa? It appears that the server is not listed in the known_hosts file. Additionally, the error looks a bit like they're trying to start an X window session. – Patrick R. Apr 4 '18 at 15:46
  • XtToolkit is a library for the X Server (graphical display), which should have nothing to do with SFTP. On the other hand, ssh can forward X connections. Guess: Something is setup wrongly wrt. to X forwarding, and tries to establish it, at least on one end. BTW, you can enable verbose debug messages on normal sftp/ssh clients/servers (e.g. -v for the standard ssh, sftp). – dirkt Apr 4 '18 at 17:19
  • Don't know if this is the issue, but I've seen SSH fail if server and client time is not in sync -- 15 min. max difference, I believe. community.centrify.com/t5/Centrify-Express/… – DrMoishe Pippik Apr 4 '18 at 18:25

The problem at its root is in ssh and the key setup. The X Windows Xauth problem is a Red Herring. After found some additional research I found a thread that appears to match your problem. The thread in question is for a product from Dovetail technologies but manifest the same problem in ssh key exchanges.

EZYXW11E XtlibError: invalidDisplay xtInitialize XtToolkitError Can't open display:
FOTS1346 Permission denied, please try again.
EZYXW11E XtlibError: invalidDisplay xtInitialize XtToolkitError Can't open display: Connection closed by UNKNOWN
FOTS2707 zsshSmfWritePipe: write(): EDC5113I Bad file descriptor. (errno2=0x05710034).

If the key is in place, the likely issue is incorrect permissions on the .ssh directory and files on the target system. The following commands in the home directory of the sftp user will correct the permissions:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

The permissions on my USS system look like this:

IBMUSER> ls -la
drwx------   2 IBMUSER  OMVS        8192 May 11 09:15 .ssh

IBMUSER> ls -la .ssh
-rw-------   1 IBMUSER  OMVS         399 May 11 09:15 authorized_keys

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.