RE: Re[2]: [CORREO BASURA] Re: [CORREO BASURA] Re: REGLA FIREWALL PARA RUNRMTCMD

Thu, 27 Oct 2022 05:21:38 -0700 

Hola 

Lo adjunto

Saludos

Carlos

 

 

De: Forum.help400 <[email protected]> En nombre de
Andoni
Enviado el: miércoles, 26 de octubre de 2022 14:55
Para: forum.help400 <[email protected]>
Asunto: Re[2]: [CORREO BASURA] Re: [CORREO BASURA] Re: REGLA FIREWALL PARA
RUNRMTCMD

 

Buenas tardes, sigues teniendo este documento a mano para enviarmelo? 

 

Gracias

 

 

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Fri, 11 Feb 2022 09:08:20 +0100

"CARLOS SANTIAGO" <[email protected]
<mailto:[email protected]> > escribió:

 

Perfecto Javier

Me harías un gran favor

Saludos y muchas gracias

Carlos

De: Forum.help400 <[email protected]
<mailto:[email protected]> > En nombre de datil400
Enviado el: viernes, 11 de febrero de 2022 8:51
Para: forum.help400 <[email protected]
<mailto:[email protected]> >
Asunto: [CORREO BASURA] Re: [CORREO BASURA] Re: REGLA FIREWALL PARA
RUNRMTCMD

Actualmente estoy probando la opción SSH. Ha sido todo muy entretenido todo
el proceso y me parece una alternativa viable. De hecho, herramientas como
VS Code for IBM i utilizan este método para comunicar Windows con IBM i.

Como tengo muy mala memoria, he pensado escribir un pequeño documento con
todos los pasos y pruebas. No sé cuando lo tendré. Si estás interesado y
escribo algo entendible puedo pasarte las notas.

Javier 

El vie, 11 feb 2022 a las 8:28, CARLOS SANTIAGO
(<[email protected] <mailto:[email protected]> >)
escribió:

Sí Javier. La opción          STRPCCMD queda descartada por el tema que
comentas del interactivo

saludos

De: Forum.help400 <[email protected]
<mailto:[email protected]> > En nombre de datil400
Enviado el: viernes, 11 de febrero de 2022 8:27
Para: forum.help400 <[email protected]
<mailto:[email protected]> >
Asunto: [CORREO BASURA] Re: REGLA FIREWALL PARA RUNRMTCMD

Hola Carlos,

Yo estoy explorando la opción de SSH y STRPCCMD como sustitutos de
RUNRMTCMD. Esto último lo utilizo a menudo, pero solo funciona en trabajos
interactivos.

En el enlace que te ha pasado Alex se comentan ambas opciones.

Javier

El vie., 11 feb. 2022 8:07, CARLOS SANTIAGO <[email protected]
<mailto:[email protected]> > escribió:

Gracias Alex

Voy a ver como cambiar el RUNRMTCMD…

Alguna idea al respecto?

Saludos 

Carlos

De: Forum.help400 <[email protected]
<mailto:[email protected]> > En nombre de Alex
Martínez
Enviado el: viernes, 11 de febrero de 2022 7:59
Para: forum.help400 <[email protected]
<mailto:[email protected]> >
Asunto: [CORREO BASURA] Re: REGLA FIREWALL PARA RUNRMTCMD

Hola

Entiendo que tienes instalado IBM Client Access, también sin soporte en
windows 10 y el daemon CWBRXD arrancado 

El puerto que utilizar es el 512 pero es inseguro, las contraseñas se
transmiten sin cifrar e IBM ya no da soporte..

https://www.ibm.com/support/pages/runrmtcmd-no-longer-works

El jue, 10 feb 2022 a las 17:38, carlos (<[email protected]
<mailto:[email protected]> >) escribió:

Buenas tardes

Alguien me puede indicar como definir la regla del firewall en un pc Windows
10 para que desde el iseries me permita ejecutar un mandato en ese pc?

He creado una regla permitiendo la ip del iseries pero no me funciona.

Gracias y saludos

Carlos

____________________________________________________
Únete a Recursos AS400, nuestra Comunidad ( http://bit.ly/db68dd )
Forum.Help400 © Publicaciones Help400, S.L.

____________________________________________________
Únete a Recursos AS400, nuestra Comunidad ( http://bit.ly/db68dd )
Forum.Help400 © Publicaciones Help400, S.L.

____________________________________________________
Únete a Recursos AS400, nuestra Comunidad ( http://bit.ly/db68dd )
Forum.Help400 © Publicaciones Help400, S.L.

 

 

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Title: Ejecución de comandos remotos en Windows desde el IBM i con SSH

Ejecución de comandos remotos en Windows desde el IBM i con SSH

Portada

En abril de 2019 IBM dejó de dar soporte al producto IBM i Access for Windows 7.1 (5770-XE1) que fue reemplazado por IBM i Access Client Solutions (5733-XJ1) [1]. Aunque IBM i Access for Windows se distribuyó en las versiones 7.1, 7.2 y 7.3, dejó de ser compatible con las versiones posteriores a Windows 8.1 y Windows Server 2012 R2.

Una de las características que le faltan a ACS es el servicio de mandato remoto necesario para ejecutar RUNRMTCMD desde el IBM i. Este mandato permitía la ejecución de comandos en un equipo Windows, pero padecía de algunos problemas, el más importante era que la contraseña del usuario de Windows no se cifraba en las comunicaciones y eso es un riesgo para la seguridad que habría que evitar.

Este documento describe una alternativa al mandato RUNRMTCMD utilizando OpenSSH tanto en el IBM i como en Windows.

Tanto Windows Server 2019 como Windows 10 (a partir de la compilación 1809) incluyen la característica OpenSSH en sus distribuciones. OpenSSH [2] es la versión de código abierto de las herramientas Secure Shell (SSH) utilizadas desde hace mucho tiempo por los administradores de Linux y de otros sistemas no Windows para la gestión multiplataforma de sistemas remotos.

SSH se basa en una arquitectura cliente-servidor donde el sistema en el que trabaja el usuario es el cliente y el sistema remoto que se gestiona es el servidor. OpenSSH incluye una serie de componentes y herramientas diseñadas para proporcionar un enfoque seguro y sencillo para la administración de sistemas remotos, incluyendo:

  • sshd.exe, que es el componente del servidor SSH que debe ejecutarse en el sistema que se gestiona de forma remota
  • ssh.exe, que es el componente del cliente SSH que se ejecuta en el sistema local del usuario
  • ssh-keygen.exe genera, gestiona y convierte las claves de autenticación para SSH
  • ssh-agent.exe almacena las claves privadas utilizadas para la autenticación de clave pública
  • ssh-add.exe añade claves privadas a la lista permitida por el servidor
  • ssh-keyscan.exe ayuda a recopilar las claves públicas de host SSH de un número de hosts
  • sftp.exe es el servicio que proporciona el Protocolo de Transferencia Segura de Archivos que se ejecuta sobre SSH
  • scp.exe es una utilidad de copia de archivos que se ejecuta en SSH

En el caso que se expone a continuación tiene como servidor SSH al equipo Windows 10 del usuario y como cliente al IBM i. La autenticación se realizará mediante un par de claves pública/privada, evitando el uso del usuario y contraseña. Esta configuración tiene más sentido que usar una contraseña que nunca cambie en el tiempo.

Preparar OpenSSH en Windows 10 o Windows Server 2019

Nota: Para todas las tareas de instalación y configuración de Windows se utilizará PowerShell con permisos de Administrador.

Instalación

No se suele encontrar instalado el servidor OpenSSH en equipos Windows [3], para comprobarlo se puede ejecutar el siguiente comando:

Get-WindowsCapability -Online | ? Name -like 'OpenSSH*'

Se mostrará en la consola algo parecido a esto:

Name  : OpenSSH.Client~~~~0.0.1.0
State : Installed

Name  : OpenSSH.Server~~~~0.0.1.0
State : NotPresent

En este caso, el cliente SSH está instalado y el servidor no lo está. Para instalar este último:

Add-WindowsCapability -Online -Name OpenSSH.Server~~~~0.0.1.0

Y si fuera necesario el cliente:

Add-WindowsCapability -Online -Name OpenSSH.Client~~~~0.0.1.0

En la consola debería verse la siguiente respueta por cada característica instalada:

Path          :
Online        : True
RestartNeeded : False

Ahora el estado de las características OpenSSH debería ser:

Name  : OpenSSH.Client~~~~0.0.1.0
State : Installed

Name  : OpenSSH.Server~~~~0.0.1.0
State : Installed

Nota: Si el estado aparece como Install pending se tiene que reiniciar Windows.

Nota: En las versiones iniciales de Windows también era necesario instalar la característica OpenSSHUtils para la generación de las claves, pero ya no es necesario [4] y ha desaparecido de los repositorios de Microsoft.

Resolución de problemas

En entornos corporativos o empresariales lo más probable es que exista una política de grupo donde se tenga configurado un servidor WSUS para la instalación de actualizaciones en los distintos Windows de la red. Normalente, la imagen de instalación que mantiene el servidor no suele incorporar características como OpenSSH. Además, suele ser el motivo de errores durante su instalación. Para comprobar si un equipo tiene configurado un servidor WSUS [5] se pueden consultar las siguientes claves del registro de Windows:

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\windows\WindowsUpdate\WUServer
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\windows\WindowsUpdate\WUStatusServer

Por ejemplo, durante la instalación del servidor OpenSSH en un equipo Windows 10 Pro con WSUS configurado se produjeron los siguientes errores:

Add-WindowsCapability : Error de Add-WindowsCapability. Código de error = 0x800f0954
En línea: 1 Carácter: 1
+ Add-WindowsCapability -Online -Name OpenSSH.Server~~~~0.0.1.0
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [Add-WindowsCapability], COMException
    + FullyQualifiedErrorId : Microsoft.Dism.Commands.AddWindowsCapabilityCommand

O este otro:

Add-WindowsCapability : Error de Add-WindowsCapability. Código de error = 0x8024500c
En línea: 1 Carácter: 1
+ Add-WindowsCapability -Online -Name OpenSSH.Server~~~~0.0.1.0
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [Add-WindowsCapability], COMException
    + FullyQualifiedErrorId : Microsoft.Dism.Commands.AddWindowsCapabilityCommand

Estos errores están relacionados con el uso de un servidor WSUS. Dependiendo de la versión de Windows y de cómo estén configuradas las GPOs, el error se puede resolver de varias formas:

En el ejemplo, el problema se solucionó desactivando temporalmente el servidor WSUS en el equipo cliente actuando sobre la siguiente clave del registro de Windows:

HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate\AU\UseWUServer

Con el valor cero (0) se desactiva el uso del servidor WSUS. A continuación hay que reiniciar el servicio Windows Update.

El siguiente script de PowerShell realiza todas las operaciones:

$currentWU = Get-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU" -Name "UseWUServer" | select -ExpandProperty UseWUServer
Set-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU" -Name "UseWUServer" -Value 0
Restart-Service wuauserv
Get-WindowsCapability -Name OpenSSH* -Online | Add-WindowsCapability –Online
Set-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU" -Name "UseWUServer" -Value $currentWU
Restart-Service wuauserv

Configuración del cortafuegos

Durante la instalación del servidor OpenSSH se creará y se habilitará una regla en el firewall llamada OpenSSH-Server-In-TCP, que permitirá el tráfico SSH entrante por el puerto 22. Si esta regla no está habilitada y el puerto no está abierto, se rechazará cualquier intento de conexión. Se puede realizar la siguiente comprobación:

Get-NetFirewallRule -Name *ssh*

Si la regla existe y está habilidad se recibirá una respuesta similar a a la siguiente:

Name                  : OpenSSH-Server-In-TCP
DisplayName           : OpenSSH SSH Server (sshd)
Description           : Inbound rule for OpenSSH SSH Server (sshd)
DisplayGroup          : OpenSSH Server
Group                 : OpenSSH Server
Enabled               : True
Profile               : Any
Platform              : {}
Direction             : Inbound
Action                : Allow
EdgeTraversalPolicy   : Block
LooseSourceMapping    : False
LocalOnlyMapping      : False
Owner                 :
PrimaryStatus         : OK
Status                : Se analizó la regla correctamente desde el almacén. (65536)
EnforcementStatus     : NotApplicable
PolicyStoreSource     : PersistentStore
PolicyStoreSourceType : Local

Si no existiera la regla se puede añadir con el siguiente script:

# Confirm the Firewall rule is configured. It should be created automatically by setup. Run the following to verify
if (!(Get-NetFirewallRule -Name "OpenSSH-Server-In-TCP" -ErrorAction SilentlyContinue | Select-Object Name, Enabled)) {
    Write-Output "Firewall Rule 'OpenSSH-Server-In-TCP' does not exist, creating it..."
    New-NetFirewallRule -Name 'OpenSSH-Server-In-TCP' -DisplayName 'OpenSSH Server (sshd)' -Enabled True -Direction Inbound -Protocol TCP -Action Allow -LocalPort 22
} else {
    Write-Output "Firewall rule 'OpenSSH-Server-In-TCP' has been created and exists."
}

Arranque del servidor SSH

Finalmente, se puede iniciar el servidor SSH con:

Start-Service sshd

O para que se inicie automáticamente cada vez que se arranque Windows:

Set-Service -Name sshd -StartupType 'Automatic'

Para comprobar el estado del servicio SSH se puede utilizar el siguiente comando:

Get-Service sshd

Y se obtendrá esta respuesta si estuviera parado:

Status   Name               DisplayName
------   ----               -----------
Stopped  sshd               OpenSSH SSH Server

O esta otra si estuviera iniciado:

Status   Name               DisplayName
------   ----               -----------
Running  sshd               OpenSSH SSH Server

Comprobación de la conexión

Desde una ventana de comando se puede probar la disponibilidad del servicio con un usuario local de Windows:

ssh localhost

El cliente SSH tomará el usuario de la sesión Windows y le solicitará la contraseña. También pueden utilizarse otros clientes SSH como Putty.

Si todo ha ido bien, se abrirá una sesión SSH en el servidor local. El comando exit se utiliza para cerrar la sesión SSH.

En este punto ya se tiene preparado el servidor SSH en el equipo Windows para realizar conexiones con autenticación con usuario y contraseña desde cualquier cliente, incluido el IBM i.

Configuración del cliente en el IBM i

Los siguientes programas bajo licencia tienen que estar instalados en el IBM i:

Resource
  ID     Option  Feature  Description
5770SS1  33       5111    Portable App Solutions Environment
5733SC1  *BASE    5050    IBM Portable Utilities for i
5733SC1  1        5050    OpenSSH, OpenSSL, zlib

Nota: Usar el mandato DSPSFWRSC para la comprobación.

Entorno de usuario

Para la configuración del entorno de usuario en el IBM i se utilizará PASE, abriendo una línea de comando con:

CALL QP2TERM

y siempre con autorizaciones equivalentes a QSECOFR, ajustando convenientemente los permisos y el propietario de los objetos que sean necesarios. Un usuario normal no debería tener acceso a una línea de mandatos ni tener permisos para ejecutar ninguno de los comandos descritos a continuación.

El usuario que inicie sesiones SSH tendrá que tener asignado un directorio de trabajo (home directory) en su perfil. Normalmente todos los directorios de usuario están ubicados en /home. Por ejemplo, ejecutar la siguiente secuencia de comandos desde QP2TERM:

> mkdir /home/someuser
> chmod 700 /home/someuser
> chown someuser /home/someuser

Nota: Sustituir el texto someuser por el nombre de un usuario válido.

El directorio de trabajo ya está creado, su propietario es someuser y sólo él tiene permisos. Si se consulta el directorio:

> ls -ld /home/someuser

Se obtendrá una salida similar a la siguiente:

lrwx------    1 someuser  0                42 30 may 2012  /home/someuser

A continuación asignar el directorio inicial (HOMEDIR) en el perfil de usuario:

CHGUSRPRF USRPRF(SOMEUSER) HOMEDIR('/home/someuser')

Toda la configuración SSH del usuario se almacenará en el directorio .ssh:

> mkdir /home/someuser/.ssh
> chmod 700 /home/someuser/.ssh
> chown someuser /home/someuser/.ssh

Autenticación basada en claves

Como ya se ha comentado, lo que se pretende es establecer una conexión con el servidor sin tener que introducir un usuario y una contraseña. A este método se le conoce como autenticación basada en claves [8] y es importante tener una noción básica de cómo funciona.

La autentcación basada en claves necesita un par de claves, una pública y otra privada. La clave pública puede compartirse con cualquier usuario o servidor. No hay problema en que sea conocida por el público en general. En cambio, la clave privada es, esencialmente, la contraseña de un usuario concreto y sólo puede ser conocida por éste. Tiene que protegerse con mucho cuidado.

El servidor SSH siempre almacena la clave pública de cada usuario que va a conectarse y el cliente (el usuario que se conecta) mantiene la clave privada.

Existen varios tipos de claves: RSA, DSA, ECDSA y Ed25519. Cualquiera sirve para establecer una conexión basada en claves. Para crear un par de claves RSA o DSA se utilzan los siguientes comandos desde QP2TERM:

> ssh-keygen -t dsa -N ""

> ssh-keygen -t rsa -N ""

Por ejemplo, si se opta por RSA se crearán dos archivos, uno para la clave pública (id_rsa.pub) y otro para la clave privada (id_rsa). Estos son los nombres por defecto y son demasiado genéricos. Lo más apropiado sería darles un nombre que ayudara a identificar (no demasiado) el servidor al que se va conectar.

El siguiente comando crea el par de claves que se utilizarán para conectar con el servidor SSH de Windows:

> ssh-keygen -t rsa -f /home/someuser/.ssh/windows_rsa_key -N "" -C "someuser@$(hostname)"

Generating public/private rsa key pair.
Your identification has been saved in /home/someuser/.ssh/windows_rsa_key.
Your public key has been saved in /home/someuser/windows_rsa_key.pub.
The key fingerprint is:
SHA256:Rg+lNi5Nh8lF71/oV+5Fd8RwHWLDaggEXu8y3h6AqZY someuser@ibm_i_server
The key's randomart image is:
+---[RSA 3072]----+
|     .oo .+ .+..+|
|    . .o.* ...o+.|
|     .  %.o o   o|
|      o*.* +   o |
|     o.+S.o . . *|
|    o .o=    o ++|
|   E   . o    o +|
|  .     . .    o.|
|         .      .|
+----[SHA256]-----+
$

Nota: en este ejemplo, las claves se generan en el lado del IBM i pero podrían obtenerse fácilmente desde Windows.

En el mundo SSH las autorizaciones son muy importantes y son causa de muchos fallos. Los ficheros y directorios de la configuración deben tener las autorizaciones y los propietarios correctos.

> chmod 600 /home/someuser/.ssh/windows_rsa_key
> chown someuser /home/someuser/.ssh/windows_rsa_key
> chown someuser /home/someuser/.ssh/windows_rsa_key.pub

El comando ssh-keygen suele proteger la clave privada para impedir el acceso a cualquiera que no sea el propietario. Cualquiera que consiga esta clave podrá conectar con el servidor haciéndose pasar por someuser.

Además, SSH dispone del archivo de configuración config [9] para almacenar todas las conexiones:

> touch /home/someuser/.ssh/config
> chmod 600 /home/someuser/.ssh/config
> chown someuser /home/someuser/.ssh/config

Por ejemplo:

Host windows
    HostName equipo.windows
    User win_user
    IdentityFile ~/.ssh/windows_rsa_key

Configurar la conexión con el equipo Windows

Para establecer la conexión basada en claves, el contenido de la clave pública creada anteriormente (windows_rsa_key.pub) debe situarse en el servidor [10] en un archivo de texto, cuyo nombre y ubicación dependen de si el usuario de Windows forma parte del grupo de administradores locales o es una cuenta estándar.

Nota: El archivo con la clave pública podrá descargarse por cualquier medio disponible, pero si se usa FTP habrá que activar el modo binario.

Nota: En el resto de este texto se identificará al usuario remoto de Windows como win_user. Sustituir este nombre por un usuario válido de Windows.

Usuario estándar

En el caso del usuario estándar, el contenido de la clave pública debe situarse en un archivo de texto llamado authorized_keys en el directorio ~/.ssh (C:\Users\win_user\.ssh). Si no existiera el archivo, simplemente se le puede cambiar el nombre al fichero .pub. En cambio, si ya existiera habrá que copiar el contenido de la clave pública al final de authorized_keys comenzando en una nueva línea.

Get-Variable Home

Name                           Value
----                           -----
HOME                           C:\Users\win_user

cd /users/win_user
md .ssh

Descargar en ~/.ssh el archivo del ejemplo windows_rsa_key.pub generado en el IBM i e incluirlo en authorized_keys.

cd .ssh
copy windows_rsa_key.pub authorized_keys

Grupo de administradores locales

Si el usuario es un administrador local, entonces la clave pública debe situarse en un archivo de texto llamado administrators_authorized_keys en el directorio C:\ProgramData\ssh\. La ACL de este archivo debe configurarse para permitir solo el acceso a los administradores y al sistema. La operativa para incluir la clave es la misma que la explicada para el usuario estándar.

Nota: Al descargar el archivo con la clave pública en el directorio C:\ProgramData\ssh es muy probable que se tengan problemas de autorizaciones. Una opción consiste en descargar el archivo en otro directorio, por ejemplo en Descargas, y después copiarlo al directorio definitivo. Incluso así, se necesitarán privilegios de administrador.

Para establecer los permisos apropiados [11] [12] para el archivo C:\ProgramData\ssh\administrators_authorized_keys se pueden ejecutar los siguientes comandos Powershell con privilegios de administrador:

$acl = Get-Acl C:\ProgramData\ssh\administrators_authorized_keys
$acl.SetAccessRuleProtection($true, $false)
$administratorsRule = New-Object system.security.accesscontrol.filesystemaccessrule("Administradores","FullControl","Allow")
$systemRule = New-Object system.security.accesscontrol.filesystemaccessrule("SYSTEM","FullControl","Allow")
$acl.SetAccessRule($administratorsRule)
$acl.SetAccessRule($systemRule)
$acl | Set-Acl

Advertencia: En la línea 3 anterior se establece la regla de autorizaciones para el grupo de usuarios Administradores. Este comando sólo es válido en la versión en castellano de Windows. En la versión en inglés se tiene que sustituir por Administrators.

Pruebas de conexión desde el IBM i

Con todo preparado y configurado es el momento de probar la conexión. Primero con una sesión interactiva. En el IBM i desde el terminal QP2TERM ejecutar el siguiente comando:

> ssh -T [email protected]

The authenticity of host 'equipo.windows (172.16.1.10)' can't be established.
ECDSA key fingerprint is SHA256:dvFcSpXosTybBtQdcIwdDNbI4mAG2C4eEWspSqczCuA.
Are you sure you want to continue connecting (yes/no/[fingerprint])?

En la primera conexión el servidor SSH preguntará al usuario si confía en él y si lo quiere añadir a la lista de servidores conocidos (~/.ssh/known_hosts). Esta pregunta sólo se hará una vez. Contestar con yes.

Se recibe una respuesta indicando que el servidor ha sido incluido en la lista de equipos conocidos.

Warning: Permanently added 'equipo.windows.dominio.local,172.16.8.106' (ECDSA) to the list of known hosts.
Microsoft Windows [Versi¢n 10.0.19041.264]
(c) 2020 Microsoft Corporation. Todos los derechos reservados.

dominio\[email protected] C:\Users\win_user>

A partir de este momento ya se pueden introducir comandos Windows en la sesión SSH. Cuando se introduzca el comando exit se regresará a la lína de comando de PASE.

Para ejecutar un comando Windows sin interacción con el usuario:

> ssh [email protected] 'dir \users\win_user\*.* >\users\win_user\diroutput3.txt'

En el directorio \users\win_user de Windows debería aparecer el archivo diroutput3.txt.

Perspectivas

SSH es una alternativa viable para sustituir el mandato RUNRMTCMD. Además ofrece un medio seguro para la comunicación con otros sistemas, sobre todo para el intercambio de archivos. En este texto sólo se ha mostrado cómo configurar SSH en dos equipos de entornos tan distintos como Windows o el IBM i. Sólo quedaría profundizar un poco más en la ejecución de scripts más complejos.

Ficha

Autor: Javier Mora
Publicación: 13 de Febrero 2022
Última revisión:

Valid XHTML 1.0! 

____________________________________________________
�nete a Recursos AS400, nuestra Comunidad ( http://bit.ly/db68dd )
Forum.Help400 � Publicaciones Help400, S.L.

Reply via email to