Vous n'êtes pas identifié(e).
Pages : 1
Pour ce qui est du "root:root" du dossier "sftponly" et de l'utilisateur "user1", je les ai; pensant bien faire, passer en commande chown root:root
Le fichier sshd_config est configuré ainsi:
Alors. Jusqu'ici; l'utilisateur "basic" se connecte bien en SSL avec passphrase.
Pour le user1, j'essaye d'envoyer la clé
avec pour message de retour
Du coup, bien que dans l'idéal, j'aurai souhaité limiter le SSL à AllowUsers AllowGroups avec identification par passphrase et donner l'accès uniquement SFTP au groupe sftponly par password; je galère! Parceque je ne trouve aucun résultat pour débloquer l'envoi de la clé ?
Merci de vos aides
*modification du titre -ssh en lien de ssl
Dernière modification par macisa (03-11-2020 17:37:02)
Hors ligne
Les commandes de tout membre du groupe sftponly sont, pour moi, restreintes. Ce que semble confirmer ton message d'erreur.
Donc tu sors ton utilisateur du groupe sftponly, tu envoies ta clé, et tu l'y remets.
ou
Tu envoie ta clef, et tu te sers de root pour la transférer sur l'utilisateur en question, en faisant attention au droits du répertoire .ssh, et du fichier authorized_keys
Dernière modification par nlancien (28-10-2020 14:19:20)
Hors ligne
ssh-copy-id est un script shell. Tu peux donc regarder ce qu'il y a comme commandes dedans.
:-) :-) je débute.. chaque chose en son temps
@nlancian merci pour ce retour
Hors ligne
Les permissions du dossier user1 ne sont pas bonnes puisque root seulement peut y accéder.
Pour finir un petit tuyau de noob qu'il m'arrive de faire de temps en temps.
À la place de la commande "ssh-copy-id" tu peux AUSSI copier tes clés manuellement, c'est pas beau mais ça fonctionne pareil même si ça fait clairement amateur.
Chez toi:
copie le contenue à la souris
Sur ton serveur:
là tu colles le contenu et tu ajustes les droits du fichier (600 ou 640 de mémoire à vérifier).
Voilà c'est à peu près tout, j'ai peut être raté des choses.
Allez courage
Dernière modification par zaphir (28-10-2020 21:01:08)
Hors ligne
C'est un poil plus long a taper, cela ne contourne pas le soucis du premier post, mais ca marche.
Pour le premier post, on peut aussi lever le serveur sftp temporairement.
Quand au propriétaire de /home/sftponly, il est correct et nécessaire dès lors que l'on veut "chrooter" la zone.
Les droits sont, de mémoire 700 pour .ssh/
et 600 pour les fichiers à l'intérieur.
Cela est paramétrable, dans ma mémoire au niveau de la ligne StrictModes, placée a Yes le serveur bloque si les permissions ne sont pas correctes.
Hors ligne
Quand au propriétaire de /home/sftponly, il est correct et nécessaire dès lors que l'on veut "chrooter" la zone.
On est d'accord pour le dossier sftponly, mais je parlais du dossier user1.
Hors ligne
Les droits sont, de mémoire 700 pour .ssh/
et 600 pour les fichiers à l'intérieur.
Je fais une petite note discrète, pour la création du .shh il faut un 704.
Une première question? A qui fait appel ssh-copy-id coté serveur (enfin, je demande coté serveur, mais cela est aussi possible que cela se passe coté clients que la conversion se passe??)
J'ai pu découvrir qu'il y a un appel de lecture du fichier .bashrc de l'utilisateur sur le serveur.
Je voudrais savoir qui traite cette demande de conversion. Un truc du style /bin/ssh/qui? ou autre /usr/bin/ssh/qui?
Et la seconde, tant à faire :-) faut-il placer un --shell lors de la création de l'utilisateur ( ou plus tard ) afin de restreinte les commandes
@+
Dernière modification par macisa (29-10-2020 15:07:16)
Hors ligne
Je vais donc creuser un peu plus loin :
Il me dit que c'est un lien symbolique vers dash. C'est ma conf. Dans la tienne ce lien pointe peut être vers bash
Tu n'as rien a faire pour restreindre les droits de ton user, le serveur ssh va bloquer toute commande qui n'est pas du sftp. Tu le vois avec ton message d'erreur. ssh-dcopy-id appelle "sh", le serveur répond : "Niet! Pas une connexion sftp."
Tu peux, peut être, lui changer son shell pour un autre mais je ne connais absolument pas les effets de bords. Si tu testes tiens nous au jus.
Quand je voulais faire un serveur sftp, je créais et paramétrait mon utilisateur, et, en dernier ressort je l'intégrais au système internal-sftp. A l'époque, je lui donnais le shell rssh, déprécié maintenant.
Hors ligne
L'utilisateur {test} est en chown(é) root.root
Dans le sshd_config
Tout ceci est bien beau mais puisque l'utilisateur client doit envoyer en correspondance sa clé publique ainsi que la possibilité d'autres clés, cela laisse encore la place à deux questions :
1 Entre le moment ou la clé est transmise au serveur et le temps de placer l'utilisateur dans un groupe réservé sftp cloisonné, l'accès ssh et sftp lui sont ouvert ?
- Existe t'il un script pour automatiser le changement de groupe de l'user dès que la clé est réceptionnée ?
2 En plaçant l'utilisateur dans le groupe sftp cloisoné, la porte du ssh se referme, donc du coup, pas de possibilité pour d'autres clés.
- J'ai bien pensé à créer un second groupe disons primaire pour laisser la possibilité de connexion en ssh permettant l'envoi d'autres clé; mais on se retrouve toujours au problème de limitation d'utilisation ssh.
S'il y a des pistes il y a preneur.
La dessus; la bonne journée
Hors ligne
Placé dans ton bloc Match Group.
A priori, je n'ai pas essayé, tu autorises la connexion par mot de passe sur ce groupe pour le sftp.
Hors ligne
Toutes mes test me renvoi à ceci
Hors ligne
Ensuite on paramètre Firefox pour utiliser un proxy socks sur le port localhost:8080 et le tour est joué.
Le gens a qui je fais assez confiance pour filer un accès ssh sur une de mes bécanes sont au nombre de deux. Probablement deux de trop. Entre Fort Knox et se balader en string il y a une marge.
Hors ligne
Auquel je rajoute un "PermitTunnel no"
Si j'ai bien trouvé, pas encore testé la moindre ligne, il est possible de n'autoriser que la commande usr/bin/sh par un chroot directory dédié.
Ce si je ne me trompe, cela devrait ainsi permettre aux utilisateurs de ne rien faire d'autre dans la partie ssh que de transférer une clé.
De là, le serveur à gentiment sa clé.
J'affecte les groupes, ce qui active le sftp et supprime l’accès ssh. M’empêchant par la même occasion de renvoyer une autre clé pour une seconde machine. Grrr
Et là je coince
Que je pensais avoir trouvé la bonne piste en supprimant le ForceCommand.
La connexion sftp passe toujours.
La connexion ssh me renvoi :
Dernière modification par macisa (02-11-2020 02:59:06)
Hors ligne
Hors ligne
Hors ligne
Hors ligne
Pages : 1