Ubuntu 16.04 et problème de connexion SSH par clef

Mise à jour d’une de mes machines vers Ubuntu  16.04  et depuis impossible de se connecter en SSH via clef.

Mon système me demande irrémédiablement le mot de passe du serveur.

Après une petite recherche sur le net il s’avère que Ubuntu 16.04 a besoin que sa clef publique soit dans le fichier ~/.ssh/authorized_keys

Hors les fichiers générés par ssh_keygen sont placé en ~/.ssh/id_rsa.pub ou ~/.ssh/id_dsa.pub

Un simple mv ~/.ssh/id_rsa.pub ~/.ssh/authorized_keys   (ou id_dsa.pub) fera tout rentrer dans l’ordre.

 

RaspberryPI 2 et 3 : sortie de 4 distro Ubuntu.

A peine sorti le RaspberryPi 3 et voila 4 distrib pour RaspberryPi 2 et 3 proposées :

Ces distribution en sont pas compatibles RaspberryPi 1 (compatible à partie du ARM V7, le 1 est en V6).

Un seul Download par disto donc  pas de portage (aucune trace dans le changelog) 64bits : juste (et c’est déjà énorme vu les délais) une adaptation aux nouveaux hardware (wifi et BlueTooth) du RaspberryPi3.

CURL : Uploader un fichier en ligne de commande vers un serveur WebDav

Cas d’utilisation.

Devoir travailler sur une plateforme OpenWRT ne possédant pas de client SSH.

Comment faire pour récupérer des fichier de cette cible ?

Une solution – si CURL est présent sur la cible – consiste à :

  • Installer un serveur WebDAV ‘basique’ (sans authentification)
    • nb : penser à rédiger un article sur ce thème
  • Uploader les fichiers – de la cible vers le serveur – via CURL

Pour uploader un fichier sur notre serveur WebDAV


curl -T myFile.sh http://10.10.254.120/myRepo/myFile.sh

Screen : Incompatibilité du partage de terminal sur des serveur multi-réseau ?

Cas d’étude vécu aujourd’hui.

2 développeur (dont moi) travaillant chacun sur un réseau local distinct.
Besoin de travailler ensemble sur une maquette présente sur un Raspberry Pi.

J’opte alors pour screen et surtout pour son option de partage de terminal  offrant la capacité de travailler à plusieurs sur un même terminal.

Un un réseau local aucun problème pour partager un terminal.

Mais impossible de partager (-x) et même de lister (-r) les terminaux créés – sur un réseau A – à partir d’un réseau B (voir schéma).

screen

 

Fort dommage 🙁

Si vous avez la moindre idée pour contrer cette limitation n’hésitez pas à me contacter.

 

 

[Update] Installer (et exploiter) Docker sur des architectures « non supportées » (Raspbian/Intel 32 bits)

[Update] Docker natif sur la dernière version de Jessie

Suite au dernier Update de Raspbian  (Release date: 2016-02-09) docker s’installe d’un simple apt-get install docker.io

Limitations constatées (par rapport à la version Hypriot) :

Disparition du -f pour le build

Impossible de spécifier le Dockerfile de cette manière

<code>

docker build -t favela/lampbase:1.0.0   -f ./lampbase.dockerFile   .

</code>

Obliger de créer un fichier Dockerfile (avec un D majuscule) et de la copier dans un répertoire (ex : lampbase)

<code>

docker build   -t favela/lampbase:1.0.0  ./lampbase/

</code>

Un simple docker pull resin/rpi-raspbian:jessie plante (trove pas le endpoint) : je repars donc sur la version Hypriot.


 

Docker ne supporte que les architectures 64 bits.

Cela est fort dommage car cela nous prive de nombreuses target de test et/ou d’exploitation.

Heureusement il existe des initiatives pour porter Docker vers des architectures autres :

Debian Intel  32 bits


apt-get update

apt-get install docker.io

Plus qu’à tester (en root) avec un « docker ps  »

Raspbian (Raspberry Pi)

  • La team Hypriot a réalisé un formidable travail de portage de docker sur Raspbian.
  • Téléchargez le .deb à l’adresse suivante partie « Hypriot Docker Debian Packages for Raspberry Pi »
  • Puis un simple

dpkg -i package_name.deb

 

Et cela fonctionne même sur un simple Raspberry Pi Zero !

PS : je n’ai testé que sur Debian Jessie pas sur Wheezy.

PS2 : le service docker n’est pas lancé au boot,  pensez à le lancer avant vos tests.


service docker start &amp;amp;amp;amp;&amp;amp;amp;amp; service docker status

Ubuntu ARM



apt-get install docker.io 

 

Attention au bon choix de vos machines docker

  • Attention : les images Docker récupérées sur le hub docker sont en majorité des images Intel 64bits : donc incompatibles avec nos target de test.
  • Pensez à bien vérifier la compatibilité de vos images.

Des test à la Prod

  • Si vos dockerfiles sont bien écris , le passage d’une plate-forme de test à une prod 64 bits ne devrait pas poser de problème (en restanbt sur le même type de distribution évidement, par exemple d’une Raspbian à une Debian) : seul le FROM devra être changé.

 

UFDBGuard : Time-Based ACLs et Default ACL

Ajouter une règle de plage horaire

UFDBGuard propose une gestion des horaires (voir page 36 de leur manuel).

On peut, grace à cette ACL, appliquer (ou non) des politique de blocage/ouverture sur des catégories de domaines/Expressions…

Par exemple : bloquer le sport et les sites de rencontre  aux heures de bureau mais les ouvrir en dehors.

La doc est très claire quant on utilise des ACL multiples mais mais ne signale pas que ce type d’ ACL n’est pas compatible avec l’ACL défaut.

 

Exemple d’ACL ne fonctionnant pas

 


time free-time {
weekly * 12:00-13:30
}


# define web content access rights
acl {

default outside free-time {
pass !porn !sport !dating any
}else{
pass !porn any
}
}

Un coup d’oeil dans les log vous montrera que UFDBGuard est en « FATAL ERROR » à chaque fois qu’il est sollicité.

Il semblerait qu’il soit impossible d’associer une ACL Time à Default. Bien dommage quant on n’a pas besoin d’avoir une policy (basée sur IP, groupe…) .

On va donc devoir créer une policy (qui soit toujours vraix) pour court-circuiter default.

Pour ma part j’ai créer une policy sur ma plage IP (car je sais qu’elle sera toujours vrai).
Je suis sur une plage 172.16.x.x


time free-time {
weekly * 12:00-13:30
}

src blacklistsrc {
ip 172.16.0.0/16
}

# define web content access rights
acl {
blacklistsrc outside free-time
{
pass !porn !sport !dating any
}
else
{
pass !porn any
}
default {
pass any
}
}

Avec une ACL « non default » tout fonctionne correctement.

Plusieurs plages horaire de pause ?


time free-time {
weekly *        12:00-13:30
weekly *        16:00-16:30
weekly thu,fri  11:30-12:00
}

 

 

DNS dynamique avec Debian

Pour obtenir un DNS dynamique il faut 2 choses :

  • Se déclarer auprès d’un service de DNS Dynamique
  • Installer un demon sur son serveur

 

Le service

J’ai opté pour freedns.afraid.org  .

Créez un compte et ajouter un sous-domaine (rien de compliqué)

Le démon

apt-get install inadyn

inadyn supporte de nombreux services :

  • http://www.dyndns.org
  • http://freedns.afraid.org
  • http://zoneedit.com
  • http://www.no-ip.com
  • http://www.easydns.com
  • http://www.tzo.com
  • http://www.3322.org
  • http://www.dnsomatic.com
  • http://www.tunnelbroker.net
  • http://dns.he.net/
  • http://www.dynsip.org
  • http://www.sitelutions.com
  • http://www.dnsexit.com
  • http://www.changeip.com

Le paramétrer (/etc/inadyn.conf)


# Service provider
# Please see inadyn(8) for a complete list of providers
system default@freedns.afraid.org


# Your username
username monusername

# Your password
password monpassword

# Your hostname. This option can appear multiple times
alias monsousdomaine.mooo.com

A par le « system » rien à expliquer.

Pour system vous trouverez dans le man la valeur correspondant à votre service.

Reste à passer inadyn en demon (/etc/default/inadyn)


...

# Set to "yes" if inadyn should run in daemon mode
# If this is changed to "yes", RUN_IPUP must be set to "no".
RUN_DAEMON="yes"

...

service inadyn restart

service inadyn status   -> pour véirfier que le service a bien démarré

Plus qu’à suivre les logs pour valider (update toute les 300s par défaut) que le service update bien votre IP.

tail -f /var/log/inadyn/inadyn.log


Tue Dec 29 16:39:26 2015: Will retry again in 300 sec...
Tue Dec 29 16:44:26 2015: .
Tue Dec 29 16:44:27 2015: Checking for IP# change, connecting to checkip.dyndns.org(91.198.22.70)
Tue Dec 29 16:44:35 2015: No IP# change detected, still at *********
Tue Dec 29 16:49:35 2015: .
Tue Dec 29 16:49:35 2015: Checking for IP# change, connecting to checkip.dyndns.org(216.146.43.70)
Tue Dec 29 16:49:43 2015: No IP# change detected, still at *********
Tue Dec 29 16:54:43 2015: .
Tue Dec 29 16:54:43 2015: Checking for IP# change, connecting to checkip.dyndns.org(91.198.22.70)
Tue Dec 29 16:54:59 2015: No IP# change detected, still at **********

 

 

 

 

 

 

Accéder à SSH via HTTPS (port 443)

Le grand classique : votre client est OK pour exposer le port 443 car il en a besoin pour accéder à sa WebApp mais impossible de vous ouvrir le port 22 (raisons multiples : « on peut pas », « SSH c’est quoi ? » …) pour accéder au serveur.

Grâce à ShellInABox et au mode proxy d’Apache l’on va pouvoir « mapper » un « SSH Web » à une URL de votre site Web et ainsi accéder en SSH – via HTTPS –  au serveur via un simple navigateur web .

Source image : https://github.com/shellinabox/shellinabox


Maquette (Debian)

Activation des modules Apache de gestion du SSL et Proxy


a2enmod ssl
a2enmod proxy
a2enmod proxy_http

Sur Debian (en tout cas sur la Raspbian utilisé pour ce test) il existe déjà un fichier de configuration valide (avec un certificat auto-signé).

/etc/apache2/sites-available/default-ssl.conf

...
# SSL Engine Switch:
# Enable/Disable SSL for this virtual host.
SSLEngine on
# A self-signed (snakeoil) certificate can be created by installing
# the ssl-cert package. See
# /usr/share/doc/apache2/README.Debian.gz for more info.
# If both key and certificate are stored in the same file, only the
# SSLCertificateFile directive is needed.
SSLCertificateFile /etc/ssl/certs/ssl-cert-snakeoil.pem
SSLCertificateKeyFile /etc/ssl/private/ssl-cert-snakeoil.key

...

On active ce host


a2ensite default-ssl

 

On ajoute le « mapping » entre l’URL /shell et ShellInABox

[Avant] /etc/apache2/sites-available/default-ssl.conf


        </VirtualHost>

</IfModule>

 

[Après] /etc/apache2/sites-available/default-ssl.conf


        </VirtualHost>

<Location /shell>
ProxyPass http://localhost:4200/
</Location>
</IfModule>

 

On re-démarre les services


service shellinabox restart

service apache2 restart

 

Vous pouvez à présent accéder à votre SSH via l’adresse https://[votreIP]/shell


Attention : ShelInABox est encore en écoute sur son port. Pour limiter l’accès au seul port 443 il faut modifier la configuration de ShellInABox afin  de limiter son écoute au localhost.

/etc/default/shellinabox


...
SHELLINABOX_ARGS="--localhost-only"

...