, , Tracer l’usage d’une commande

Vous voulez savoir si une commande est utilisée, il y a plusieurs solutions en voici une basée sur les
programme d’exit qui est assez simple

Il existe un programme d’exit QIBM_QCA_CHG_COMMAND

Pour ajouter votre programme vous avez une commande ADDEXITPGM 

ADDEXITPGM EXITPNT(QIBM_QCA_CHG_COMMAND)   +
           FORMAT(CHGC0100)                +
           PGMNBR(1)                       +
           PGM(VOTREBIB/HSTCMD)           +
           TEXT('Tracer une commande') +
           PGMDTA('RSTLIB    QSYS')

Vous devrez lui indiquer dans la paramètre PGMDTA la commande qualifiée à tracer
exemple :
‘STRDBG QSYS’

Les données reçues sont sur le format CHGC0100 qui vous donne le découpage du buffer reçu par votre programme

Vous pouvez faire un programme générique qui va loguer l’utilisation d’une commande, vous pouvez en mettre plusieurs et la prise en compte est immédiate

Voici le source en clle du programme HSTCMD 

 PGM    PARM(&ExitInfo  &NewString   &Newlength)                 
       DCL  &Class       *CHAR   10                                                                                 
       DCL  &OffsetDec   *DEC  (7 0)
       DCL  &CmdLenDec   *DEC  (7 0)
       DCL  &ExitInfo    *CHAR 2000   /* CHGC0100 interface data      */
/* Input parameters                                                   */
       DCL  &ExitPoint   *CHAR   20   /* Exit Point name              */ 
       DCL  &ExitFormat  *CHAR    8   /* Exit Point Format            */ 
       DCL  &CmdName     *CHAR   10   /* Command name being executed  */ 
       DCL  &CmdLib      *CHAR   10   /* Command Library              */ 
       DCL  &Change      *CHAR    1   /* Change allowed? 1=yes 0=no   */ 
       DCL  &Prompt      *CHAR    1   /* Prompt requested? 1=yes 0=no */ 
       DCL  &Filler      *CHAR    2   /* Reserved by IBM              */ 
       DCL  &Offset      *CHAR    4   /* Offset to command string     */ 
       DCL  &CmdLength   *CHAR    4   /* Command string length        */ 
       DCL  &CmdString   *CHAR 2000   /* Command String               */          
/* Output Parameters                                                  */
       DCL  &NewString   *CHAR 2000   /* Replace with this command    */
       DCL  &NewLength   *CHAR    4   /* Length of new command        */
                                      /* 0 = no new command           */ 
DCL &JOB *CHAR 10
DCL &USR *CHAR 10
DCL &NBR *CHAR  6
       MONMSG   CPF0000    EXEC(GOTO ERROR)
/* découpage du paramètre reçu                                   */
       CHGVAR  &ExitPoint  %SST(&ExitInfo   1  20)             
       CHGVAR  &ExitFormat %SST(&ExitInfo  21   8)              
       CHGVAR  &CmdName    %SST(&ExitInfo  29  10)             
       CHGVAR  &CmdLib     %SST(&ExitInfo  39  10)              
       CHGVAR  &Change     %SST(&ExitInfo  49   1)              
       CHGVAR  &Prompt     %SST(&ExitInfo  50   1)              
       CHGVAR  &Filler     %SST(&ExitInfo  51   2)              
       CHGVAR  &Offset     %SST(&ExitInfo  53   4)              
       CHGVAR  &CmdLength  %SST(&ExitInfo  57   4)               
       CHGVAR  &CmdLenDec  %BIN(&Cmdlength)                   
       CHGVAR  &OffsetDec  (%BIN(&Offset) + 1)          /* Set offset */
       CHGVAR  &CmdString  %SST(&ExitInfo &OffsetDec &CmdLenDec)
/* Extraction du travail */
                    RTVJOBA    JOB(&JOB) USER(&USR) NBR(&NBR)          
/* envoi message à qsysopr */ 
             SNDUSRMSG  MSG(&job *tcat '/' *tcat &usr *tcat +   
                          '/' *tcat &nbr *bcat %sst(&CmdString 1 + 
                          100) ) MSGTYPE(*INFO) TOUSR(*SYSOPR)
/* passage de la commande sans transformation */
chgvar &NewString &CmdString
chgvar &NewLength &CmdLength 
ERROR:
return
ENDPGM

Remarque :

Vous n’avez pas besoin de mettre en place des audits et tout est dynamique

Vous pouvez transformer une commande ou la remplacer par une autre

Pour voir les commandes que vous tracez

==> WRKREGINF QIBM_QCA_CHG_COMMAND

Exemple :


Les commandes qui commencent par DLT, je remplace par un message suppression refusée pour certain utilisateurs

Rappel :

Un programme d’exit doit être simple et ne pas planter !

/par
, Mot de passe QSECOFR désactivé

Il y a plusieurs solutions, la plus simple est sans doute celle la ,vous devrez avoir accès à la console et connaitre un mot de passe sur la console (HSCROOT par exemple)

Il faut savoir que vous pouvez vous connecter à celle ci, même si vous avez un mot de passe désactivé.

A partir d’ACS

Sélectionner Console 5250

Vous devez rentrer un mot de passe de votre HMC, exemple HSCROOT

Vous devez choisir votre partition

et saisir le mot passe même *DISABLED sur la mire d’ouverture

Une fois connecter il suffit de réactiver le profil

==>CHGUSRPRF USRPRF(QSECOFR) STATUS(*ENABLED)

Remarque:

Il est malgré tout conseillé d’avoir un compte de secours que vous dédiez à une reprise derrière une désactivation intempestive.

Par exemple :

SECOURS qui sera dédié à ca avec des droits identiques à QSECOFR et avec un mot de passe gardé au coffre

plus d’informations ici : https://www.ibm.com/support/pages/qsecofr-profile-disabled

/par
, La bibliothèque QUSRTOOL

C’est une bibliothèque qui contient les sources d’environ 15 outils IBMi, le plus connu est NETS qui permet de gérer les partages en mode 5250.
Elle est développée par Jim Sloan, ce sont les outils TAATOOLS et depuis la version V3.7 ce sont eux qui gérent les licences.

Donc vous pouvez acquérir une licence du produit en vous adressant ici : support@taatool.com

Vous pouvez également avoir une version des outils sur votre machine : en effet avant la version 3.7 IBM distribuait gratuitement ce produit

pour plus d’information c’est ici

https://www.ibm.com/support/pages/qusrtool-status

Pour la gestion des partages, vous avez une explication ici

https://www.ibm.com/support/pages/manage-ibm-i-netserver-without-navigator-go-nets

Dans ce menu vous avez par exemple l’option 12 qui permet de gérer les utilisateurs désactivés, c’est une alternative simple à Navigator for i dans certains cas.

/par
, , , Utiliser les listes de validation comme coffre fort de mot de passe

Pour rappel, les listes de validation sont des objets sur IBMi, de type VLDL.

Par ligne de commande, on peut seulement créer une liste ou la supprimer.

L’utilisation classique des listes d’autorisation est la sécurisation de vos serveurs IWS par authentification basique. Celles-ci permettent l’utilisation d’un profil qui n’est pas un réel utilisateur IBM i.

La gestion, de ces listes, se passe dans navigator for i, dans le HTTPAdmin :

Onglet « Advanced »

Ce que vous pouvez faire :

  • Ajouter une entrée dans la liste, si la liste de validation n’existe pas, elle sera créé pour l’occasion. A minima, il faut renseigner la liste de validation, un profil et un mot de passe
  • Changer le mot de passe d’une entrée
  • Supprimer une entrée
  • Lister les entrées d’une liste

Ce que vous ne pouvez pas faire :

  • Consulter le mot de passe en cours d’une entrée, un classique en terme de sécurité.
  • Supprimer une liste de validation, il faut utiliser la commande 5250 DLTVLDL

Pour mettre en place la sécurisation d’un serveur via ces listes, il faut, toujours depuis le HTTPAdmin, au niveau de la gestion des sécurités de votre serveur HTTP*, sélectionner l’option liste de validation :

Avantage :

  • Ne pas créer de réel utilisateur IBMi pour l’authentification.
  • Permettre à des tiers extérieurs d’avoir un login ne pouvant servir que dans le cadre d’appel HTTP à un serveur protéger par la liste d’autorisation dont est issu le login
  • Encryption de la liste au niveau OS. Pas de possibilité d’accès aux données de la liste de façon simple.

    En cas d’appel depuis l’extérieur du réseau de confiance, ça semble une bonne option.

Inconvénient :

  • Il faut connaître en amont le client qui va se connecter, et donc avoir une gestion de demande /création de compte
  • L’interface de gestion n’est pas compatible avec un grand nombre d’entrées dans la liste. Dans ce cas il faudra, soit trouver une autre solution pour sécuriser son serveur, soit utiliser les API misent à disposition par IBM

* Sur les versions récentes, la sécurité peut aussi être gérée au niveau du serveur applicatif. A vous de voir, si vous voulez un duo de serveurs HTTP/applicatif ou seulement un serveur applicatif, mais c’est un autre sujet…

Les API de gestion des listes de validation

La documentation officielle :

https://www.ibm.com/docs/fr/i/7.5?topic=ssw_ibm_i_75/apis/sec6.html

IBM nous fournit des API pour gérer les listes de validation. On retrouve les actions possibles dans Navigator for i…. Et d’autres !

En regardant de plus près ces API, on constate sur la création d’une entrée de la présence d’un attribut permettant ou non de décrypter un mot de passe :

Navigator for i utilisant les valeurs par défaut, lorsqu’on crée une entrée par ce biais, le mot de passe n’est pas décryptable.
Par contre, si on crée une entrée par l’API correspondante, avec cet attribut positionné à QSY_VFY_FIND (1), on peut par la suite récupérer le mot de passe via l’API C QsyFindValidationLstEntry() ou son équivalent QSYFDVLE

Prenons des exemples :

Je crée dans une liste de validation, dédié à l’article, DTFORM/DEMOBLOG, un profil MdpnonVIsible avec l’attribut de décryptage à ‘0’, et un profil MdpVisible avec l’attribut de décryptage à ‘1’.

Première remarque : l’appel d’api d’ajout d’une entrée dans une liste de validation renvoie un erreur si la liste n’existe pas. Il faut la créer au préalable par la commande CRTVLDL.


En regardant dans Navigator for i, les deux entrées apparaissent sans distinction :

Lors du décryptage, si on tente un appel de l’API find avec une erreur, mauvais nom de liste, profil inexistant, …, le retour est en erreur, comme pour toutes les API : -1. On peut récupérer le message détaillé de l’erreur, on reste sur de la gestion standard :

Si on lance l’API Find avec pour le profil MdpnonVisible :

L’API renvoie un code retour ok, mais pas de mot de passe, normal, il n’est pas décryptable.

Avec le profil décryptable, on récupère bien le mot de passe initial :

Par cette méthode, vous pouvez donc récupérer des mots de passe stockés dans une liste de validation, à la condition que l’entrée ait été créée avec le top de décryptage à ‘1‘.

Pour compléter la sécurité sur le décryptage des mots de passe, vous pouvez mettre :

  • Sur la liste de validation
    • Un profil technique comme propriétaire
    • Aucun droit sur aucun autre profil .
  • Avoir un programme dédié au décryptage avec :
    • Comme propriétaire le même que celui de la liste de validation
    • Compilé pour faire de l’adoption de droit.
  • Et si on veut aller plus loin, en cas de debug possible en prod, protéger les sources, du programme de décryptage et ses appelants, par mot de passe.

Bien entendu cette stratégie n’est valable que si la gestion des droits utilisateurs est rigoureuse… Pas de *allobj sur les profils par exemple !

Conclusion :

Vous pouvez utiliser les listes de validation pour stocker des profils/mot de passe, sans les stocker en clair sur la machine. Mais on peut très bien imaginer utiliser ces listes pour stocker toutes les données sensibles permettant les échanges inter-applications ou autre :

  • URL d’invocation de WS
  • IP ou nom DNS pour FTP / SFTP
  • …

Et pour cela de se créer une liste par usage, liste pour URL, liste pour IP/DNS, …, de mettre dans le profil, un code application, et dans le mot de passe la valeur que l’on veut récupérer, avec la limitation de 600 caractères pour le mot de passe, à part pour des URL très spécifique, ça ne devrait pas être limitatif.

Les listes de validation restent des objets très peu connu, mais qui mérite de l’être !

/par
, Zones avec informations confidentielles

Vous pouvez utiliser le catalogue base de données pour identifier vos informations sensibles

Pour cela vous allez utiliser les vues syscolumns de QSYS2 (norme IBMi) ou sqlcolumns de SYSIBM (norme DB2)

Vous pouvez rechercher toutes les zones qui contiennent (email, mail, RIB, IBAN, ETC..)

Dans notre exemple , on recherchera les zones IBAN dans toutes les tables en analysant :
Nom de zone SQL
Nom de zone IBMI
Entête de colonne
Texte de colonne

Sans différentiation de majuscule minuscule

Et on sortira la liste des droits public sur ces objets


— liste des fichiers avec une zone IBAN

— Avec un IBAN

SELECT COLUMN_NAME AS Zone,
IFNULL(COLUMN_HEADING, ' ') AS Entete,
IFNULL(COLUMN_TEXT, ' ') AS Text,
TABLE_SCHEMA AS bibliotheque,
TABLE_NAME AS fichier,
(SELECT OBJECT_AUTHORITY
FROM QSYS2.OBJECT_PRIVILEGES
WHERE SYSTEM_OBJECT_SCHEMA = TABLE_SCHEMA
AND OBJECT_NAME = TABLE_NAME
AND OBJECT_TYPE = '*FILE'
FETCH FIRST ROW ONLY) AS DROIT_public
FROM qsys2.syscolumns
WHERE COLUMN_NAME LIKE ('%IBAN%')
OR SYSTEM_COLUMN_NAME LIKE ('%IBAN%')
OR UCASE(COLUMN_HEADING) LIKE ('%IBAN%')
OR UCASE(COLUMN_TEXT) LIKE ('%IBAN%');

Conclusion :

Ca veut dire que toutes les tables avec *public à *USE sont visualisables par tous les utilisateurs de la machine.

Pour sécuriser vous devez le faire sur les fichiers
Soit
– Mettre en place des droits sur l’objet, attention l’utilisateur peut avoir droit à ce fichier quand il est dans l’application.
Soit
– Sécuriser un service d’accès par exemple ici ODBC, pour éviter un accès remote, (Fonctions usage ou programme d’exit sont les meilleurs solutions)

Bien sur si vous créez de nouvelle table vous pouvez crypter ces zones, ce qui la rendrait illisible à un utilisateur qui ne connait pas la clé

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

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_flagSortie*INTVariable de retour : 1 ou 0
arg_numEntrée*INTPosition 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

Pour plus de détails

Documentation IBM – %PARMS() : https://www.ibm.com/docs/en/i/7.5?topic=procedure-parms-built-in-function
Documentation IBM – CEETSTA : https://www.ibm.com/docs/api/v1/content/ssw_ibm_i_75/apis/CEETSTA.htm
/par
, Surveillez l’état de vos bandes

Vous sauvegardez sur des bandes LTO, et vous voulez savoir si vos bandes sont en bon état,
pour en savoir plus sur les LTO : https://fr.wikipedia.org/wiki/Linear_Tape-Open

La durée de vie théorique d’une bande LTO est donnée pour 30 ans, mais elle dépend beaucoup des conditions d’utilisation et elles peuvent être défectueuses.
Certaines sociétés changent leurs bandes tous les 3 ans.

La bonne pratique c’est de le faire quand vous changez votre POWER en principe tous les 3 à 5 ans.

Mais il peut être important de contrôler l’état de vos supports pour éviter les mauvaises surprises.

Il n’existe pas de service SQL ni de sortie outfile pour l’instant.

Vous allez pouvoir faire une analyse par volume.

C’est vous qui indiquez le nom de volume quand vous formater votre support
INZTAP DEV(TAPXXX) NEWVOL(xxxxxx) vous disposez de 6 caractères

Exemple :
==>INZTAP DEV(TAP01) NEWVOL(LUNDI1) …

La commande qui va vous permettre d’analyser ces volumes est la commande PRTERRLOG
qui va vous générer un spool QPCSMPRT.

En principe vous avez un roulement de bande par semaine.

Vous pouvez contrôler le volume dans le lecteur avant de déclencher une sauvegarde, mais il n’est pas conseillé de la bloquer, vous pouvez remonter un message.

« * Attention bande du LUNDI trouvée dans le lecteur * »

Exemple

Vous devez connaitre le type de votre unité de bande pour utiliser cette commande.

==>DSPDEVD TAP01

==>PRTERRLOG TYPE(VOLSTAT) OUTPUT(PRINT)
VOLTYPE(3580)
VOLSTATTYP(*LIFETIME)

Si vous avez des erreurs il faut remplacer vos bandes.

Pour vous aider à automatiser cette remontée d’information, vous pouvez utiliser notre outil disponible ici :

https://github.com/Plberthoin/PLB/tree/master/SNDVOLSTAT

Remarque :

Il est important :
d’avoir un plan de reprise d’activité suite à un crash
de tester une restauration partielle de temps en temps
de passer la cartouche de nettoyage tous les 6 mois

/par
, , , SQL – appel de webservice

Depuis la V7R1 (SF99701 – DB2 – niveau 23), on peut invoquer des web service via SQL. Les fonctions se trouvent dans SYSTOOLS.

En V7R4 TR5, sont sorties de nouvelles fonctions, elles se trouvent dans QSYS2.

Outre les fonctions HTTP, celles pour encoder / décoder en base64 et pour encoder / décoder L’URL, ont aussi été implémentées dans QSYS2.

Rappel des différences entre ces fonctions

Tout d’abord les performances. Les fonctions de QSYS2 permettent un gain non négligeable, elles sont basé sur les fonctions AXIS en C natif, contrairement à celles de SYSTOOLS qui sont basées sur des classes java.

Les paramètres dans l’entête ou le corps du message sont transmis en JSON pour les fonctions de QSYS2, à la place de XML pour celle de SYSTOOLS.

La gestion des certificats est simplifiée par l’utilisation de DCM, alors qu’avec les fonctions de SYSTOOLS, il fallait pousser le certificat dans le magasin du runtime java utilisé par les fonctions HTTP. En cas de multiple versions de java installées, il fallait s’assurer de laquelle servait pour les fonctions HTTP. L’ajout du certificat, se faisait via des commandes shell.

Les types et tailles des paramètres des fonctions ont été adaptés pour ne plus être des facteurs limitants de l’utilisation des fonctions SQL, voici quelques exemples :

Certaines utilisations ont aussi été simplifiées en automatisant des tâches.

Prenons l’exemple d’un appel à un web service avec une authentification basique. Le couple profil / mot de passe doit être séparé par « : » et l’ensemble encoder en base64. C’est la norme HTTP.

Dans le cas des fonctions de SYSTOOLS, il fallait effectuer l’ensemble des opérations, alors qu’avec les fonctions de QSYS2, il suffit de passer le profil et le mot de passe dans la propriété BasicAuth. La mise en forme et l’encodage étant faits directement par les fonctions AXIS :

Il y a par contre un cas limitatif des fonctions QSYS2, que IBM a rajouté, alors que la norme HTTP autorise ce type d’appel.

Il s’agit d’avoir une authentification basique sur un appel en http.

Ce cas n’est pas trop contraignant, aujourd’hui le https est la norme et le http quasiment disparu…. quasiment !
Nous rencontrons encore chez nos clients des web services « interne » en http. La migration en https n’étant pas vendeur auprès des directions qui n’y voit aucun gain pour le métier. C’est l’éternel problème des changements structurels en IT.

Dans ces cas, la fonction de QSYS2, renverra une erreur, assez claire !

Le premier réflexe est de voir avec le fournisseur du service s’il ne dispose pas d’une version en https.

Maintenant, si vous n’avez pas d’autre choix que d’appeler un web service en http avec authentification basique, il faudra continuer d’utiliser les fonctions de SYSTOOLS. Dans tous les autres cas, aucune hésitation, utilisez les fonctions de QSYS2.

Mais mettons nous d’accord, de l’authentification basique en http, ce n’est pas de la sécurité, c’est une absurdité.

En http, le message passe en clair sur la trame réseau, avec votre profil / mot de passe, encodé en base 64, et non encrypté, donc en clair eux aussi.

Edit : Précision apportée par Gautier Dumas de CFD-innovation. Merci à lui.
On peut contourner le problème avec les fonctions de QSYS2. Il ne faut pas utiliser la propriété BASICAUTH, mais construire l’authentification basique comme on le faisait avec celle de SYSTOOLS.
VALUES QSYS2.HTTP_GET(
‘http://hostname/wscommon/api/contacts’,
‘{« header »: »Authorization, BASIC dGVzdHVzZXI6dGVzdHB3ZA== »}’);
Il n’y a donc vraiment plus de raison de continuer avec les fonctions de SYSTOOLS !

/par
, , , Effacer la log de votre travail

Vous faites le l’administration, le plus souvent en 5250 sous l’écran de commandes IBMI
==> call QCMD

Vous voulez effacer la log que vous voyez par la commande DSPJOBLOG.

La première solution consiste à vous déconnecter, du coup la log est effacée ou transformée en spool.

Cette méthode efface tout le contexte mis en place, liste de bibliothèques , variables d’environnement, objets dans QTEMP que vous avez peut être mis beaucoup de temps à construire dans vos tests.

L’idée c’est d’avoir une solution moins radicale qui permette de n’effacer que la log de votre travail, c’est pourquoi vous devriez avoir dans vos tools un outil comme celui la

Une commande qu’on a appelé astucieusement CLRLOG que vous pouvez trouver ici

https://github.com/Plberthoin/PLB/tree/master/CLRLOG

Comme le code est simple on le remet ici

On utilise la commande RMVMSG qui n’est utilisable que dans un programme CLLE

Le programme en CLLE

 PGM /*------------------------------------*/        
 /* Supprime les messages de votre log     */        
 /* Ne supprime pas les messages *PGMQ     */        
 /*----------------------------------------*/        
              RMVMSG     PGMQ(*ALLINACT) CLEAR(*ALL) 
              RMVMSG     PGMQ(*EXT) CLEAR(*ALL)      
 ENDPGM

La commande 

 /* Supprime les messages de votre log     */ 
CMD        PROMPT('Clearer la log de votre job')

Remarque :

Cette commande n’efface pas les messages de type *PGMQ

/par
, , , 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)

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
HostNom de la configuration, utilisé à la place des différentes informations à la connexion
HostnameAdresse ou nom du serveur à atteindre
UserNom de l’utilisateur
IdentityFileChemin vers la clef privée
StrictHostKeyChecking accept-newPermet 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
/par