19 juin 2014

Utiliser une clef SSH pour se connecter avec Putty, Filezilla

L'utilisation des clefs SSH permettent de remplacer l'authentification par mot de passe demandée par le serveur Unix/Linux. Pour ceci chacun doit se créer sa propre clef, puis le gestionnaire du compte Unix/Linux doit la référencer dans la liste des clefs autorisés.

A noter :
  • En fait chacun se crée un "couple" de clefs :
    • Une est dite "privée". Elle ne doit rester strictement la propriété de son créateur. Elle sert notamment à chiffrer les communications,
    • La seconde est dite "publique". Son propriétaire la transmet à ses "interlocuteurs". Elle sert à authentifier le propriétaire des clefs et à déchiffrer ses communications.
  • Ce système peut aussi servir entre deux applications,
  • Le bon fonctionnement de l'authentification par clef dépend de son paramétrage par l’administrateur Unix/Linux (/etc/ssh, droits d'accès)

Création des clef

  • Télécharger PuttyGen.exe
  • Exécuter PuttyGen
  • Choisir (par exemple) un type de clef RSA et une longueur de clef de 2048 bits :

  • Cliquer sur "Generate" et déplacer la souris pour générer une clef aléatoire,

  • Une fois la clef calculée, indiquez en commentaire vos nom et prénoms. Pour des raisons de sécurité (vol de votre clef privée), il est conseillé de paramétrer un mot de passe pour pouvoir utiliser la clef. Ceci est facultatif.

  • Sauvegardez les clefs, par exemple sous le nom :
    • Prénom_NOM.pub pour la clef publique
    • Prénom_NOM.ppk pour la clef privée

A noter : sur une machine Unix ou Linux la création de la clef peut être réalisée en mode commande.
Par exemple : ssh-keygen -t rsa -b 2048 -C "Nom Prenom" -f Prenom_NOM

Paramétrage sur le serveur

  • Transmettre la clef publique à l’administrateur pour qu’il la place dans le fichier « $HOME/.ssh/authorize_keys » du compte ciblé
 A noter : les droits Unix/Linux sur le répertoire ".ssh" et le fichier "authorized_keys" doivent être restrictifs sans quoi les autorisations ne seront pas prises en compte.

Paramétrage sur le micro

  • Pour Putty indiquez l’emplacement de la clef privée dans Connection / SSH / Auth « Private key file for authentication »



  • Pour Filezilla indiquez l’emplacement de la clef privée dans Edition / Paramètres / Connexion / SFTP « Ajouter une clef privée »

Test de connexion


login as: hradev
 

Authenticating with public key "Digix"
Passphrase for key "Digix":
-------------------------Avis aux utilisateurs----------------------------------
Tout acces non autorise sur ce systeme est passible de poursuites.
--------------------------------------------------------------------------------
hr9dev@srvlnx001:/home/hradev>

12 juin 2014

Créer un "DIRECTORY" Oracle en référençant le code instance

Ci dessous un script SQL qui crée dans la base Oracle un "DIRECTORY" nommé HR_FILE pour les outils d'export import "Data Pump".

La plupart du temps le chemin contient le nom de l'instance, ce qui nécessite de variabiliser l'ordre de création.

Ici Gabriel récupère ce nom dans une variable "SID" qu'il réutilise lors du "CREATE" :

COLUMN INSTANCE NEW_VALUE SID NOPRINT
SELECT SYS_CONTEXT('USERENV','DB_NAME') AS INSTANCE
FROM DUAL
/
CREATE DIRECTORY HR_FILE AS '/oracle/&SID./exports'
/



11 juin 2014

Un effet de bord de la "Timezone" Linux sur les dates saisies dans HRCT


Sur certains environnements les utilisateurs nous ont signalés que les dates saisies via interface web de HRCT sont altérées (stockées en base à J – 1 : par exemple un utilisateur qui saisit 01/03/2014 retrouvera en base 28/02/2014). Hors pour d'autres environnements hébergés sur d’autres serveurs, la saisie est correcte.

Après contact avec l’éditeur, celui-ci nous suggère de contrôler les TimeZone des machines incriminées.

Si la commande « date +%Z » affichait le même résultat, les commandes suivantes indiquaient effectivement des différences :
  • Sur une machine correcte :
hr-configuration-tool-web-smartgwt.log: user.timezone=Europe/Paris

ls -l /etc/localtime
-rw-r--r-- 1 root root 2945 29 oct. 2013 /etc/localtime

  • Sur une machine incorrecte :
hr-configuration-tool-web-smartgwt.log: user.timezone=GMT
 

ls -l /etc/localtime
-r--r--r-- 1 root root 5890 6 sept. 2013 /etc/localtime


Après correction du /etc/localtime par l'administrateur Unix, le comportement de HRCT est redevenu normal.

PS : La date HRCT passait à J-1 car  01/03/2014 moins une heure donne 28/02/2014:23:00 - puis l'heure est tronquée.


Autre option, à tester : ajouter l'option "-Duser.timezone=Europe/Paris" à la ligne de commande Java de Tomcat.

2 juin 2014

Envoyer un mail par Telnet

Ci dessous un exemple d'invocation d'un serveur mail avec Telnet.

Indiquez :
  • L'adresse IP du serveur (ici 1.2.3.4) et le port (ici 25)
  • Le nom de domaine (ici digix.com)
  • L'émetteur ("mail from:"),
  • Le recepteur ("rcpt to:"),
  • Le contenu du mail ("data"),
  • Terminez par un "." et "quit"
Ce genre de test peut servir à débugger un problème de connexion entre HRQuery et le serveur mail de l'entreprise.

telnet 1.2.3.4 25
Trying...
Connected to 1.2.3.4.
Escape character is '^]'.
220 MAILSERVER.intranet.xyz Microsoft ESMTP MAIL Service ready at Mon, 2 Jun 2014 13:43:32 +0200
helo digix.com
250 MAILSERVER.intranet.xyz Hello [1.2.3.4]
mail from:joe@digix.com
250 2.1.0 Sender OK
rcpt to:jack@digix.com
250 2.1.5 Recipient OK
data
354 Start mail input; end with <CRLF>.<CRLF>
Ceci est un test d'envoi de mail

.
250 2.6.0 <21c55b59-a638-4615-8938-0d5a5edbcb8a@MAILSERVER.intranet.xyz> Queued mail for delivery
quit
221 2.0.0 Service closing transmission channel
Connection closed.