[TUTO] Antenne BLEA sur NAS Synology : Docker

[Fredje_B]

Merci Guirem pour ces éclaircissement, j'avais en effet le problème avec la création des utilisateurs qui ne voulait pas fonctionner correctement. Tes manipulations ont réglés le problème!

Par contre, pas moyen de me connecter en SSH au container...après m'être connecté sur le container avec la commande "docker exec -it RelayBT bash", je lance la commande "ssh -p 22000 pluginblea@localhost" et après avoir encodé le mot de passe, je suis directement éjecté avec les retours suivant : "Connection to localhost closed by remote host. Connection to localhost closed."

Dans Jeedom, j'ai configuré une nouvelle antenne avec l'IP de mon NAS, le port 22000, le nom et le mot de passe de l'utilisateur pluginblea et lorsque je clique sur "Envoyez les fichiers", j'obtiens une error "500 : HTTP/2.0 500"

Quelqu'un a t'il déjà eu le même problème?

[guirem]

Bonsoir,

- Essaie avec l'IP du nas plutôt que 'localhost'.
- Essaie avec un port inférieur à 220000, il me semble que le maximum pour un port est autour de 65000

[Fredje_B]

Bonjour Guirem,

Une nouvelle fois merci pour ta réaction....hélas, j'avais déjà essayé avec l'IP du NAS et le résultat est le même. Mon port est 22.000 donc bien inférieur au 65.000 autorisés.

Je pense qu'il s'agit d'un problème de paramètre du serveur ssh dans la machine virtuelle...Car l'authentification se passe correctement (si je tape un mauvais mot de passe, je suis bien recalé, le bon mot de passe passe à l'étape suivante où la connexion est interrompue par le service).

Autre chose qui me fait pencher pour un mauvais paramètre du service ssh, c'est qu'une connexion SFTP fonctionne sans aucun soucis!

Je joins à tout hasard mon ficher /etc/ssh/sshd_config, si une âme charitable voulait bien le comparer au siens et m'indiquer les différences?

# $OpenBSD: sshd_config,v 1.100 2016/08/15 12:32:04 naddy Exp $

# This is the sshd server system-wide configuration file. See
# sshd_config(5) for more information.

# This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin

# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented. Uncommented options override the
# default value.

Port 22000
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::

#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_ecdsa_key
#HostKey /etc/ssh/ssh_host_ed25519_key

# Ciphers and keying
#RekeyLimit default none

# Logging
#SyslogFacility AUTH
#LogLevel INFO

# Authentication:

#LoginGraceTime 2m
#PermitRootLogin prohibit-password
#StrictModes yes
#MaxAuthTries 6
#MaxSessions 10

#PubkeyAuthentication yes

# Expect .ssh/authorized_keys2 to be disregarded by default in future.
#AuthorizedKeysFile .ssh/authorized_keys .ssh/authorized_keys2

#AuthorizedPrincipalsFile none

#AuthorizedKeysCommand none
#AuthorizedKeysCommandUser nobody

# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
#HostbasedAuthentication no
# Change to yes if you don't trust ~/.ssh/known_hosts for
# HostbasedAuthentication
#IgnoreUserKnownHosts no
# Don't read the user's ~/.rhosts and ~/.shosts files
#IgnoreRhosts yes

# To disable tunneled clear text passwords, change to no here!
#PasswordAuthentication yes
#PermitEmptyPasswords no

# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication no

# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#KerberosGetAFSToken no

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes
#GSSAPIStrictAcceptorCheck yes
#GSSAPIKeyExchange no

# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication. Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
#UsePAM yes

#AllowAgentForwarding yes
#AllowTcpForwarding yes
#GatewayPorts no
X11Forwarding yes
#X11DisplayOffset 10
#X11UseLocalhost yes
#PermitTTY yes
PrintMotd no
#PrintLastLog yes
#TCPKeepAlive yes
#UseLogin no
#UsePrivilegeSeparation sandbox
#PermitUserEnvironment no
#Compression delayed
#ClientAliveInterval 0
#ClientAliveCountMax 3
#UseDNS no
#PidFile /var/run/sshd.pid
#MaxStartups 10:30:100
#PermitTunnel no
#ChrootDirectory none
#VersionAddendum none

# no default banner path
#Banner none

# Allow client to pass locale environment variables
AcceptEnv LANG LC_*

# override default of no subsystems
Subsystem sftp /usr/lib/openssh/sftp-server

# Example of overriding settings on a per-user basis
#Match User anoncvs
# X11Forwarding no
# AllowTcpForwarding no
# PermitTTY no
# ForceCommand cvs server

[Fredje_B]

Avec un verbose lors de la connexion ssh, on voit bien que l'authentification se fait correctement via mot de passe, c'est ensuite que ca se gâte...vais voir du coté du shell autorisé lors du login ssh...

OpenSSH_7.4p1 Debian-10+deb9u1, OpenSSL 1.0.2l 25 May 2017
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to 192.168.0.81 [192.168.0.81] port 22000.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_rsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.4p1 Debian-10+deb9u1
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.4p1 Debian-10+deb9u1
debug1: match: OpenSSH_7.4p1 Debian-10+deb9u1 pat OpenSSH* compat 0x04000000
debug1: Authenticating to 192.168.0.81:22000 as 'pluginblea:pluginblea'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:ESoB3xxY3OaA+qtiaGcpJStoVGUBIdKKK7Vp+sN5WKc
debug1: Host '[192.168.0.81]:22000' is known and matches the ECDSA host key.
debug1: Found key in /root/.ssh/known_hosts:2
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,ssh-rsa,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Trying private key: /root/.ssh/id_rsa
debug1: Trying private key: /root/.ssh/id_dsa
debug1: Trying private key: /root/.ssh/id_ecdsa
debug1: Trying private key: /root/.ssh/id_ed25519
debug1: Next authentication method: keyboard-interactive
Password:
debug1: Authentication succeeded (keyboard-interactive).
Authenticated to 192.168.0.81 ([192.168.0.81]:22000).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: pledge: network
debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0
debug1: Sending environment.
debug1: channel 0: free: client-session, nchannels 1
debug1: fd 1 clearing O_NONBLOCK
Connection to 192.168.0.81 closed by remote host.
Connection to 192.168.0.81 closed.
Transferred: sent 2288, received 2168 bytes, in 0.1 seconds
Bytes per second: sent 42649.1, received 40412.3
debug1: Exit status -1

[guirem]

Salut,

Ca marche si tu fais :
ssh -p 22000 pluginblea@localhost 'echo je suis la'

Si oui c'est probablement un pb de .bashrc ou .profile la racine /home/pluginblea
En fait tu n'a pas besoin de te connecter en ssh car c'est ssh en mode interactif qui n'a pas l'air de fonctionner.
Connecte toi en root pour faire la dernière étape (sudo apt-get install -y bluetooth bluez)
Ensuite les étapes à partir de jeedom fonctionneront normalement

[Fredje_B]

Salut Guirem,

Oui en passant des commandes cela fonctionne, je peux même démarrer un bash évidement. J'arrête donc de chercher une solution pour cela puisque tu me dit que c'est pas obligatoire d'avoir un accès interactif. Merci pour l'info au passage.

Par contre en Jeedom je reçois l'erreur "500: HTTP/2.0 500" dès que j'essaie d'envoyer les fichiers ou si je clique sur n'importe quel bouton de l'écran antenne. De plus, je reçois aussi sur le cron15 l'erreur "Call to undefined function ssh2_connect()"

En fait, je pense que j'ai bousillé le PHP du container dans lequel tourne Jeedom...j'entend par là que j'avais un problème de Cron qui était du à au fait que Jeedom appelait une version de PHP qui n'existait plus ("/usr/bin/php")...j'ai du changer cela en "php" tout court...maintenant, je vois que la fonction "ssh2_connect()" est censée être une fonction standard de PHP mais celle-ci n'est pas reconnue...en fait, avant de parcourir ce fil, j'avais essayé d'installer les fonctions USB sur le container de Jeedom et j'ai installé pas mal de paquets Linux, je pense que mon problème actuel vient de là...

Bref, pour être sur, je vais recréer un docker et en profiter pour installer la dernière version de Debian, réinstaller Jeedom et faire une restauration ensuite...

[gpga]

Bonjour

je viens d'installer une antenne Blea sur un Syno, j'ai suivi scrupuleusement le protocole et je suis arrivé jusqu'au lancement des dépendances sur le plugin jeedom.
Tout semble s'être bien passé, par contre je n'arrive pas à lancer l'antenne

J'ai un message d'erreur dans le log

Error: importing module from jeedom folder

Comment finaliser le démarrage de mon antenne,

Merci pour votre aide

[Fredje_B]

@gpga, peux tu passer le module Blea en mode début et relancer l'antenne? Ensuite poster le résultat ici

[SkiZoSnaKe]

Bonsoir,

J'avais un problème sur mon Synology pour accèder via SSH au conteneur (erreur: "connection refused") car il manquait le mapping du port dans la ligne de commande de départ ^^
Voici celle que j'ai utilisée:

Code : Tout sélectionner

sudo docker run --name RelayBT-Docker --restart=always --net=bridge -p 9122:22 --privileged -itd  -v /dev/bus/usb:/dev/bus/usb itscaro/debian-ssh:latest

J'utilise le port 9122 sur mon Synology afin de me connecter au port 22 du conteneur.

En espérant que cela puisse vous servir

[SkiZoSnaKe]

Bonsoir,

J'ai la même erreur que gpga, à savoir:

Code : Tout sélectionner

Error: importing module from jeedom folder

J'ai l'impression que mon dongle BT n'est pas reconnu sous le conteneur alors que sous DSM aucun problème car lorsque je lance la commande "hciconfig" dans le conteneur j'ai l'erreur suivante:

Code : Tout sélectionner

Can't open HCI socket.: Address family not supported by protocol

Une idée?

Merci
Bonne soirée

[Fredje_B]

Bonsoir,

J'avais un problème sur mon Synology pour accèder via SSH au conteneur (erreur: "connection refused") car il manquait le mapping du port dans la ligne de commande de départ ^^
Voici celle que j'ai utilisée:

Code : Tout sélectionner

sudo docker run --name RelayBT-Docker --restart=always --net=bridge -p 9122:22 --privileged -itd  -v /dev/bus/usb:/dev/bus/usb itscaro/debian-ssh:latest

J'utilise le port 9122 sur mon Synology afin de me connecter au port 22 du conteneur.

En espérant que cela puisse vous servir

Ça fonctionne aussi en mode bridge si je comprend bien? Je m’étais entêté à essayer de le faire fonctionner en mode Host...je vais passer le container en Host et voir ce que ça donne.

[Fredje_B]

Bonsoir,

J'ai la même erreur que gpga, à savoir:

Code : Tout sélectionner

Error: importing module from jeedom folder

J'ai l'impression que mon dongle BT n'est pas reconnu sous le conteneur alors que sous DSM aucun problème car lorsque je lance la commande "hciconfig" dans le conteneur j'ai l'erreur suivante:

Code : Tout sélectionner

Can't open HCI socket.: Address family not supported by protocol

Une idée?

Merci
Bonne soirée

Qu’est ce que sa donne avec un lsusb -l ?

[Fredje_B]

Bonsoir,

J'ai la même erreur que gpga, à savoir:

Code : Tout sélectionner

Error: importing module from jeedom folder

J'ai l'impression que mon dongle BT n'est pas reconnu sous le conteneur alors que sous DSM aucun problème car lorsque je lance la commande "hciconfig" dans le conteneur j'ai l'erreur suivante:

Code : Tout sélectionner

Can't open HCI socket.: Address family not supported by protocol

Une idée?

Merci
Bonne soirée

Qu’est ce que sa donne avec un lsusb -l ?

[SkiZoSnaKe]

Qu’est ce que sa donne avec un lsusb -l ?

J'ai le résultat suivant:

Code : Tout sélectionner

Bus 001 Device 003: ID f400:f400
Bus 001 Device 002: ID 8087:07db Intel Corp.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 002 Device 003: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)
Bus 002 Device 002: ID 0658:0200 Sigma Designs, Inc.
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Le dongle apparaît pourtant bien:

Code : Tout sélectionner

Bus 002 Device 003: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)

[Fredje_B]

En fait, cette erreur est très certainement due au fait que vous exécutez votre container en mode Bridge au lieu du mode host (--net=host).

Je viens d'essayer un container en mode bridge, j'arrive à me connecter en ssh sans problème mais j'obtiens la même erreur que vous...Erreur que je n'obtiens pas en mode host mais je n'arrive pas à me connecter en SSH! Sans connexion SSH, le plugin n'arrive pas à se connecter, bref suis complètement bloqué

Il faut absolument faire tourner le container en mode host afin qu'il puisse se connecter directement au matériel bluetooth du Synology.

[SkiZoSnaKe]

En fait, cette erreur est très certainement due au fait que vous exécutez votre container en mode Bridge au lieu du mode host (--net=host).

Je viens d'essayer un container en mode bridge, j'arrive à me connecter en ssh sans problème mais j'obtiens la même erreur que vous...Erreur que je n'obtiens pas en mode host mais je n'arrive pas à me connecter en SSH! Sans connexion SSH, le plugin n'arrive pas à se connecter, bref suis complètement bloqué

Il faut absolument faire tourner le container en mode host afin qu'il puisse se connecter directement au matériel bluetooth du Synology.

Ok, merci dans ce cas je vais tester en mode host (j'avais changé lorsque j'avais les problèmes d'accès SSH pour voir si cela venait de là).

[laaubert]

Bonjour,

Je suis bloqué à l'étape ou je dois faire un ssh sur le container. J'ai bien des ports SSH différents pour le Syno et le Debian.

Quand j'essaye de me connecter en utilisant le compte pluginblea, je suis bien authentifié mais le container ferme la session juste après.

Côté client en utilisant l'option -vvv de la commande ssh je vois les logs suivants:

Code : Tout sélectionner

debug1: Next authentication method: password
pluginblea@10.0.2.10's password: 
debug2: we sent a password packet, wait for reply
debug1: Authentication succeeded (password).       <-------
Authenticated to 10.0.2.10 ([10.0.2.10]:223).
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0
debug2: callback start
debug2: fd 3 setting TCP_NODELAY
debug3: ssh_packet_set_tos: set IP_TOS 0x10
debug2: client_session2_setup: id 0
debug2: channel 0: request pty-req confirm 1
debug1: Sending environment.
debug3: Ignored env TERM_PROGRAM
debug3: Ignored env SHELL
debug3: Ignored env TERM
debug3: Ignored env TMPDIR
debug3: Ignored env Apple_PubSub_Socket_Render
debug3: Ignored env TERM_PROGRAM_VERSION
debug3: Ignored env TERM_SESSION_ID
debug3: Ignored env USER
debug3: Ignored env SSH_AUTH_SOCK
debug3: Ignored env __CF_USER_TEXT_ENCODING
debug3: Ignored env PATH
debug3: Ignored env PWD
debug1: Sending env LANG = en_CA.UTF-8
debug2: channel 0: request env confirm 0
debug3: Ignored env XPC_FLAGS
debug3: Ignored env XPC_SERVICE_NAME
debug3: Ignored env SHLVL
debug3: Ignored env HOME
debug3: Ignored env LOGNAME
debug3: Ignored env ARCHFLAGS
debug3: Ignored env DISPLAY
debug3: Ignored env _
debug2: channel 0: request shell confirm 1
debug2: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug1: channel 0: free: client-session, nchannels 1
debug3: channel 0: status: The following connections are open:
  #0 client-session (t4 r0 i0/0 o0/0 fd 5/6 cc -1)

Connection to 10.0.2.10 closed by remote host.          <-----------
Connection to 10.0.2.10 closed.
Transferred: sent 2764, received 1948 bytes, in 0.0 seconds
Bytes per second: sent 197077.0, received 138895.1
debug1: Exit status -1

Côté container, j'ai regardé le contenu de /var/log mais je ne vois pas grand chose qui pourrait m'indiquer la cause du problème:

Code : Tout sélectionner

root@NAS:/# ls -l /var/log
total 100
-rw-r--r-- 1 root root   1605 Feb  1 08:37 alternatives.log
drwxr-xr-x 1 root root     60 Feb  1 08:37 apt
-rw-rw---- 1 root utmp   1920 Feb  1 08:53 btmp
-rw-r--r-- 1 root root  40284 Feb  1 08:37 dpkg.log
-rw-r--r-- 1 root root  32032 Feb  1 08:41 faillog
-rw-rw-r-- 1 root utmp 292292 Feb  1 09:20 lastlog
-rw-rw-r-- 1 root utmp   6144 Feb  1 09:20 wtmp

Seul les fichiers lastlog et wtmp sont mis à jour à chaque connection me confirmant bien que j'étais connecté.

Existe t'il d'autre logs qui pourraient me mettre sur la piste ?

Merci de votre aide.

[Fredje_B]

@Laaubert, je ne te serais pas de grande aide car j'ai eu exactement le même problème que toi et n'ai jamais trouvé la solution.

J'ai fini par installer le dongle USB sur un Pi que j'utilise comme porte de sortie VPN (il tourne H24 et sous Debian)...c'est installé en 5 minutes (faut un peu bidouiller le pi pour faire reconnaitre la clé) et ca tourne du feu de Dieu...

[laaubert]

Salut Fredje_B,

J'ai maintenant vu ton post dans ce thread . La commande donnée par Guirem fonctionne aussi pour moi donc j'essaierai de continuer les étapes dès que j'aurai reçu mon dongle et on verra.

Merci

[laaubert]

Je suis bloqué comme Fredje_B.

SSH ne fonctionne pas et Jeedom n'arrive pas à envoyer les fichiers même si il me dit que l'opération a réussi...

J'ai trouvé cette commande en cherchant sur le web qui me permet de me connecter de manière limitée et me donne un message d'erreur:

Code : Tout sélectionner

root@NAS:/# ssh pluginblea@10.0.2.10 -p 223 /bin/bash -xi
pluginblea@10.0.2.10's password:
bash: cannot set terminal process group (-1): Inappropriate ioctl for device
bash: no job control in this shell
+ '[' -z '\s-\v\$ ' ']'
+ shopt -s checkwinsize
+ '[' -z '' ']'
+ '[' -r /etc/debian_chroot ']'
+ PS1='${debian_chroot:+($debian_chroot)}\u@\h:\w\$ '
+ '[' -x /usr/lib/command-not-found -o -x /usr/share/command-not-found/command-not-found ']'
+ case $- in
+ HISTCONTROL=ignoreboth
+ shopt -s histappend
+ HISTSIZE=1000
+ HISTFILESIZE=2000
+ shopt -s checkwinsize
+ '[' -z '' ']'
+ '[' -r /etc/debian_chroot ']'
+ case "$TERM" in
+ '[' -n '' ']'
+ '[' '' = yes ']'
+ PS1='${debian_chroot:+($debian_chroot)}\u@\h:\w\$ '
+ unset color_prompt force_color_prompt
+ case "$TERM" in
+ '[' -x /usr/bin/dircolors ']'
+ test -r /home/pluginblea/.dircolors
++ dircolors -b
+ eval 'LS_COLORS='\'''\'';
export LS_COLORS'
++ LS_COLORS=
++ export LS_COLORS
+ alias 'ls=ls --color=auto'
+ '[' -f /home/pluginblea/.bash_aliases ']'
+ shopt -oq posix
+ '[' -f /usr/share/bash-completion/bash_completion ']'
+ '[' -f /etc/bash_completion ']'
pluginblea@NAS:~$

Malgré mes recherches je n'ai pas réussi à comprendre d'où cette erreur pourrait provenir. Je ne suis pas assez expert en système Linux.

Est-ce que quelqu'un aurait une idée ?

Merci d'avance !!