Conexiones SSH en z/OS

Escrito por Javier

En esta ocasión vamos a realizar la configuración del servidor/cliente SSH (Secure SHell) que tiene z/OS para poder conectarnos desde otras máquinas a Mainframe y viceversa. El objetivo de esto es poder iniciar scripts en otras máquinas (Linux, Windows, etc.) usando un JCL o poder lanzar un JCL mediante la ejecución de un script en otro servidor.

El servicio SSH (OpenSSH) se ejecuta en la parte Unix que tiene z/OS y es una de las herramientas que se incluyen en “IBM Ported Tools for z/OS”. Además, después de configurar este servicio, también podremos usar el servicio SFTP para transmitir ficheros de una forma más segura que con el FTP normal.

Yo voy a realizar la configuración más sencilla posible, pero aquí dejo un enlace a la guía completa de IBM sobre OpenSSH para los que quieran profundizar más en el tema.

Versión 1.2: http://www-03.ibm.com/systems/resources/fot4os02.pdf

Versión 1.3: http://www-03.ibm.com/systems/resources/fot4os03.pdf

 

NOTA: Tenemos que tener configurado el TCPIP en z/OS para que funcione.

 

Primero vamos a ver dónde se encuentran los ficheros de configuración de OpenSSH dentro de la parte Unix de z/OS, para ello vamos a buscar la tarea “SSHD”, que es el servidor SSH, en la librería de procedimientos, en mi caso, ADCD.Z113.PROCLIB.

 

Vemos  que ejecuta el script “sshd.sh” que se encuentra en la ruta /etc/ssh.

 

Vamos a ver que contiene el directorio /etc/ssh, para ello escribimos el comando “TSO ISHELL” para entrar en el panel ISPF de la parte Unix.

 

Vemos el listado de archivos que sale, ponemos una “V” en el fichero “sshd.sh” para ver qué hace el script.

 

Dejamos vacío el campo “Record length”.

 

Vemos que ejecuta el programa que se encuentra en “/usr/sbin/sshd” y usa el fichero de configuración /etc/ssh/sshd_config. Ese es el fichero de configuración que debemos editar.

 

Salimos con F3 y ponemos una “E” para editar el fichero sshd_config.

 

Dejamos los campos en blanco.

 

Vemos que el archivo contiene lo siguiente. Las Ñ al principio de la línea significa que esa línea es un comentario. En esta ocasión vamos a hacer la validación de la conexión mediante clave RSA en vez de usuario y contraseña.

 

Las opciones que vamos a usar son las siguientes:

Port 22

Protocol 2

PermitRootLogin yes (importante poner “yes” si vamos a usar el usuario IBMUSER u otro que pertenezca a GID=0 - grupo de usuarios root)

StrictModes no

RSAAuthentication yes                 

PubkeyAuthentication yes              

AuthorizedKeysFile .ssh/authorized_keys

IgnoreUserKnownHosts no

PasswordAuthentication no  (vamos a hacer el acceso mediante clave RSA)

 

El resto de opciones pueden seguir como se encuentra por defecto.

 

Una vez editados todos los parámetros indicados, guardamos y salimos.

Podemos comprobar a que grupo de usuarios pertenece el usuario que vamos a usar desde el panel principal de “ISHELL”, en el menú Setup, opción 2 (User list).

 

Vemos que pertenece al grupo 0 – SYS1.

 

También podemos ver una lista de los grupos en el panel Setup, opción 8 (Group list).

 

Ahora vamos a generar una clave RSA para el usuario al que vamos a querer conectarnos desde otras máquinas. Para hacerlo, salimos del “ISHELL” y entramos a OMVS.

 

Como estamos usando el usuario IBMUSER, nos deja por defecto en esa ruta.

 

Desde esa ruta, escribimos el comando “ssh-keygen -t rsa”.

 

Esperamos a que ponga “INPUT” abajo a la derecha y pulsamos “intro”.

 

Durante el proceso pedirá una “passphrase” que dejaremos en blanco y seguiremos pulsando intro.

 

Ahora vamos a hacer un “scan” para comprobar si nos responde con la clave que acabamos de crear. Usaremos el comando “ssh-keyscan –t rsa host >> /etc/ssh/ssh_known_hosts”. El “-t rsa” es para forzar el protocolo 2 y el host es la IP del destino, en este caso, la IP que tengamos puesta en Mainframe. Hacemos que nos deje la salida de ese comando en el fichero “/etc/ssh/ssh_known_host” por si más adelante queremos hacer una prueba para conectarnos.

En mi caso el comando queda así:

“ssh-keyscan –t rsa 192.168.1.110 >> /etc/ssh/ssh_known_hosts”

 

NOTA: si el comando no funciona, posiblemente tengamos que reiniciar el servicio SSHD para que coja los cambios que hemos hecho al principio. Más adelante se explica cómo hacerlo.

 

El comando tarda un poquito en responder, cuando veamos que pone “INPUT” abajo a la derecha, pulsamos intro. Nos aparecerá lo siguiente.

 

Ahora vamos a repetir el comando pero con otra máquina a la que queremos acceder. En mi caso se trata de una máquina Windows a la que he instalado el programa OpenSSH.

Escribimos el mismo comando cambiando la IP de destino, en mi caso, queda de la siguiente forma:

ssh-keyscan –t rsa 192.168.1.10 >> /etc/ssh/ssh_known_hosts

 

Salimos de OMVS escribiendo “exit” (importante que sea en minúsculas). Entramos de nuevo en ISHELL y buscamos el fichero “/etc/ssh/ssh_known_hosts” para comprobar los datos que hemos introducido.

 

Vemos que están los dos host.

 

Ahora vamos a ver los ficheros con la clave RSA que generamos anteriormente. Entramos en la ruta “/u/ibmuser”.

 

Entramos dentro de la carpeta “.ssh”.

 

Vemos que existen los ficheros id_rsa, id_rsa.pub y prng_seed. Para poder conectarnos en otros servidores, sólo tendríamos que mandar la clave del “id_rsa.pub” al servidor remoto (por FTP, SCP, copiar/pegar) y ponerla en el fichero “authorized_keys” dentro de la carpeta “.ssh” del usuario con el que queramos acceder.

NOTA: el servidor remoto también debe tener configurado el servidor SSH (SSHD) de forma que puedas logarte con clave RSA. Con tener la misma configuración que hemos hecho aquí del fichero “/etc/ssh/sshd_config” valdría.

Yo voy a hacer una copia del fichero id_rsa.pub para crear el fichero authorized_keys. Los motivos por los que hago esto son:

  • Nos aseguramos que tenemos el fichero authorized_keys con el formato y permisos correctos.
  • Podemos acceder al servidor SSH usando el propio cliente SSH de Mainframe, esto sirve para probar si el servicio funciona correctamente, por ejemplo, si un equipo remoto no puede acceder, pero desde el propio cliente de Mainframe si, pues posiblemente haya un problema de comunicaciones, firewall, etc.

Para hacerlo, ponemos una “C” delante de “id_rsa.pub”.

 

Marcamos la opción 1.

 

Ponemos el nombre del fichero y dejamos los permisos por defecto (644).

 

Ya hemos creado el fichero “authorized_keys”. Ahora vamos a aprovechar para editarlo y añadir la clave “id_rsa.pub” del servidor remoto que accederá al servidor de Mainframe.

Yo, para no complicar demasiado el tutorial, voy a hacer copia/pega.

NOTA: En el servidor remoto, también tendremos que tener instalado OpenSSH y haber generado una clave RSA tal y como hemos hecho en Mainframe.

 

Una vez hayamos pegado la clave pública del servidor remoto en Mainframe, vamos a aprovechar para poner la clave pública, que hemos generado para el usuario IBMUSER, en el fichero known_hosts del servidor remoto dentro de la carpeta “.shh” del usuario que vayamos a usar para acceder. Para hacerlo, entramos en el fichero “/u/ibmuser/.ssh/ id_rsa.pub”.

 

Y copiamos la clave y la pegamos en el fichero mencionado anteriormente.

Pegamos la clave, que debe estar en una línea solo y guardamos.

 

Ahora vamos a reiniciar el servidor SSHD de Mainframe para que coja los cambios en la configuración que hicimos al principio del tutorial.

Para reiniciarlo entramos de nuevo a OMVS.

NOTA: cuando se añaden o se cambian claves RSA no es necesario reiniciar el servidor.

 

Antes de parar el servidor, podemos comprobar, en la Consola, que está activo. Usaremos el comando “d a,ssh*”.

 

Para parar el servidor, escribimos el comando en OMVS:

kill $(cat /var/run/sshd.pid)

 

Comprobamos en la Consola que está parado.

 

Lo arrancamos desde la Consola con el comando “S SSHD”.

 

Aunque ponga “SSHD ENDED”, el servicio está arrancado, porque, como se ejecuta en la parte UNIX, son las tareas “BPXAS” las que lo mantienen activo.

 

Confirmamos que está arrancado con "d a,ssh*".

 

NOTA: Con el comando “kill -s HUP $(cat /var/run/sshd.pid)” se puede reiniciar el servicio SSHD, pero podría ocurrir que no arrancase con los permisos correctos por el usuario. Si lo arrancamos desde Consola, no deberíamos tener ese problema.

 

Ahora vamos a probar el acceso SSH desde el servidor remoto (Windows) a host. Abrimos un CMD y ponemos el comando “ssh Esta dirección de correo electrónico está siendo protegida contra los robots de spam. Necesita tener JavaScript habilitado para poder verlo.”. Si queremos que nos muestre un debug de la conexión podemos poner “ssh –vvv Esta dirección de correo electrónico está siendo protegida contra los robots de spam. Necesita tener JavaScript habilitado para poder verlo.”.

 

Tras unos segundos, vemos que accedemos. Ponemos el comando “ls -l” para ver los archivos que tiene el directorio donde nos encontramos.

Una vez hemos accedido al host, podemos hacer lo que se nos ocurra, por ejemplo, dar un comando, lanzar un script que tengamos, un rexx, un JCL, etc.

 

Cerramos la conexión con el comando “exit”.

 

Por último vamos a ejecutar un JCL que se conecte por SSH al servidor remoto (Windows) y ejecute algún comando. El JCL es el siguiente:

 

//SCRIPTWN JOB (9999),'SCRIPT WINDOWS',CLASS=A,MSGCLASS=Q,      

// MSGLEVEL=(1,1),REGION=0M,NOTIFY=&SYSUID                      

//SHELLCMD EXEC PGM=BPXBATCH                                    

//STEPLIB DD DSN=CEE.SCEERUN,DISP=SHR                            

//STDIN DD PATH='/u/ibmuser/exec/scriptwin.in',PATHOPTS=(ORDONLY)

//STDOUT DD PATH='/u/ibmuser/exec/scriptwin.out',                

// PATHOPTS=(OWRONLY,OCREAT,OTRUNC),PATHMODE=SIRWXU             

//STDERR DD PATH='/u/ibmuser/exec/scriptwin.err',                 

// PATHOPTS=(OWRONLY,OCREAT,OTRUNC),PATHMODE=SIRWXU             

 

El fichero “/u/ibmuser/exec/scriptwin.in” contiene los comandos que vamos a ejecutar, en este caso, ssh.

El fichero “/u/ibmuser/exec/scriptwin.out” contiene las salidas que produzcan esos comandos.

El fichero “/u/ibmuser/exec/scriptwin.err” contiene los errores que se puedan producir.

Antes de ejecutar el JCL, tenemos que crear la carpeta “exec” dentro del usuario “ibmuser” y tenemos que crear el fichero “scriptwin.in” con los comandos que vamos a ejecutar. Los otros dos ficheros se crean automáticamente cuando se ejecute el JCL. 

Entramos en ISHELL y creamos la carpeta /u/ibmuser/exec.

 

Nos saldrá un panel para que indiquemos lo que queremos crear. Ponemos File Type 1 (Directory) y permisos 755.

 

Ahora creamos el fichero “scriptwin.in”.

 

Ponemos File Type 2 (Regular file) y permisos 755.

 

Entramos en el directorio /u/ibmuser/exec/ y editamos el fichero scriptwin.in.

 

Ponemos el siguiente código :

/bin/ssh -T usuario@host "comando1; comando2; comando3" 

En mi caso:

/bin/ssh -T Esta dirección de correo electrónico está siendo protegida contra los robots de spam. Necesita tener JavaScript habilitado para poder verlo. "hostname; pwd; cd ..; pwd; ls ."    

De esta forma nos conectamos al servidor 192.168.1.10 con el usuario “javiero” y ejecutamos varios comandos, separados por punto y coma “;”. Podemos ejecutar los comandos que queramos siempre que estén dentro de las comillas.

 

Ahora volvemos al JCL y lo ejecutamos. El job tarda un poco en ejecutarse. Como hemos puesto “notify”, sabremos cuando podemos ver los ficheros de salida para ver el resultado. Si termina con RC=255 es que no ha sido posible conectarse.

 

En mi caso, ha terminado con RC=0. Vamos a ver los archivos de salida que se encuentran en /u/ibmuser/exec. Entramos en el fichero “scriptwin.err”.

 

En este fichero, como no se ha producido ningún error, solo tenemos el banner que lanza el servidor cuando nos conectamos.

 

Por último vemos el fichero “scriptwin.out” con la salida de los comandos que hemos ejecutado.

 

Ya hemos configurado la conexión SSH, en futuras entradas, posiblemente utilicemos este tipo de conexión para ejecutar cosas en distintas máquinas.

 

 

 

Visto: 5027

Comentarios  

+1 #1 Tamie 19-04-2018 01:07
Thanks fοr finally talking about >Conexiones SSH еn z/OЅ
Citar
-1 #2 karthick 23-04-2018 21:09
Im getting below error when i trying ssh-keygen -t rsa ; no clue why its coming i'm using 1.10 adcd on hercules .

FOTS1824 PRNG seed extraction failed
FOTS1945 ssh-rand-helper child produced insufficient data

please guide me.
Citar

Escribir un comentario


Código de seguridad
Refescar