Bonjour à tous, Suite à un déménagement (perso), et quelques ajustement technique dans mon nouveau chez moi temporaire (pas de ligne téléphonique donc je passe par une solution routeur 4G) j'ai voulu améliorer mon système de rapatriement de fichier entre ma seedbox (Dedibox LT 2015 chez Online.net en Debian 8 tournant depuis longtemps - install script d'ex-rat - pas de docker) et mon server local (un petit server lui aussi en débian 8 headless pour plex). En gros tout est parti de la volonté de mettre en place un script avec du rsync entre mes deux servers sur certains dossiers. Je me renseigne, je vois que c'est possible mais à condition de passer par une authentification SSH par clef (pour éviter de taper le MdP à chaque fois) du coup je procède de la sorte : J'ai généré la clef public et privée sur le server local copié la publique dans ~/.ssh/authorized_keys sur ma dédibox redémarré ssh J'ai fait une tentative de connexion par clef via fichier de configuration (en indiquant IdentityFile et le chemin de ma clef publique). La Dédibox m'a demandé un mdp, j'ai pensé que je m'étais loupé, donc j'ai abort l'authentification (Ctrl C). Sur la dédibox j'ai supprimé le fichier authorized_keys mais j'ai oublié de redémarrer ssh j'ai fais une tentative de copie de la clef depuis le server local en utilisant la commande ssh-copy-id -i ~/.ssh/id_rsa.pub user@mon_serveur et là plantage, le serveur c'est mis à ralentir, puis freeze des applications, j'ai donc lancé un hard reboot depuis la console online.net Depuis le redémarrage : - seul l'application Plex fonctionne - Les pages webs ne s'affichent plus - depuis mon server local ou un autre ordinateur, impossible de me connecter en SSH j'ai droit à un connection timed out. J'ai contacté l'assistance de online.net qui m'a simplement conseillé de mettre (ce qui est actuellement le cas) le server en mode Secours. Apparemment d'après le diagnostic, l'accès est dans ce cas possible, mais j'avouerai que je ne sais pas trop quoi chercher pour réparer. nmap Adresse_IP Starting Nmap 7.60 ( https://nmap.org ) at 2018-10-26 00:10 CEST Nmap scan report for gormboxplex.domaine (Adresse_IP) Host is up (0.0032s latency). Not shown: 997 closed ports PORT STATE SERVICE 22/tcp open ssh 80/tcp open http 6666/tcp open irc Ce qui est vraiment étrange c'est que d'un coup d'un seul, seul plex fonctionnait (j'avais des stream pdt et après le premier reboot) mais tout ce qui avait une interface web était planté. Je ne serais pas contre une aide de votre part, parce que là, je suis un peu comme une poule devant un couteau.

Plus d'accès ssh à ma Seedbox : Need Help!

Ce site est optimisé pour être consulté depuis un navigateur moderne dans lequel JavaScript est activé.

Plus d'accès ssh à ma Seedbox : Need Help!

gormson

Bonjour à tous,

Suite à un déménagement (perso), et quelques ajustement technique dans mon nouveau chez moi temporaire (pas de ligne téléphonique donc je passe par une solution routeur 4G) j'ai voulu améliorer mon système de rapatriement de fichier entre ma seedbox (Dedibox LT 2015 chez Online.net en Debian 8 tournant depuis longtemps - install script d'ex-rat - pas de docker) et mon server local (un petit server lui aussi en débian 8 headless pour plex).

En gros tout est parti de la volonté de mettre en place un script avec du rsync entre mes deux servers sur certains dossiers. Je me renseigne, je vois que c'est possible mais à condition de passer par une authentification SSH par clef (pour éviter de taper le MdP à chaque fois) du coup je procède de la sorte :

J'ai généré la clef public et privée sur le server local
copié la publique dans ~/.ssh/authorized_keys sur ma dédibox
redémarré ssh
J'ai fait une tentative de connexion par clef via fichier de configuration (en indiquant IdentityFile et le chemin de ma clef publique).
La Dédibox m'a demandé un mdp, j'ai pensé que je m'étais loupé, donc j'ai abort l'authentification (Ctrl C).
Sur la dédibox j'ai supprimé le fichier authorized_keys mais j'ai oublié de redémarrer ssh
j'ai fais une tentative de copie de la clef depuis le server local en utilisant la commande ssh-copy-id -i ~/.ssh/id_rsa.pub user@mon_serveur
et là plantage, le serveur c'est mis à ralentir, puis freeze des applications, j'ai donc lancé un hard reboot depuis la console online.net

Depuis le redémarrage :
- seul l'application Plex fonctionne
- Les pages webs ne s'affichent plus
- depuis mon server local ou un autre ordinateur, impossible de me connecter en SSH j'ai droit à un connection timed out.

J'ai contacté l'assistance de online.net qui m'a simplement conseillé de mettre (ce qui est actuellement le cas) le server en mode Secours. Apparemment d'après le diagnostic, l'accès est dans ce cas possible, mais j'avouerai que je ne sais pas trop quoi chercher pour réparer.

nmap Adresse_IP Starting Nmap 7.60 ( https://nmap.org ) at 2018-10-26 00:10
CEST Nmap scan report for gormboxplex.domaine (Adresse_IP)
Host is up (0.0032s latency).
Not shown: 997 closed ports
PORT STATE SERVICE
22/tcp open ssh
80/tcp open http
6666/tcp open irc

Ce qui est vraiment étrange c'est que d'un coup d'un seul, seul plex fonctionnait (j'avais des stream pdt et après le premier reboot) mais tout ce qui avait une interface web était planté.

Je ne serais pas contre une aide de votre part, parce que là, je suis un peu comme une poule devant un couteau.

spider1163

Salut,
cherches-tu COMMENT ou QUOI réparer ?

Quelques pistes pour le comment :
https://documentation.online.net/fr/dedicated-server/rescue/mount-partitions
https://documentation.online.net/fr/dedicated-server/rescue/configure-root-password

Pour le quoi : as-tu essayé d'inverser tes modifications ?

gormson

Bonjour,

Merci de ta réponse, pour le moment je n'ai rien touché, je ne veux pas faire plus de bêtises lol.
Donc c'est surtout le "quoi réparer" au vue de la quantité de modification que j'ai apporté... autant dire presque nulle.
Parce qu'à la rigueur sur la seedbox, je n'ai que viré (et non reboot sshd) le fichier de clef publique...
mais ce que je me dis c'est qu'au Hard Reboot, normalement le process ssh a redémarrer aussi donc devrait avoir corriger le problème...
C'est pour ça que je pige pas...

spider1163

On va regarder ton souci SSH avant d'analyser tes applications ralenties :

Aurai-tu Fail2ban d'installé ?
Ne te serai-tu pas fait bannir ?
As-tu testé de te connecter via une autre IP/VPN ?

Si le souci persiste :
As-tu modifié /etc/ssh/sshd_config ?
Inséré quelque chose comme ceci
PasswordAuthentication no ChallengeResponseAuthentication no ?
Repasse à yes sinon poste le contenu de ton fichier à la limite

gormson

Oui j'ai Fail2ban d'installé
pour retester il faudrait que je sortes du mode secours.
j'avais tester uniquement depuis mon poste Windows et mon serveur Debian local mais derrière mon IP de mon routeur 4G.

par contre quand ça merdait j'avais tenter aussi de faire un
nmap -p Port AdresseIP
Starting Nmap 6.47 ( http://nmap.org ) at 2018-10-26 00:05 CEST
Note: Host seems down. If it is really up, but blocking our ping probes, try -Pn
Nmap done: 1 IP address (0 hosts up) scanned in 3.21 seconds

comme si mon ssh n'était juste plus là, mais peut être est ce fail2ban...

Mais je n'avais pas modifie le sshd_condig de la sorte, j'avais laissé justement le PasswordAuthentication sur yes...
dès que je rentre je ferais les tests et posterai le tout ici 🙂

gormson

Bon après connexion en mode secours j'ai pu
- ajouter correctement la clef publique au fichier authorized_keys
- décommenter la ligne AuthorizedKeysFile dans le fichier sshd_config (que je n'avais pas fait car pas marqué dans le tuto que j'ai suivi... 🙁)

Par contre j'ai un doute, j'arrive à me connecter en utilisant ma clef mais dans le fichier sshd_config j'ai le paramètre PasswordAuthentication en commentaire donc ignoré.

Mais lors de ma connexion, j'ai, malgré l'authentification par clef, dû taper mon mot de passe...

Est ce normal?

MattProd

gormson le mot de passe c'est pas le passphrase de ta clé que tu tape ?

gormson

Arf alors la bonne question
l'invite est la même que pour le mot de passe du compte du coup comme j'ai fait un bon vieux passphrase = mdp du coup (oui je sais c'est pas bien), du coup je ne sais pas trop dire 🙁

MattProd

gormson parce qu'il me semble si a la création de la clé tu as entré une passphrase alors oui elle te la demandera toujours...
Si je me trompe que l'on me reprenne

Malakai

A la limite pour tester et voir qui demande le mot de passe (passphrase), tu peux utiliser ssh-agent (Linux) ou pageant (Windows).
Si apres avoir mis correctement en place ssh-agent/pageant, tu as toujours une demande de mot de passe, c'est que c'est le serveur ssh qui le demande.
Ou sinon, tu regeneres une cle sans mettre de passphrase, tu la copie sur le serveur et tu vire l'ancienne (apres restart de sshd et avant de fermer la fenetre ssh encore active, test la connexion avec la nouvelle cle, pour eviter de rester coince dehors).

gormson

Bon...

alors du coup je suis perdu, j'ai regénéré une clef depuis mon MacBook, toujours avec

ssh-keygen -t rsa

mais au moment de mettre la passphrase j'ai laissé vide.
De même que pour mon server local, j'ai modifié la clef pour retirer la passphrase.

Je retente une connexion, et toujours une invite de password, mais c'est bien le password du compte.

J'ai donc tenté de changer un paramètre dans ssh_config

PasswordAuthentication no

En me disant que du coup je n'aurais pas d'invite de MdP.
Et là j'ai droit au retour suivant:

user@domaine.tld: Permission denied (publickey).

du coup je pige vraiment pas.
j'ai lancé un ssh en mode -vvv

OpenSSH_7.7p1, LibreSSL 2.7.3
debug1: Reading configuration data /Users/user/.ssh/config
debug1: /Users/user/.ssh/config line 6: Applying options for Alias
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 48: Applying options for *
debug2: ssh_connect_direct: needpriv 0
debug1: Connecting to domaine.tld port XXX.
debug1: Connection established.
debug1: identity file /Users/user/.ssh/id_rsa.pub type 0
debug1: key_load_public: No such file or directory
debug1: identity file /Users/user/.ssh/id_rsa.pub-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_7.7
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.7p1 Debian-5+deb8u7
debug1: match: OpenSSH_6.7p1 Debian-5+deb8u7 pat OpenSSH* compat 0x04000000
debug3: fd 5 is O_NONBLOCK
debug1: Authenticating to domaine.tld:XXXX as 'user'
debug3: put_host_port: [domaine.tld]:XXXX
debug3: hostkeys_foreach: reading file "/Users/user/.ssh/known_hosts"
debug3: record_hostkey: found key type ECDSA in file /Users/user/.ssh/known_hosts:10
debug3: load_hostkeys: loaded 1 keys from [domaine.tld]:XXXX
debug3: order_hostkeyalgs: prefer hostkeyalgs: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521
debug3: send packet: type 20
debug1: SSH2_MSG_KEXINIT sent
debug3: receive packet: type 20
debug1: SSH2_MSG_KEXINIT received
debug2: local client KEXINIT proposal
debug2: KEX algorithms: curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1,ext-info-c
debug2: host key algorithms: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa
debug2: ciphers ctos: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com
debug2: ciphers stoc: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com
debug2: MACs ctos: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: compression ctos: none,zlib@openssh.com,zlib
debug2: compression stoc: none,zlib@openssh.com,zlib
debug2: languages ctos: 
debug2: languages stoc: 
debug2: first_kex_follows 0 
debug2: reserved 0 
debug2: peer server KEXINIT proposal
debug2: KEX algorithms: curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1
debug2: host key algorithms: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256,ssh-ed25519
debug2: ciphers ctos: aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com
debug2: ciphers stoc: aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com
debug2: MACs ctos: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: compression ctos: none,zlib@openssh.com
debug2: compression stoc: none,zlib@openssh.com
debug2: languages ctos: 
debug2: languages stoc: 
debug2: first_kex_follows 0 
debug2: reserved 0 
debug1: kex: algorithm: curve25519-sha256@libssh.org
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
debug3: send packet: type 30
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug3: receive packet: type 31
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:w4AEWVh43z7/ccZn08avRtHpa6aHYkP+ambWfFjB+5U
debug3: put_host_port: [IP]:XXXX
debug3: put_host_port: [domaine.tld]:XXX
debug3: hostkeys_foreach: reading file "/Users/user/.ssh/known_hosts"
debug3: record_hostkey: found key type ECDSA in file /Users/user/.ssh/known_hosts:10
debug3: load_hostkeys: loaded 1 keys from [domaine.tld]:XXXX
debug3: hostkeys_foreach: reading file "/Users/user/.ssh/known_hosts"
debug3: record_hostkey: found key type ECDSA in file /Users/user/.ssh/known_hosts:10
debug3: load_hostkeys: loaded 1 keys from [IP]:XXXX
debug1: Host '[domaine.tld]:XXX' is known and matches the ECDSA host key.
debug1: Found key in /user/JNeuu/.ssh/known_hosts:10
debug3: send packet: type 21
debug2: set_newkeys: mode 1
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug3: receive packet: type 21
debug1: SSH2_MSG_NEWKEYS received
debug2: set_newkeys: mode 0
debug1: rekey after 134217728 blocks
debug2: key: /Users/user/.ssh/id_rsa.pub (0x7fde75d06c80), explicit
debug3: send packet: type 5
debug3: receive packet: type 6
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug3: send packet: type 50
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey
debug3: start over, passed a different list publickey
debug3: preferred publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering public key: RSA SHA256:cUhOMGJGwX2KnztLqEnmoHGKOb+3Vaz4cUCkViX6i8o /Users/user/.ssh/id_rsa.pub
debug3: send_pubkey_test
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
rootgorm@gormbox.fr: Permission denied (publickey).

Je comprends pas 😢

jean-luc

gormson

Bonsoir,

As tu les bon droits sur le dossier .ssh et sur le fichier authorized_keys ?

Si user = root :

chown -R root:root /root/.ssh
chmod 700 /root/.ssh
chmod 600 /root/.ssh/authorized_keys

Si user = userx :

chown -R userx:userx /home/userx/.ssh
chmod 700 /home/userx/.ssh
chmod 600 /home/userx/.ssh/authorized_keys

gormson

Re 🙂

Bon j'ai modifié les droits comme écrit ci dessus et là... je pige encore moins
Sachant que j'ai ce fichier de config

Host Alias
  Hostname domaine.tld
  User le_user_qui_est_pas_root
  Port Le_Porc
  IdentityFile ~/.ssh/id_rsa.pub

j'ai au final cette réponse du server

Permissions 0644 for '/root/.ssh/id_rsa.pub' are too open.
It is recommended that your private key files are NOT accessible by others.
This private key will be ignored.
key_load_private_type: bad permissions

Bon déjà ça évolue 🙂

gormson

Bon on avance, j'ai appliqué les mêmes permissions que ci-dessus à la clef publique

chmod 600 /root/.ssh/id_rsa.pub

Bon par contre je pige pas la suite, pour changer :

Enter passphrase for key '/root/.ssh/id_rsa.pub'
le_user_qui_est_pas_root@domaine.tld's password:

alors que j'avais mis à "blank" la passphrase.... bordel 🙃 😡

et je comprends pas pourquoi ça me demande cette fucking passphrase
dediou!!

laster13

gormson Voilà comment je procède habituellement, si ça peut t'aider

Sur la machine maître, celle à partir de laquelle tu te connecteras sur l'autre serveur, tu renommes le fichier known_hosts, comme ça : on repart à zéro

mv /root/.ssh/known_hosts /root/.ssh/known_hosts.old

Test de connexion sur la machine esclave (642 est le port ssh sur la machine esclave, adapte)

root@DESKTOP-L7NFADO:/# ssh -p 642 root@IP The authenticity of host '[IP]:642 ([IP]:642)' can't be established. ECDSA key fingerprint is SHA256:RQk8D2tCvG+SUen96BRu8iPVMouoq4QY7jnfsmDWO7k. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added '[IP]:642' (ECDSA) to the list of known hosts. root@IP's password:

Puis exit

Ensuite, toujours sur la machine maître : ssh-keygen -t rsa

Voilà ce que tu obtiens

Generating public/private rsa key pair. Enter file in which to save the key (/root/.ssh/id_rsa): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /root/.ssh/id_rsa. Your public key has been saved in /root/.ssh/id_rsa.pub. The key fingerprint is: SHA256:kPgTaWCWBysRJBngAh3Edfmk3muEWfU6C5grGSQXgsQ root@DESKTOP-L7NFADO The key's randomart image is: +---[RSA 2048]----+ |OX*+*o.. | |=E++o=oo. . | |....oo*+ . . | |. ..oo.oo . | | + .oBS . | | . *.+ o | | o o o o | | o . o . | | . . | +----[SHA256]-----+

tu appuies sur entrer à chaque fois, donc pas de passphrase

Ensuite

scp -P 642 /root/.ssh/id_rsa.pub IP(machine esclave):/root/.ssh/authorized_keys2

l'option -P port si tu as changé le port ssh sur la machine esclave

tu obtiens
root@DESKTOP-L7NFADO:/# scp -P 642 /root/.ssh/id_rsa.pub IP(machine esclave):/root/.ssh/authorized_keys2 root@IP's password: id_rsa.pub

Dorénavant tu devrais pouvoir te connecter sur la machine esclave sans mot de passe

A noter mon fichier dans /root/.ssh/authorized_keys2 et non authorized_keys. Après je suppose que ça diffère selon l'OS. Tu fais tout ça en root

Je te conseille de repartir a zéro en supprimant id_rsa et id_rsa.pub de ton serveur maître et de recréer les clés comme indiquer plus haut

Tu peux faire cette manip dans les deux sens pour indifféremment avoir un accès sans mot de passe sur le maître et esclave

Malakai

gormson
J'ai l'impression que tu inverses les clefs publique et privee.
La clef publique est celle en .pub que tu dois mettre dans le authorized_keys de ton serveur.
La clef privee est celle avec laquelle tu t'authentifie depuis ta machine cliente.

Magicalex

Malakai si malakai a raison tu peux tout reprendre de zéro.

Petit rappel la clé privée sert à crypter les messages et la clé privée à décrypter les messages. C'est pour cette raison que votre clé privée ne doit en aucun cas voyager sur des serveurs.

spider1163

Magicalex Petit rappel la clé privée sert à crypter les messages et la clé privée à décrypter les messages

ON DIT CHIFFRER, ET PAS CRYPTER. :-)
https://chiffrer.info/

"la terminologie de cryptage reviendrait à coder un fichier sans en connaître la clé et donc sans pouvoir le décoder ensuite.
Le terme n’est par ailleurs pas reconnu par le dictionnaire de l’Académie française."

gormson

NOOOOOOOM de ZEUUUUUS

Et bien merci à vous pour les aiguillages. Du coup j'ai tout repris calmement sur les conseils de @laster13
j'ai repris l'ensemble de la procédure.

Ceci m'a permis de comprendre au moment du SCP que, comme je ne me connecte pas en root, et que j'avais placé le fichier authorized_keys dans /root/.shh, impossible à SSH d'accéder en tant qu'user non root d'aller chercher la clef dans root/.ssh. Merci @jean-luc d'avoir fait la précision sur les droits...

Et oui comme un couillon, le tuto que j'avais suivi était dans un cas "connection en root", que j'ai désactivé pour plus de sécurité. Du coup, comme le fichier ssh_config le mentionne

AuthorizedKeysFile      %h/.ssh/authorized_keys

donc pas dans ROOT !!!! couillon que je suis 😭

Du coup, une fois que j'avais le bon nouveau fichier authorized_keys, au bon endroit, avec les bons droits... pourquoi au grand diable, est ce que je retombais sur ce F$ù$^king message :

Permissions 0644 for '/root/.ssh/id_rsa.pub' are too open.

ben fooooooorcément de couillon 2 le retour de la vengeance de la mort, il avait encore suivi bêtement un tuto sur le renseignement du fichier config pour ssh... allez je vous le mets histoire qu'on rigole 😚

Host Le_nom_du_host
  Hostname domaine.tld
  User Le_user_pas_root
  Port Le_Porcassou
  IdentityFile ~/.ssh/id_rsa.pub

C'est bon? vous l'avez vu? le truc de 💩 qui saute aux yeux de toutes personnes avec plus de 3 neurones informatique??? hein? hein?

Ben ouaiiiiis merci oh grand merci à @Malakai et @Magicalex... j'utilisais la clef publique, pour m'authentifier...
Tout ça parce que j'ai suivi sans réfléchir ce fucking tuto : https://technique.arscenic.org/connexion-distante-au-serveur-ssh/article/utilisation-et-configuration-specifiques-cote-client

avec cette petite ligne...

IdentityFile : chemin vers la clé d’identification publique à utiliser (par exemple : ~/.ssh/ma_cle.pub) ;

Juste le pire exemple de la création quoi...

Donc voilà, merci à vous encore, comme d'hab il y a toujours quelqu'un pour aider ici.
Maintenant on part sur d'autre script... vous devriez me revoir d'ici peu 😚 😅

Magicalex

spider1163 Oh merci de m'avoir repris ^^

Page suivante »