Classement

Bonjour a tous ! Ci-dessous un petit tuto pour pouvoir securiser sa connexion ssh sur un NAS synology avec authy Afin de pouvoir faire fonctionner votre authentification double facteur sur il vous faudra avoir installé bootstrap (IPKG) créé un compte authy créé une application authy-ssh : 9c6772a078870c470de0a32a1865743c dans cette exemple Installation des paquets IPKG nécessaire Commencez par vous loger en root (root et pas admin) sur votre NAS via votre client ssh préféré, puis installer le paquet ipkg bash ipkg install bash Téléchargement et configuration d’authy-ssh Une fois que vous avez installe bash, téléchargez authy-ssh cd /tmp curl -O 'https://raw.githubusercontent.com/authy/authy-ssh/master/authy-ssh' Si curl vous retourne une erreur “curl: (1) Protocol ‘https not supported or disabled in libcurl” utilisez la commande suivante curl -O 'https://raw.githubusercontent.com/authy/authy-ssh/master/authy-ssh' --insecure Maintenant éditez la configuration du script nano authy-ssh Remplacez #!/usr/bin/env bash (1ere ligne) par #!/opt/bin/bash et ajoutez avant export TERM=”xterm-256color” export PATH=$PATH:/opt/bin Voici a quoi devrait ressembler les 13 premières lignes du script authy-ssh une fois ces deux modifications terminées #!/opt/bin/bash VERSION="1.4" AUTHY_URL="https://api.authy.com" APP_ROOT=`dirname $0` CONFIG_FILE="$APP_ROOT/authy-ssh.conf" UPSTREAM_URL="https://raw.github.com/authy/authy-ssh/master/authy-ssh" READ_TIMEOUT=60 OK=0 FAIL=1 export PATH=$PATH:/opt/bin export TERM="xterm-256color" Rendez le script exécutable et lancez l’installation chmod +x authy-ssh ./authy-ssh install /usr/local/bin/ L’installation devrait se passer correctement DS_Test> ./authy-ssh install /usr/local/bin Copying ./authy-ssh to /usr/local/bin/authy-ssh... Setting up permissions... Enter the Authy API key: 9c6772a078870c470de0a32a1865743c Default action when api.authy.com cannot be contacted: 1. Disable two factor authentication until api.authy.com is back 2. Don't allow logins until api.authy.com is back type 1 or 2 to select the option: 2 Generating initial config on /usr/local/bin/authy-ssh.conf... Adding 'ForceCommand /usr/local/bin/authy-ssh login' to /etc/ssh/sshd_config MAKE SURE YOU DO NOT MOVE/REMOVE /usr/local/bin/authy-ssh BEFORE UNINSTALLING AUTHY SSH To enable two-factor authentication on your account type the following command: sudo /usr/local/bin/authy-ssh enable root <your-email> <your-numeric-country-code> <your-cellphone> Example: sudo ./authy-ssh enable root myuser@example.com 1 401-390-9987 To enable two-factor authentication on user account type: sudo /usr/local/bin/authy-ssh enable <local-username> <user-email> <user-cellphone-country-code> <user-cellphone> To uninstall Authy SSH type: sudo /usr/local/bin/authy-ssh uninstall Restart the SSH server to apply changes Configuration d’authy-ssh pour les utilisateurs admin et root L’installation d’une authentification double facteur pour un utilisateur se fait sur le modèle suivant /usr/local/bin/authy-ssh enable <utilisateur> <email> <code pays> <numero-de-telephone> Dans notre cas pour admin (commencez par l’utilisateur admin, si tout fonctionne correctement vous pourrez implémenter cette solution pour root) /usr/local/bin/authy-ssh enable admin chuck@norris.com 33 666666666 Authy-ssh se configure alors DS_Test> /usr/local/bin/authy-ssh enable admin chuck@norris.com 33 666666666 Username: admin Cellphone: (+33) 666666666 Email: chuck@norris.com Do you want to enable this user? (y/n) y User was registered DS_Test> authy-ssh lors de la configuration ne modifie le fichier de configuration ssh que pour l’utilisateur root, puisque nous nous occupons d’admin il faudra que vous le fassiez vous même nano /etc/ssh/sshd_config Une fois le fichier de configuration de ssh ouvert rendez vous a la fin du fichier et vous verrez qu’authy a ajoute la ligne ForceCommand /usr/local/bin/authy-ssh login au block Match User root # Example of overriding settings on a per-user basis Match User root # X11Forwarding no AllowTcpForwarding yes # ForceCommand cvs server ForceCommand /usr/local/bin/authy-ssh login Créez le meme block pour l’utilisateur admin, de sorte que vous ayez # Example of overriding settings on a per-user basis Match User root # X11Forwarding no AllowTcpForwarding yes # ForceCommand cvs server ForceCommand /usr/local/bin/authy-ssh login Match User admin ForceCommand /usr/local/bin/authy-ssh login Redémarrez le service ssh killall sshd Reconnectez vous en ssh cette fois en avec l’user admin, voici ce que vous devriez voir login as : admin admin@192.168.1.190's password: Authy Token (type 'sms' to request a SMS token): Si et seulement si tout fonctionne lors de la connection ssh admin vous pouvez configurer authy sur root, reconnectez vous en root et lancez le script de configuration /usr/local/bin/authy-ssh enable root chuck@norris.com 33 666666666 Source

Oui mais surtout la vraie bonne question serait de savoir pourquoi vouloir du https pour de simples photos ? Ou est l'intérêt ?

Oui les symptômes étaient assez flagrants. Echnage le disque HS contre un autre et tout devrait rentrer dans l'ordre.

Pour commencer je dirais comme Pluton : lis d'abord la notice d'installation calmement, plusieurs fois à tête reposée. Ensuite à tout hasard faire un double reset du syno (premier appuis maintenu du poussoir reset jusqu'au bip suivi 4 ou 5 secondes après d'un second appui maintenu. Arrêt du syno et sortie des deux disques. Le formater complètement sur ton ordi par exemple. Ne remettre qu'un seul disque et recommencer la procédure d'installation exactement comme indiquée sur la notice. Si ça marche et que l'installation se termine bien, installer le second disque et le configurer de la façon que tu désires. Soit "SHR sur un seul volume avec protection des données" ce qui équivaut au RAID1. Soit "SHR sur volumes séparés sans protection des données" ce qui correspond à du basic. La notion "avec (ou sans) protection des données" semble être du traduit taiwanais direct...), les données ne sont pas plus protégées dans un cas comme dans l'autre. REGLE NUMERO 1 : ne jamais entamer une nouvelle opération tant que la précédente n'est pas terminée correctement. De même ne jamais tenter une "mise à jour pour résoudre le problème" si quelque chose cafouille en cours d'installation. On ne doit faire une mAJ que sur un syno parfaitement opérationnel et ne présentant aucun dysfonctionnement. Sous linux je ne sais pas mais sous windows il est recommandé de désactiver le parefeu windows (qui ne sert à rien puisqu'il y en a un dans la box) et souvent aussi de désactiver l'antivirus le temps de l'installation.

Le cable lui même je ne pense pas. Certains synos ont un bloc d'alimentation externe. Je pensais à ces modèles là. Mais si l'alim est intégrée au syno on revient à un syno en panne,

Ton histoire ressemble furieusement à une alimentation déficiente. Par hasard tu n'aurais pas un copain qui aurait le même syno et qui pourrait te prêter son alim ? Sinon faire une demande chez synology. En principe en anglais mais préciser que tu est en France. Ils ont parfois des francophones. Ils sont réactifs (sous 4 / 5 jours ouvrables quand même)

Non c'est la bonne méthode, elle est identique à celle proposée dans l'interface. Fais le test suivant : retire (et repère l'ordre) les disques et essaye de rallumer le syno. S'il se rallume, bien sûr il ne sera pas opérationnel et la led status sera orange clignotante. Sinon si il refuse de se rallumer, il est en panne. Mais si le syno se rallume c'est qu'un des disques crée un dysfonctionnement. Recommencer l'opération en remettant les disques un par un pour définir le disque à problèmes.