Je vous demande de l’aide concernant un paramatrage un peu particulier.
J’ai créé un compte sur ma debian et je souhaite que mon utilisateur se connecte avec cle ssh .
Jusqu’ici tout va bien … j’ai bien la passphrase à taper et ca fonctionne.
j’ai modifier le /etc/ssh/sshd_config en passant les parametres ci dessous sur « no »
PasswordAuthentication no
ChallengeResponseAuthentication yes
UsePAM no
Ensuite j’ai fais un user ayant un acces à un seul repertoire en sftp en lui attribuant le nologin pr des raisons de secu.
Le probleme c’est que mes utilisateurs ayant le parametre nologin, me demande une clé ssh .
Comment faire pour faire cohabité les deux connexions? est il possible de faire des cles ssh pour mes utilisateurs qui n’en sont pas vraiment ???
En particulier, passer le paramètre UsePAM à no me semble assez discutable car vous vous privez ainsi de l’énorme travail des développeurs Debian pour construire un système sécurisé par défaut mais accessible par un maximum de moyens.
Qu’appelez-vous « attribuer le nologin » ? Que donne la commande
getent passwd $USER
Sachant que ssh signifie secureshell avouez que si vous donnez /usr/sbin/nologin comme shell à un utilisateur du système susceptible d’utiliser légitimement ssh c’est pour le moins contradictoire. C’est prévu pour des utilisateurs système particuliers comme www-datamanmailnobody …
Pouvez-vous préciser ce que vous entendez par « raisons de sécu » ?
Ouh là ! Il me semble plutôt que c’est la directive PasswordAuthentication qui, mise à no, ne laisse alors que la possibilité de s’authentifier que par clé.
La démarche habituelle serait plutôt la suivante : le gentil administrateur crée les comptes des utilisateurs en leur donnant un mot de passe provisoire. De plus, il leur met à disposition les informations pour
se connecter avec le mot de passe fourni
changer de mot de passe
créer des clés SSH sur leur poste client et comment utiliser la commande ssh-copy-id. Comment automatiser avec kechain.
Comment utiliser efficacement un compte Linux, avec une liste des services fournis.
Étc …
En supprimant l’accès par mot de passe, vous empêchez vos utilisateurs de réaliser leurs premiers pas Une fois que tout le monde est au point pour utiliser des clés, vous pouvez fermer la porte, mais pas a priori.
Quelles deux connexions ?
Pour bien comprendre ce qui se passe : depuis votre poste client vous testez l’authentification en lançant la commande
ssh -v -v user@serveur id
dans différents cas de figure : avec et sans agent, et avec ou sans clés chargées dans l’agent
J’ai pas étais tres clair effectivement.
Je reprends
Je souhaite faire un serveur sftp. Ce serveur fonctinne tout va bien.
Voila ce qui est en place:
j’ai deux comptes user 1 et 2 à qui je donne un acces à un repertoire en écriture en sftp.
Ces deux utilisateurs ne peuvent pas executer de shell puisque c’est pas le but et j’ai donc passé ce parametre pour cela sur chaque user:
usr/sbin/nologin
Ca fonctionne.
Maintenant, pour mon utilisateur root et mon utilisateur admin, je souhaite que ces deux users utilises les clé ssh pour se connecter mais pas mes deux users…
Aujourd’hui si j’active la connexion en clé ssh, ca me demande une clé aussi pour mes deux users … Si c’est pas possible de faire cohabité les deux solutions, comment créer des clés ssh piur mes deux autres users? Merci pour votre aide
oui c’est possible, via les directives Match User dans le fichier /etc/ssh/sshd_config.
Par exemple, tu peux utiliser quelque chose comme:
# directives globales pour tous les utilisateurs
PasswordAuthentication no
[...]
# directives spéciales pour user1 et user2, en fin de fichier
Match User user1, user2
PasswordAuthentication yes
Merci pour vos retours.
Sputnik93, j’ai fais la modif avec un Match User mais ca ne fonctionne pas …
Quand je fais cette regle j’ai acces refusé pour l’utilisateur concerné .
Mon utisateur root et admin son bien avec authentification SSH mais les autres ne peuvent pas se connecter parce que ca demande donc la clé
se termine par nologin, cela ne m’étonne pas que l’accès soit refusé. Donnez le retour complet des commandes utilisées.
Pas de paraphrase SVP, donnez le retour complet des commandes lancées avec l’option verbeuse -v et même -v -v si vous lancez la commande ssh
Pour les utilisateurs de sftp uniquement, mettre
ForceCommand internal-sftp
dans la partie Match User
Naturellement la sortie de
est toujours la bienvenue.
Cordialement,
Regards,
Mit freundlichen Grüßen,
مع تحياتي الخالصة
F. Petitjean
Ingénieur civil du Génie Maritime.
« On ne perd pas son temps en aiguisant ses outils. »
Proverbe français
« Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » (R. Devos)
grep -v '^#' /etc/ssh/sshd_config | grep -v '^$'
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key
SyslogFacility AUTHPRIV
PermitRootLogin yes
AuthorizedKeysFile .ssh/authorized_keys
PasswordAuthentication no
ChallengeResponseAuthentication no
GSSAPIAuthentication yes
GSSAPICleanupCredentials yes
UsePAM no
X11Forwarding yes
PrintMotd no
AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
AcceptEnv LC_IDENTIFICATION LC_ALL LANGUAGE
AcceptEnv XMODIFIERS
Subsystem sftp /usr/libexec/openssh/sftp-server
Match Group sftp_users
ForceCommand internal-sftp
ChrootDirectory /sftp/%u
AllowTcpForwarding no
Match User Yaldone
PasswordAuthentication yes
ssh -vv user1@10.1.1.176
[...]
User1@10.1.1.176's password:
debug2: we sent a password packet, wait for reply
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
Permission denied, please try again.
debug1: read_passphrase: can't open /dev/tty: No such file or directory
User1@10.1.1.176's password:
Ton utilisateur est chroot ? du coup quel est le besoin de limité l’accès à un shell, surtout si tu veux justement te connecter à un shell avec cet utilisateur ?
Avec cette conf j’ai le même probleme (utiisateur Yaldone)
#Match Group sftp_users
# ForceCommand internal-sftp
# ChrootDirectory /sftp/%u
# AllowTcpForwarding no
Match User Yaldone
ForceCommand internal-sftp
ChrootDirectory /sftp/%u
AllowTcpForwarding no
PasswordAuthentication yes
Je ne sais pas si ça donnera grand chose, mais dans le man sshd_config, il y a ce paragraphe:
Subsystem
Configures an external subsystem (e.g. file transfer
daemon). Arguments should be a subsystem name and a
command (with optional arguments) to execute upon subsystem
request.
The command sftp-server implements the SFTP file transfer
subsystem.
Alternately the name internal-sftp implements an in-process
SFTP server. This may simplify configurations using
ChrootDirectory to force a different filesystem root on
clients.
Peut-être qu’à la place de la ligne Subsystem sftp /usr/libexec/openssh/sftp-server tu peux essayer avec Subsystem sftp internal-sftp.
On est loin, très loin du fichier de configuration fourni par le paquet Debian
fp2@debpacha:~ $ grep -v '^#' /etc/ssh/sshd_config | grep -v '^$'
Include /etc/ssh/sshd_config.d/*.conf
ChallengeResponseAuthentication no
UsePAM yes
X11Forwarding yes
PrintMotd no
AcceptEnv LANG LC_*
Subsystem sftp /usr/lib/openssh/sftp-server
fp2@debpacha:~ $
Ni plus ni moins. Pourrait-on savoir où vous avez trouvé toutes ces directives ?
Il y a un serveur Kerberos sur votre serveur ?
Je répète, cela me semble contradictoire avec votre volonté d’avoir plusieurs types d’utilisateurs avec des profils de connexion et d’authentification différents. (Mais peut-être que je me trompe avec cette histoire de nologin )
Cordialement,
Regards,
Mit freundlichen Grüßen,
مع تحياتي الخالصة
F. Petitjean
Ingénieur civil du Génie Maritime.
« Il est souvent trop tôt pour savoir s’il n’est pas trop tard. »
Pierre Dac
« Rien ne sert de penser, faut réfléchir avant. »
Pierre Dac
J’ai refais un compte utilisateur mais ne mettant pas le parametre « nolgin » à sa création.
Et maintenant ca fonctionne …mes utilisateurs root et admin ont un acces avec clé ssh et mon utilisateur standard n’est autorisé qu’a faire du sftp avec son mot de passe habituel.
Une fois que tout le monde est au point pour utiliser des clés, vous pouvez fermer la porte, mais pas a priori.
