Windows – Gaia

Contrôler le nombre de paramètres passés à un programme CL – %PARMS() / CEETSTA

Il arrive parfois d’avoir moins de paramètres passés à un programme CL que le nombre attendu, par exemple si on ajoute un paramètre à ce dernier mais que pour diverses raisons on ne souhaite pas modifier et recompiler tous les programmes qui y font appel.

Il existe deux solutions relativement simples à implémenter pour contrôler le nombre de paramètres transmis afin d’adapter en conséquence le comportement du programme : La fonction intégrée %PARMS et l’API CEETSTA.

%PARMS() – V7R4 et ultérieures

À partir de la V7R4, rien de plus simple, il suffit d’utiliser la fonction intégrée %PARMS(), qui retourne le nombre de paramètres :

PGM PARM(&PARAM1 &PARAM2) /* Paramètres */ DCL VAR(&PARAM1) TYPE(*CHAR) LEN(10) DCL VAR(&PARAM2) TYPE(*CHAR) LEN(10) /* Corps du programme en fonction du passage du paramètre */ IF COND(%PARMS() *EQ 2) THEN(DO) SNDPGMMSG MSG('Le paramètre &PARAM2 est renseigné') ENDDO ELSE CMD(DO) SNDPGMMSG MSG('Le paramètre &PARAM2 n''est pas renseigné') ENDDO ENDPGM

Malheureusement, si on est confrontés à une contrainte de version, %PARMS ne descend pas en dessous de la V7R4 :

CEETSTA – V7R3 et antérieures

Dans ce cas, la solution la plus propre (je ne parlerai donc pas de monitoring sur un CHGVAR) est l’utilisation de l’API CEETSTA.
Il suffit de lui passer en paramètre :
– Une variable qui contiendra la valeur de retour, 1 si le paramètre est transmis, 0 s’il n’est pas transmis
– Une variable indiquant la position du paramètre à contrôler

presence_flag	Sortie	*INT	Variable de retour : 1 ou 0
arg_num	Entrée	*INT	Position de la variable à tester

PGM PARM(&PARAM1 &PARAM2) /* Paramètres */ DCL VAR(&PARAM1) TYPE(*CHAR) LEN(10) DCL VAR(&PARAM2) TYPE(*CHAR) LEN(10) /* Déclaration des variables nécessaires à l'utilisation de l'API */ DCL VAR(&PRESENCE) TYPE(*INT) /* Variable de retour : 1 ou 0 */ DCL VAR(&ARG_NUM) TYPE(*INT) VALUE(2) /* Position de la variable à tester */ /* Appel de l'API */ CALLPRC PRC('CEETSTA') PARM((&PRESENCE) (&ARG_NUM)) /* Corps du programme en fonction du passage du paramètre */ IF COND(&PRESENCE *EQ 1) THEN(DO) SNDPGMMSG MSG('Le paramètre &PARAM2 est renseigné') ENDDO ELSE CMD(DO) SNDPGMMSG MSG('Le paramètre &PARAM2 n''est pas renseigné') ENDDO ENDPGM

Remarques

Le compte des paramètres pour la arg_num commence à 1
La valeur de retour est un *INT pas un *LGL

Se connecter à un serveur SSH exécuté sous Windows à partir d’un IBM i (Comment obtenir la log pour débuguer les problèmes éventuels)

Mise en place d’OpenSSH Server sur Windows

Pour mettre en place OpenSSH Server sur Windows, la méthode « standard » consiste à passer par les Paramètres > Applications et fonctionnalités > fonctionnalités facultatives :

Il est recommandé de redémarrer Windows une fois la fonctionnalité ajoutée.

Il suffit ensuite de démarrer le serveur via le gestionnaire de Services Windows :

Il est également souhaitable de configurer le démarrage automatique du serveur :

Remarque
Il est également possible d’installer OpenSSH sur Windows via d’autres sources (GitHub par exemple) ce qui permet, entre autres, de choisir plus facilement sa version d’OpenSSH, voir section Détail.

Création d’un jeu de clefs SSH via ssh-keygen

Pour plus de détails sur la création de clefs, vous pouvez vous référer à l’article de Guillaume Gestion des clefs SSH.

Il est également possible d’utiliser PuttyGen, outil venant avec le client Putty pour générer le jeu de clefs de manière graphique (https://www.chiark.greenend.org.uk/~sgtatham/putty/latest.html).

Dans cet article je vais tout réaliser sur l’IBM i via QSH :

$ ssh-keygen -t ecdsa -f ~/.ssh/ssh_key

Mise en place de la clef privée et configuration côté IBM i (client)

On a généré la clef privée dans le répertoire .ssh de l’utilisateur, donc elle est déjà bien en place. Il suffit donc de créer un fichier config dans le répertoire .ssh de l’utilisateur afin de simplifier nos commandes pour la suite.
Voici un exemple de fichier config :

[~/.ssh/config]

Host windows
    Hostname sshd_server.lan
    User jl
    IdentityFile ~/.ssh/key
    StrictHostKeyChecking accept-new

Host	Nom de la configuration, utilisé à la place des différentes informations à la connexion
Hostname	Adresse ou nom du serveur à atteindre
User	Nom de l’utilisateur
IdentityFile	Chemin vers la clef privée
StrictHostKeyChecking accept-new	Permet d’ajouter automatiquement la signature du serveur distant au known_hosts

Mise en place de la clef privée et configuration côté Windows (serveur)

Il faut transférer la clef ssh_key.pub vers Windows et l’ajouter soit au fichier %UserProfile%.ssh\authorized_keys pour un utilisateur lambda, soit au fichier C:\ProgramData\ssh\administrators_authorized_keys pour un utilisateur ayant des droits d’administrateur local.

Attention à ce niveau, les droits des fichiers sont un peu particulières, il faut comme toujours avec le SSH réduire au maximum les utilisateurs ayant accès au fichier et, particularité de Windows, ajouter le droit de lecture au profil de service local Système :

Activation du fichier de log – Configuration sshd_config

Afin de pouvoir analyser d’éventuels problèmes ou simplement vouloir observer un peu plus en détail les différentes étapes de la mise en relation d’un flux ssh il est possible d’activer la log du serveur.

Par défaut celle-ci est redirigée vers les journaux d’évènements Windows et est seulement en « info ».
On les retrouver via l’Observateur d’événements Windows :

Le mieux à mon avis est de repasser par un système plus standard, soit un vrai fichier de logs.

Pour ce faire, il faut aller modifier le fichier de configuration du serveur SSH, généralement il se trouve ici :

C:\ProgramData\ssh\sshd_config
ou
%ProgramData%\ssh\sshd_config

Il faut rechercher les lignes suivantes :

[sshd_config]

# Logging
#SyslogFacility AUTH
#LogLevel INFO

Les décommenter et indiquer les valeurs suivantes :

[sshd_config]

# Logging
SyslogFacility LOCAL0
LogLevel Debug3

Une fois la configuration modifiée et le serveur redémarré, il suffit de retenter une connexion puis d’aller consulter le fichier de log :

C:\ProgramData\ssh\logs\sshd.log
ou
%ProgramData%\ssh\logs\sshd.log

Remarque
Les problèmes courants se passent généralement autour des lignes liées au fichier authorized_keys ou administrators_authorized_keys, problèmes de droits ou
chemin du fichier utilisé…

Test de SSH IBM i vers Windows

On peut maintenant tester le tout via QSH ou CALL QP2TERM.
Grâce au fichier config la commande est simple :
(l’option -T permet de désactiver l’allocation d’un pseudo terminal)

$ ssh -T windows
Microsoft Windows [version 10.0.19045.3208]
(c) Microsoft Corporation. Tous droits r

Il est maintenant possible d’exécuter des commandes Shell Windows à partir de cette connexion.

Si on voulait obtenir les mêmes niveaux de log côté client (IBM i) que l’on a activé côté Windows, on pourrait utiliser la commande suivante :

$ ssh -T -vvv windows
OpenSSH_8.0p1, OpenSSL 1.1.1t  7 Feb 2023                                            
debug1: Reading configuration data /home/jl/.ssh/config                              
debug1: /home/jl/.ssh/config line 1: Applying options for *                          
debug1: /home/jl/.ssh/config line 4: Applying options for laptop                     
debug1: Reading configuration data /QOpenSys/QIBM/ProdData/SC1/OpenSSH/etc/ssh_config
...
Microsoft Windows [version 10.0.19045.3208]
(c) Microsoft Corporation. Tous droits r

Pour plus de détails
OpenSSH.com : https://www.openssh.com/
OpenSSH Server sous Windows – Document Microsoft : https://learn.microsoft.com/fr-fr/windows-server/administration/openssh/openssh_overview
OpenSSH – GitHub : https://github.com/PowerShell/Win32-OpenSSH/releases

Archive d’étiquettes pour : Windows

Articles

Contrôler le nombre de paramètres passés à un programme CL – %PARMS() / CEETSTA

Se connecter à un serveur SSH exécuté sous Windows à partir d’un IBM i (Comment obtenir la log pour débuguer les problèmes éventuels)