Re: SSH : autoriser root seulement en local
Le dimanche 11 février 2007 20:32, Franck Joncourt a écrit : Michel Grentzinger wrote: [...] Réseau domestique... Donc j'interdis le login root mais je requiers une connexion par clé, c'est bien ça ? J'aurais accès au root directement ? [...] Cela devrait pouvoir te permettre de te logguer avec un mot de passe pour les utilisateurs classiques et uniquement par clef publique pour l'utilisateur root. Y aurait-il quelqu'un dans l'assistance avec une telle configuration ? oui : PermitRootLogin without-password et configuration traditionelle pour les clefs publiques/privées. Cela fonctionne, mais c'est « MAL » pour tous les jours. Il vaut de loin mieux faire « sudo » ; AMHA en dehors de la question « sécurité » c'est une question de « bonnes pratiques¹ » (c'est le « IT² » qui parle). J'ai utilisé cette configuration comme « fail-safe ». [...] Si vous persistez dans cette voie (et pour éviter de taper un mot de passe déjà que l'on ne tape plus sudo), il existe libpam-ssh pour charger sa clef privée dans un agent au login ([gdx]dm par exemple) à l'aide du mot de passe saisi. Personnellement, je préfère éviter de taper mon mot de passe 2x³ avec libpam-ssh et taper « sudo -s » plustôt que l'inverse (taper le mot de passe root et pas « sudo -s »). HS: a quand un module PAM pour utiliser l'agent ssh et faire sudo avec clef publique/privée ? ¹: les effets se font ressentir à long-terme même si on ne comprends pas toujours pourquoi au début ;-) ²: http://en.wikipedia.org/wiki/It_crowd ³: 1x pour « ssh [EMAIL PROTECTED] » et 1x pour « sudo -s » Cordialement, -- Eric DÉCORNOD Ingénieur d'Études SCICS - Faculté des Sciences Université Henri Poincaré
Re: SSH : autoriser root seulement en local
Le lundi 12 février 2007 11:15, Eric DECORNOD a écrit : Le dimanche 11 février 2007 20:32, Franck Joncourt a écrit : Michel Grentzinger wrote: [...] oui : PermitRootLogin without-password et configuration traditionelle pour les clefs publiques/privées. Cela fonctionne, mais c'est « MAL » pour tous les jours. mode baby Troll Pourquoi C'est au contraire bien plus sécurisé qu'un password, du fait que même les clés ne sont pas échangées, mais seulement leurs représentations. Par ailleurs les spécialistes sécurité estiment, pour une majorité, que si un attaquant a déjà réussi à subtiliser un login pour un user normal, il-y-a énormément de chances pour qu'il finisse par se loger en root Mais évidemment, si tu laisses sans surveillance une station logée sous root /mode baby Troll JY
Re: SSH : autoriser root seulement en local
Le lundi 12 février 2007 13:45, Jean-Yves F. Barbier a écrit : [...] oui : PermitRootLogin without-password et configuration traditionelle pour les clefs publiques/privées. Cela fonctionne, mais c'est « MAL » pour tous les jours. mode baby Troll s/baby//g Pourquoi C'est au contraire bien plus sécurisé qu'un password, du fait que même les clés ne sont pas échangées, mais seulement leurs représentations. Absoluement, je préfère de loin le challenge-response au plaintext. Je rêve même de la configuration où ta clef privée reste sur clef USB et est chargée/déchargée à l'insertion/suppression de cette dernière. Par ailleurs les spécialistes sécurité estiment, pour une majorité, que si un attaquant a déjà réussi à subtiliser un login pour un user normal, il-y-a énormément de chances pour qu'il finisse par se loger en root Et à fortiori si le user en question est sudoer... Mais évidemment, si tu laisses sans surveillance une station logée sous root C'est bien là la teneur de mes propos : Je soutiens que c'est « MAL » non pas pour des raison techniques ou sécuritaires, mais pour des questions d'« usage » (de la même façon que manger au dessus de son clavier c'est MAL ;-) ). Je m'explique : à se logguer en root on prends de mauvaise habitudes. Plus l'habitude court, plus la « faignantise » s'installe et moins on fait attention à ce que l'on fait. Et c'est à ce moment là que le doigt glisse de la touche * vers entrée (les deux sont côte à côte) et que les accidents arrivent. En utilisant « sudo » on fait bien la distinction ente ce qui requiert les droits root et le reste. De plus sudo consigne les actions, ce qui est judicieux dès lors que l'administration se fait à plusieurs (troll« quel est le x#!@ qui a remplacé les flèches par hjkl sont tes nouveaux amis »/troll). /mode baby Troll JY Cordialement, -- Eric DÉCORNOD Ingénieur d'Études SCICS - Faculté des Sciences Université Henri Poincaré
Re: SSH : autoriser root seulement en local
Le lundi 12 février 2007 15:27, Eric DECORNOD a écrit : Le lundi 12 février 2007 13:45, Jean-Yves F. Barbier a écrit : [...] Absoluement, je préfère de loin le challenge-response au plaintext. Je rêve même de la configuration où ta clef privée reste sur clef USB et est chargée/déchargée à l'insertion/suppression de cette dernière. Ca, ça devrait être possible sans trop de PB (montage auto de la clé à l'insertion + symlink de '/root/.ssh' pointant vers un DIR de la clé) ... Je m'explique : à se logguer en root on prends de mauvaise habitudes. Plus l'habitude court, plus la « faignantise » s'installe et moins on fait attention à ce que l'on fait. Et c'est à ce moment là que le doigt glisse de la touche * vers entrée (les deux sont côte à côte) et que les accidents arrivent. Oui, et non... Je m'explique: tant que ça n'est que du $user à modifier, c'est Ok; par contre, si c'est systématiquement du system, là tu n'as pas le choix (Ex: les modifs que je fais sur mon firewall ou sur mon serveur sont *toujours* des modifs system (règle iptables, modifs de samba, etc...), donc c'est plus rapide de se loger en root.) Pour conclure, c'est de la responsabilité de l'admin de savoir s'il prend cette décision... et les précautions qui s'imposent. Il m'est plus souvent arrivé de faire des conneries en me trompant de console (console 2 en ssh sur un autre micro où tu crois être, alors que tu es en console 1, et vice-versa) que de faire des erreurs parce que j'étais root. ... De plus sudo consigne les actions, ce qui est judicieux dès lors que l'administration se fait à plusieurs (troll« quel est le x#!@ qui a remplacé les flèches par hjkl sont tes nouveaux amis »/troll). Là, effectivement, je suis d'accord avec toi, pas question de loger directement en root! Cordialement, JY
Re: [HS] be root or not ? (was : SSH autoriser root seulement en local)
Le lundi 12 février 2007 15:40, Jean-Yves F. Barbier a écrit : [...] Je m'explique : à se logguer en root on prends de mauvaise habitudes. Plus l'habitude court, plus la « faignantise » s'installe et moins on fait attention à ce que l'on fait. Et c'est à ce moment là que le doigt glisse de la touche * vers entrée (les deux sont côte à côte) et que les accidents arrivent. Oui, et non... Je m'explique: tant que ça n'est que du $user à modifier, c'est Ok; par contre, si c'est systématiquement du system, là tu n'as pas le choix (Ex: les modifs que je fais sur mon firewall ou sur mon serveur sont *toujours* des modifs system (règle iptables, modifs de samba, etc...), donc c'est plus rapide de se loger en root.) Je le concède, je suis le premier à me loguer en root dans ce cas (il m'est arrivé de ne créer aucun compte utilisateur). Pour conclure, c'est de la responsabilité de l'admin de savoir s'il prend cette décision... et les précautions qui s'imposent. Je reconnais que j'y vais un peu fort en disant « c'est MAL », mais c'est pour moi une façon de me rappeler justement ces fameuses « précautions qui s'imposent » (flagellationtout comme sudo qui me fait [EMAIL PROTECTED] à chaque fois qu'il me demande mon mot de passe de 25 caractères/flagellation). Il y a d'autres méthodes comme se dire que « chaque fois qu'on se logue en root pour rien, dieu tue un chat, pensez aux chats ». Il m'est plus souvent arrivé de faire des conneries en me trompant de console (console 2 en ssh sur un autre micro où tu crois être, alors que tu es en console 1, et vice-versa) que de faire des erreurs parce que j'étais root. # reboot...(attente trop longue) connection closed blabla... « eh merde » C'est du vécu aussi ça... ... De plus sudo consigne les actions, ce qui est judicieux dès lors que l'administration se fait à plusieurs (troll« quel est le x#!@ qui a remplacé les flèches par hjkl sont tes nouveaux amis »/troll). Là, effectivement, je suis d'accord avec toi, pas question de loger directement en root! Et pourtant on le fait si souvent... En fait il faudrait assigner un shell qui consigne dans les journaux pour les ssh [EMAIL PROTECTED] par défaut ; je crois que c'est possible avec les options du .ssh/authorized_keys mais je n'ai jamais testé. Cordialement, JY Cordialement, -- Eric DÉCORNOD Ingénieur d'Études SCICS - Faculté des Sciences Université Henri Poincaré
Re: [HS] be root or not ? (was : SSH autoriser root seulement en local)
Le lundi 12 février 2007 16:39, Eric DECORNOD a écrit : Le lundi 12 février 2007 15:40, Jean-Yves F. Barbier a écrit : [...] Je le concède, je suis le premier à me loguer en root dans ce cas (il m'est arrivé de ne créer aucun compte utilisateur). Alors CA, CA c'est TT mal !!! Mon fils, vous direz 50 je vous salut init et 30 'l'ext2 est mon berger. Pour conclure, c'est de la responsabilité de l'admin de savoir s'il prend cette décision... et les précautions qui s'imposent. Je reconnais que j'y vais un peu fort en disant « c'est MAL », mais c'est pour moi une façon de me rappeler justement ces fameuses « précautions qui s'imposent » (flagellationtout comme sudo qui me fait [EMAIL PROTECTED] à chaque fois qu'il me demande mon mot de passe de 25 caractères/flagellation). pas suffisant: flagellation au sumac vénéneux + barbelés rouillés Il y a d'autres méthodes comme se dire que « chaque fois qu'on se logue en root pour rien, dieu tue un chat, pensez aux chats ». dommage qu'il ne tue pas un con, je n'aurais plus que des comptes root (quoiqu'on soit toujours le con de quelqu'un :) ... De plus sudo consigne les actions, ce qui est judicieux dès lors que l'administration se fait à plusieurs (troll« quel est le x#!@ qui a remplacé les flèches par hjkl sont tes nouveaux amis »/troll). Là, effectivement, je suis d'accord avec toi, pas question de loger directement en root! Et pourtant on le fait si souvent... En fait il faudrait assigner un shell qui consigne dans les journaux pour les ssh [EMAIL PROTECTED] par défaut ; je crois que c'est possible avec les options du .ssh/authorized_keys mais je n'ai jamais testé. C'est une idée à creuser, et je vais regarder ça de près. Cordialement , JY
Re: SSH : autoriser root seulement en local
Jean-Yves F. Barbier wrote: mode baby Troll Pourquoi C'est au contraire bien plus sécurisé qu'un password, du fait que même les clés ne sont pas échangées, mais seulement leurs représentations. Par ailleurs les spécialistes sécurité estiment, pour une majorité, que si un attaquant a déjà réussi à subtiliser un login pour un user normal, il-y-a énormément de chances pour qu'il finisse par se loger en root Faut plus lancer Apache alors? (ni rien d'autre, à part vi :). le principe de bon sens retenu en général est la defense in depth, et une de ses conséquences: minimiser les privilèges donnés à quoi/qui que ce soit. D'accord, ça ne suffit pas à rendre un système sécurisé, mais ça aide un peu. D'autre part, laisser l'accès à root pose le problème de la machine client: du coup, on a besoin de la rendre plus sûre qu'on n'en a envie (surtout avec un windows ou un virus peut choper les mots de passe. bien sur, un keylogger peut aussi recuperer toutes les infos, mais c'est plus dur car il doit prévoir quand tu fais su... etc). -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs From et Reply-To: To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: SSH : autoriser root seulement en local
Bonjour Interdire le root login mais autoriser une connection par clefs Guy Michel Grentzinger a écrit : Le samedi 10 février 2007 19:41, mouss a écrit : Je cherche à limiter les connexions en root seulement depuis le réseau local (homeg.lan). J'ai essayé ceci sans succès : PermitRootLogin yes AllowUsers [EMAIL PROTECTED] Est-ce possible ? Je n'ai pas trouvé de docs la-dessus. pas à ma connaissance. Cela dit, il n'y a aucune raison d'autoriser l'accès à root. ca empêche tout audit. il vaut mieux que chaque utilisateur utilise son propre compte, et si necessaire fait 'su' (ou sudo). Oui mais pour gérer mon serveur, c'est beaucoup plus pratique d'aller directement dans le compte root ! -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs From et Reply-To: To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: SSH : autoriser root seulement en local
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 De Leeuw Guy wrote: Bonjour Interdire le root login mais autoriser une connection par clefs Guy Je pense que autoriser le login root est beaucoup trop dangereux, meme avec une clef publique. Avec quelqu'un de mal intentionne sur le resau local, on est pas a l'abris d'une replay attack. Mais bon,tout depend du contexte dans lequel on se place. - -- Franck Joncourt http://www.debian.org http://smhteam.info/wiki/ GPG server : pgpkeys.mit.edu Fingerprint : C10E D1D0 EF70 0A2A CACF 9A3C C490 534E 75C0 89FE -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFz1AWxJBTTnXAif4RAuLuAJ9e4Dxpp+4y3sA3G0Pz/WzQ4nTO8ACdGamU imsVmmtlL/p7CE/7b/HS+dc= =Bgfz -END PGP SIGNATURE- ___ All New Yahoo! Mail � Tired of [EMAIL PROTECTED]@! come-ons? Let our SpamGuard protect you. http://uk.docs.yahoo.com/nowyoucan.html -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs From et Reply-To: To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: SSH : autoriser root seulement en local
Le dimanche 11 février 2007 18:19, Franck Joncourt a écrit : Interdire le root login mais autoriser une connection par clefs Guy Je pense que autoriser le login root est beaucoup trop dangereux, meme avec une clef publique. Avec quelqu'un de mal intentionne sur le resau local, on est pas a l'abris d'une replay attack. Mais bon,tout depend du contexte dans lequel on se place. Réseau domestique... Donc j'interdis le login root mais je requiers une connexion par clé, c'est bien ça ? J'aurais accès au root directement ? -- Michel Grentzinger OpenPGP key ID : B2BAFAFA Available on http://www.keyserver.net
Re: SSH : autoriser root seulement en local
Le dimanche 11 février 2007 18:19, Franck Joncourt a écrit : De Leeuw Guy wrote: Bonjour Interdire le root login mais autoriser une connection par clefs Guy Je pense que autoriser le login root est beaucoup trop dangereux, meme avec une clef publique. Avec quelqu'un de mal intentionne sur le resau local, on est pas a l'abris d'une replay attack. Faux, sinon la politique Debian n'aurait pas précédemment changée PermitRootLogin de no vers yes. JY
Re: SSH : autoriser root seulement en local
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Michel Grentzinger wrote: Le dimanche 11 février 2007 18:19, Franck Joncourt a écrit : Interdire le root login mais autoriser une connection par clefs Guy Je pense que autoriser le login root est beaucoup trop dangereux, meme avec une clef publique. Avec quelqu'un de mal intentionne sur le resau local, on est pas a l'abris d'une replay attack. Mais bon,tout depend du contexte dans lequel on se place. Réseau domestique... Donc j'interdis le login root mais je requiers une connexion par clé, c'est bien ça ? J'aurais accès au root directement ? J'ai jamais effectue de connexion root en ssh! J'ai la directive ''PermitRootLogin'' a no. Je me connecte en ssh via un utilisateur classique et je me loggue ensuite en root. Pour te donner la bonne configuration je ne suis donc pas le mieux place :) Mais, moi j'essayerais : PermitRootLogin forced-commands-only PubkeyAuthentication yes PasswordAuthentication yes Cela devrait pouvoir te permettre de te logguer avec un mot de passe pour les utilisateurs classiques et uniquement par clef publique pour l'utilisateur root. Y aurait-il quelqu'un dans l'assistance avec une telle configuration ? - -- Franck Joncourt http://www.debian.org http://smhteam.info/wiki/ GPG server : pgpkeys.mit.edu Fingerprint : C10E D1D0 EF70 0A2A CACF 9A3C C490 534E 75C0 89FE -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFz29MxJBTTnXAif4RAuNbAJoD6iVzut+XSf1+TrtQO7dvor2g0wCePhxI HvWT+yv3it1CmGuNyYxRXyo= =+QYb -END PGP SIGNATURE- ___ Try the all-new Yahoo! Mail. The New Version is radically easier to use � The Wall Street Journal http://uk.docs.yahoo.com/nowyoucan.html -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs From et Reply-To: To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: SSH : autoriser root seulement en local
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jean-Yves F. Barbier wrote: Le dimanche 11 février 2007 18:19, Franck Joncourt a écrit : De Leeuw Guy wrote: Bonjour Interdire le root login mais autoriser une connection par clefs Guy Je pense que autoriser le login root est beaucoup trop dangereux, meme avec une clef publique. Avec quelqu'un de mal intentionne sur le resau local, on est pas a l'abris d'une replay attack. Faux, sinon la politique Debian n'aurait pas précédemment changée PermitRootLogin de no vers yes. JY Qu'est ce qui est considere comme faux ? 1/ le fait de se logguer en root avec mot de passe 2/ le fait de se logguer en root avec une clef publique 3/ 1 2 n'est pas sure. Moi, c'etait mon avis, mais je suis preneur si quelqu'un peut m'expliquer pourquoi. - -- Franck Joncourt http://www.debian.org http://smhteam.info/wiki/ GPG server : pgpkeys.mit.edu Fingerprint : C10E D1D0 EF70 0A2A CACF 9A3C C490 534E 75C0 89FE -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFz3GpxJBTTnXAif4RAo7yAJ0Yux2GwX4HWr0LiHAUUUzYIN0L8QCg0tiL 3Wk0geakiHbdoi/iu00YV2o= =+NOv -END PGP SIGNATURE- ___ All new Yahoo! Mail The new Interface is stunning in its simplicity and ease of use. - PC Magazine http://uk.docs.yahoo.com/nowyoucan.html -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs From et Reply-To: To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: SSH : autoriser root seulement en local
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Franck Joncourt wrote: Jean-Yves F. Barbier wrote: Le dimanche 11 février 2007 18:19, Franck Joncourt a écrit : De Leeuw Guy wrote: Bonjour Interdire le root login mais autoriser une connection par clefs Guy Je pense que autoriser le login root est beaucoup trop dangereux, meme avec une clef publique. Avec quelqu'un de mal intentionne sur le resau local, on est pas a l'abris d'une replay attack. Faux, sinon la politique Debian n'aurait pas précédemment changée PermitRootLogin de no vers yes. JY Et bien j'ai fait quelques recherches et j'en deduis que j'avais tord. L'authentification par clef publique semble tout a fait fiable (a l'exception d'une vulnerabilite face aux attaques de types MITM - http://fr.wikipedia.org/wiki/Attaque_de_l%27homme_du_milieu). Desole pour le bruit mais on apprend tous les jours :) - -- Franck Joncourt http://www.debian.org http://smhteam.info/wiki/ GPG server : pgpkeys.mit.edu Fingerprint : C10E D1D0 EF70 0A2A CACF 9A3C C490 534E 75C0 89FE -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFz41PxJBTTnXAif4RAr4zAJ9ikWO0bu6gSAV4pDRwHoYdRqQNQACgh8sT nITU8tMU/hqhEJ01j7QWW+8= =J+Ug -END PGP SIGNATURE- ___ All new Yahoo! Mail The new Interface is stunning in its simplicity and ease of use. - PC Magazine http://uk.docs.yahoo.com/nowyoucan.html -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs From et Reply-To: To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
SSH : autoriser root seulement en local
Bonjour, Je cherche à limiter les connexions en root seulement depuis le réseau local (homeg.lan). J'ai essayé ceci sans succès : PermitRootLogin yes AllowUsers [EMAIL PROTECTED] Est-ce possible ? Je n'ai pas trouvé de docs la-dessus. -- Michel Grentzinger OpenPGP key ID : B2BAFAFA Available on http://www.keyserver.net
Re: SSH : autoriser root seulement en local
Michel Grentzinger wrote: Bonjour, Je cherche à limiter les connexions en root seulement depuis le réseau local (homeg.lan). J'ai essayé ceci sans succès : PermitRootLogin yes AllowUsers [EMAIL PROTECTED] Est-ce possible ? Je n'ai pas trouvé de docs la-dessus. pas à ma connaissance. Cela dit, il n'y a aucune raison d'autoriser l'accès à root. ca empêche tout audit. il vaut mieux que chaque utilisateur utilise son propre compte, et si necessaire fait 'su' (ou sudo). maintenant, tu peux aussi lancer deux ssh: un pour le réseau local et un pour le public. il faut dupliquer la configuration bien entendu (y compris /etc/pam.d/ssh). -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs From et Reply-To: To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: SSH : autoriser root seulement en local
Le samedi 10 février 2007 19:41, mouss a écrit : Je cherche à limiter les connexions en root seulement depuis le réseau local (homeg.lan). J'ai essayé ceci sans succès : PermitRootLogin yes AllowUsers [EMAIL PROTECTED] Est-ce possible ? Je n'ai pas trouvé de docs la-dessus. pas à ma connaissance. Cela dit, il n'y a aucune raison d'autoriser l'accès à root. ca empêche tout audit. il vaut mieux que chaque utilisateur utilise son propre compte, et si necessaire fait 'su' (ou sudo). Oui mais pour gérer mon serveur, c'est beaucoup plus pratique d'aller directement dans le compte root ! -- Michel Grentzinger OpenPGP key ID : B2BAFAFA Available on http://www.keyserver.net
Re: SSH : autoriser root seulement en local
Michel Grentzinger wrote: Le samedi 10 février 2007 19:41, mouss a écrit : Je cherche à limiter les connexions en root seulement depuis le réseau local (homeg.lan). J'ai essayé ceci sans succès : PermitRootLogin yes AllowUsers [EMAIL PROTECTED] Est-ce possible ? Je n'ai pas trouvé de docs la-dessus. pas à ma connaissance. Cela dit, il n'y a aucune raison d'autoriser l'accès à root. ca empêche tout audit. il vaut mieux que chaque utilisateur utilise son propre compte, et si necessaire fait 'su' (ou sudo). Oui mais pour gérer mon serveur, c'est beaucoup plus pratique d'aller directement dans le compte root ! tu lances une instance ssh juste pour ça. cette instance écoutera sur un port à choisir, autorisera uniquement les connexions à partir du réseau local, et uniquement pour des comptes à choisir. pour cela, il faut faire une copie des fichiers ssh. attention au fichier de pid dans /etc/init.d/ssh (sinon, tu risque d'arrêter le mauvais ssh...). -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs From et Reply-To: To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: SSH : autoriser root seulement en local
Michel Grentzinger a écrit : [...] Cela dit, il n'y a aucune raison d'autoriser l'accès à root. ca empêche tout audit. il vaut mieux que chaque utilisateur utilise son propre compte, et si necessaire fait 'su' (ou sudo). Oui mais pour gérer mon serveur, c'est beaucoup plus pratique d'aller directement dans le compte root ! Pratique pour quoi? gérer un serveur demande de l' attention de la part de l' administrateur: un accès en user suivi d' un sudo comme cela a été proposé est la meilleure solution en matière de sécurité. A vous de voir si le pratique doit prendre le pas sur la sécurité. Quant au beaucoup, j' en doute ;-)! -- Daniel Huhardeaux _ _ _ _ enum+48 32 285 5276 (_ __) _ ) _ (_ __) _ _(_) iaxtel 1-700-849-6983 / / / // / // / / / / /_/ / / sip/iax:callto [EMAIL PROTECTED]/_/ ( ___( ___/ /_/ (_/ (_/_/.netFWD# 422493 -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs From et Reply-To: To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Fwd: [Exploits] SSH Remote Root password Cracking Tool, Qt 3.x bmp Exploit ...]
On Thu, 26 Aug 2004 01:55:55 +0200 Mezig [EMAIL PROTECTED] wrote: Nicolas Rueff wrote: On Wed, 25 Aug 2004 17:35:36 +0200 Mezig [EMAIL PROTECTED] wrote: 1 idée et sinon, je vous joint 1 info de chez K-Otik sur QT et surtout SSH :( ! Ce qui explique pourquoi j'ai des tentatives de connexion sauvage sur ma passerelle depuis quelques jours: Aug 24 17:57:13 firewall sshd[7654]: Failed password for test from :::67.18.247.2 port 44207 ssh2 Aug 24 17:57:15 firewall sshd[7656]: Failed password for guest from :::67.18.247.2 port 49327 ssh2 Aug 24 17:57:18 firewall sshd[7659]: Failed password for admin from :::67.18.247.2 port 39591 ssh2 Aug 24 17:57:20 firewall sshd[7661]: Failed password for admin from :::67.18.247.2 port 56204 ssh2 Aug 24 17:57:22 firewall sshd[7664]: Failed password for illegal user user from :::67.18.247.2 port 33377 ssh2 Aug 24 17:57:25 firewall sshd[7666]: Failed password for root from :::67.18.247.2 port 60536 ssh2 Aug 24 17:57:27 firewall sshd[7669]: Failed password for root from :::67.18.247.2 port 41287 ssh2 Aug 24 17:57:29 firewall sshd[7671]: Failed password for root from :::67.18.247.2 port 54616 ssh2 Aug 24 17:57:32 firewall sshd[7674]: Failed password for test from :::67.18.247.2 port 60438 ssh2 Lol ;) C 1 'avertissement' technique, mais extérieur à la communauté linux :(! Par contre le PB peut devenir critique sous peu... , vu la quantité de serveurs sous des OS Libre... :( ! Sinon , d'après spam-RBL, Adresse IP : 67.18.247.2 Cette IP n'est pas recensée dans notre base ... :)! bash-2.05b$ host 67.18.247.2 2.247.18.67.in-addr.arpa domain name pointer admin.sh3ll.ro. Tu n'as déjà pas affaire à 1 spammeur... ; mais de là à te rassurer ... ? Pas de soucis pour moi: authentification via clés privées / publiques ;) Et sinon avec les options -B, --bogus-nxdomain=ipaddr Transform replies which contain the IP address given into No such domain replies. This is intended to counteract a devious move made by Versign in September 2003 when they started returning the address of an advertising web page in response to queries for unregistered names, instead of the correct NXDOMAIN response. This option tells dnsmasq to fake the correct response when it sees this behaviour. As at Sept 2003 the IP address being returnd by Verisign is 64.94.110.11 -f, --filterwin2k Later versions of windows make periodic DNS requests which don't get sensible answers from the public DNS and can cause problems by triggering dial-on-demand links. This flag turns on an option to filter such requests. The requests blocked are for records of types SOA and SRV, and type ANY where the requested name has underscores, to catch LDAP requests. de dnsmask, il n'y a pas moyen de faire qque chose ? C'est à dire ? Je ne comprends pas ce que tu veux dire. Note que vu mon niveau, c'est pas à toi que je risque 'd'apprendre' grand-chose ..., ça serai +tôt le contraire :( ! Super ta page, j'y ai lu plein de sujets qui m'intéressent... :) ! Yep, mais faudrait que je songe à la faire évoluer un poil (dernière mise à jour en mars dernier). Ajoute peut-être qque chose sur ssh et surtout les commandes 'avancées', si tu peux... :) ? Honnêtement: pas le temps et surtout pas le net chez moi, ce qui complique un chouia la mise à jour des trucs. -- Nicolas Rueff · Montbéliard · France · http://rueff.homelinux.org (^[EMAIL PROTECTED] · GPG 0xDD44DAB4 /v\ Jabber [EMAIL PROTECTED] · ICQ 97700474 __/ « We are Penguin. Resistance is futile. You will be assimilated. »
[Fwd: [Exploits] SSH Remote Root password Cracking Tool, Qt 3.x bmp Exploit ...]
Slt Tjrs dans mes PB de SSh, je cherche dans quels fichier de config, dois-je mettre à =yes, la commande : PubkeyAuthentication ? 1 idée et sinon, je vous joint 1 info de chez K-Otik sur QT et surtout SSH :( ! Si j'ai pu aider ? Merci Mi ---BeginMessage--- -- K-OTiK Security / Exploits -- 2002-2004 K-OTiK.COM © Threat and Security Survey 24h/24 and 7j/7 Backend/XML/RSS - http://www.k-otik.com/rss -- 22.08.2004 : Qt 3.x bmp image parsing local buffer overflow Exploit --- * [localhost] netstat -ant | grep 7000 * [localhost] gcc -Wall haqt.c * [localhost] ./a.out 0x80be9f8 8 * [localhost] ./qvv suckit.bmp * [localhost] netstat -ant | grep 7000 * tcp 0 0 0.0.0.0:7000 0.0.0.0:* LISTEN * [n00b localho outernet] ./a.out * Usage: ./a.out retaddr [ align ] * http://www.k-otik.com/exploits/08222004.haqt.c.php - 22.08.2004 : SSH Remote Root password Brute Force Cracking Utility --- * the first brutessh was only for users guest test * brutessh2 is a brute for sshd port wich atempts to login as root * trying more than 2000 passwords for it. * users guest , test , nobody and admin with no passwords are included. This exploit is circulating in the wild. So protect your passwords. http://www.k-otik.com/exploits/08202004.brutessh2.c.php -- -- ---End Message---
Re: [Fwd: [Exploits] SSH Remote Root password Cracking Tool, Qt 3.x bmp Exploit ...]
On Wed, 25 Aug 2004 17:35:36 +0200 Mezig [EMAIL PROTECTED] wrote: 1 idée et sinon, je vous joint 1 info de chez K-Otik sur QT et surtout SSH :( ! Ce qui explique pourquoi j'ai des tentatives de connexion sauvage sur ma passerelle depuis quelques jours: Aug 24 17:57:13 firewall sshd[7654]: Failed password for test from :::67.18.247.2 port 44207 ssh2 Aug 24 17:57:15 firewall sshd[7656]: Failed password for guest from :::67.18.247.2 port 49327 ssh2 Aug 24 17:57:18 firewall sshd[7659]: Failed password for admin from :::67.18.247.2 port 39591 ssh2 Aug 24 17:57:20 firewall sshd[7661]: Failed password for admin from :::67.18.247.2 port 56204 ssh2 Aug 24 17:57:22 firewall sshd[7664]: Failed password for illegal user user from :::67.18.247.2 port 33377 ssh2 Aug 24 17:57:25 firewall sshd[7666]: Failed password for root from :::67.18.247.2 port 60536 ssh2 Aug 24 17:57:27 firewall sshd[7669]: Failed password for root from :::67.18.247.2 port 41287 ssh2 Aug 24 17:57:29 firewall sshd[7671]: Failed password for root from :::67.18.247.2 port 54616 ssh2 Aug 24 17:57:32 firewall sshd[7674]: Failed password for test from :::67.18.247.2 port 60438 ssh2 Lol ;) -- Nicolas Rueff · Montbéliard · France · http://rueff.homelinux.org (^[EMAIL PROTECTED] · GPG 0xDD44DAB4 /v\ Jabber [EMAIL PROTECTED] · ICQ 97700474 __/ « We are Penguin. Resistance is futile. You will be assimilated. »
Re: [Fwd: [Exploits] SSH Remote Root password Cracking Tool, Qt 3.x bmp Exploit ...]
Nicolas Rueff wrote: On Wed, 25 Aug 2004 17:35:36 +0200 Mezig [EMAIL PROTECTED] wrote: 1 idée et sinon, je vous joint 1 info de chez K-Otik sur QT et surtout SSH :( ! Ce qui explique pourquoi j'ai des tentatives de connexion sauvage sur ma passerelle depuis quelques jours: Aug 24 17:57:13 firewall sshd[7654]: Failed password for test from :::67.18.247.2 port 44207 ssh2 Aug 24 17:57:15 firewall sshd[7656]: Failed password for guest from :::67.18.247.2 port 49327 ssh2 Aug 24 17:57:18 firewall sshd[7659]: Failed password for admin from :::67.18.247.2 port 39591 ssh2 Aug 24 17:57:20 firewall sshd[7661]: Failed password for admin from :::67.18.247.2 port 56204 ssh2 Aug 24 17:57:22 firewall sshd[7664]: Failed password for illegal user user from :::67.18.247.2 port 33377 ssh2 Aug 24 17:57:25 firewall sshd[7666]: Failed password for root from :::67.18.247.2 port 60536 ssh2 Aug 24 17:57:27 firewall sshd[7669]: Failed password for root from :::67.18.247.2 port 41287 ssh2 Aug 24 17:57:29 firewall sshd[7671]: Failed password for root from :::67.18.247.2 port 54616 ssh2 Aug 24 17:57:32 firewall sshd[7674]: Failed password for test from :::67.18.247.2 port 60438 ssh2 Lol ;) C 1 'avertissement' technique, mais extérieur à la communauté linux :(! Par contre le PB peut devenir critique sous peu... , vu la quantité de serveurs sous des OS Libre... :( ! Sinon , d'après spam-RBL, Adresse IP : 67.18.247.2 Cette IP n'est pas recensée dans notre base ... :)! Tu n'as déjà pas affaire à 1 spammeur... ; mais de là à te rassurer ... ? Et sinon avec les options -B, --bogus-nxdomain=ipaddr Transform replies which contain the IP address given into No such domain replies. This is intended to counteract a devious move made by Versign in September 2003 when they started returning the address of an advertising web page in response to queries for unregistered names, instead of the correct NXDOMAIN response. This option tells dnsmasq to fake the correct response when it sees this behaviour. As at Sept 2003 the IP address being returnd by Verisign is 64.94.110.11 -f, --filterwin2k Later versions of windows make periodic DNS requests which don't get sensible answers from the public DNS and can cause problems by triggering dial-on-demand links. This flag turns on an option to filter such requests. The requests blocked are for records of types SOA and SRV, and type ANY where the requested name has underscores, to catch LDAP requests. de dnsmask, il n'y a pas moyen de faire qque chose ? Note que vu mon niveau, c'est pas à toi que je risque 'd'apprendre' grand-chose ..., ça serai +tôt le contraire :( ! Super ta page, j'y ai lu plein de sujets qui m'intéressent... :) ! Ajoute peut-être qque chose sur ssh et surtout les commandes 'avancées', si tu peux... :) ? Cordialement Mi
Re: SSH permits root-Logins with wrong password
On Wed, Jun 16, 2004 at 05:43:32PM +0200, Frank Niedermann wrote: snip If I try to use 'x' as wrong password, ssh won't let me in: [EMAIL PROTECTED]'s password: Permission denied (publickey,password,keyboard-interactive). Just as I would expect it. If I use a longer or similar password as the real root password, ssh will let me log in, example: real root password = linux4me - success :) fake root password = fun4linux - success! :( The ssh package version: ii ssh 3.8p1-3 Secure rlogin/rsh/rcp replacement (OpenSSH) Any idea about that behavor? Do you have public keys installed on that server? If you have a key with one password which is different from root's password on that machine, it can explain this behavior. HTH. -- Hamilton Coutinho | panic(Aarggh: attempting to free lock with [EMAIL PROTECTED] | active wait queue - shoot Andy); Porto Alegre - RS - Brasil |2.0.38 /usr/src/linux/fs/locks.c -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
SSH permits root-Logins with wrong password
Hello, I have a Debian testing server on my network with OpenSSH running. If I try to log in as root but with wrong password I get the following: [EMAIL PROTECTED] deniedfr $ ssh [EMAIL PROTECTED] Password: wrong password here Password: the same wrong password Password: the same wrong password [EMAIL PROTECTED]'s password: the same wrong password Last login: Wed Jun 16 17:03:11 2004 from dettnb80.tt.de.ifm dettlx18:~# uname -a Linux dettlx18 2.4.18-bf2.4 #1 Son Apr 14 09:53:28 CEST 2002 i686 GNU/Linux dettlx18:~# The /var/log/auth.log: sshd[1335]: (pam_securetty) access denied: tty 'ssh' is not secure ! sshd[1335]: (pam_unix) authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=dettnb80.tt.de.ifm user=root sshd[1333]: error: PAM: Authentication failure sshd[1336]: (pam_securetty) access denied: tty 'ssh' is not secure ! sshd[1336]: (pam_unix) authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=dettnb80.tt.de.ifm user=root sshd[1333]: error: PAM: Authentication failure sshd[1337]: (pam_securetty) access denied: tty 'ssh' is not secure ! sshd[1337]: (pam_unix) authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=dettnb80.tt.de.ifm user=root sshd[1333]: error: PAM: Authentication failure sshd[1333]: Failed keyboard-interactive/pam for root from 172.16.15.80 port 32896 ssh2 sshd[1333]: Accepted password for root from 172.16.15.80 port 32896 ssh2 sshd[1338]: (pam_unix) session opened for user root by root(uid=0) If I try to use 'x' as wrong password, ssh won't let me in: [EMAIL PROTECTED]'s password: Permission denied (publickey,password,keyboard-interactive). Just as I would expect it. If I use a longer or similar password as the real root password, ssh will let me log in, example: real root password = linux4me - success :) fake root password = fun4linux - success! :( The ssh package version: ii ssh 3.8p1-3 Secure rlogin/rsh/rcp replacement (OpenSSH) Any idea about that behavor? Regards, Frank -- Mail: [EMAIL PROTECTED] XMPP: [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: SSH permits root-Logins with wrong password
I tried to duplicate this on a sid box and a sarge box (that hasn't been upgraded for awhile). I couldn't duplicate your results. The sid box has ii ssh3.8.1p1-4 Secure rlogin/rsh/rcp replacement (OpenSSH and the sarge box has ii ssh3.6.1p2-3 Secure rlogin/rsh/rcp replacement (OpenSSH) Sarge box: [EMAIL PROTECTED]:~$ ssh -l root 10.224.112.121 [EMAIL PROTECTED]'s password: Permission denied, please try again. [EMAIL PROTECTED]'s password: Permission denied, please try again. [EMAIL PROTECTED]'s password: Permission denied (publickey). [EMAIL PROTECTED]:~$ Sid box: [EMAIL PROTECTED]:~$ ssh -l root 66.122.133.154 Password: Password: Password: [EMAIL PROTECTED]'s password: Permission denied, please try again. [EMAIL PROTECTED]'s password: Permission denied, please try again. [EMAIL PROTECTED]'s password: Permission denied (publickey,password,keyboard-interactive). [EMAIL PROTECTED]:~$ On Wed, 2004-06-16 at 08:43, Frank Niedermann wrote: Hello, I have a Debian testing server on my network with OpenSSH running. If I try to log in as root but with wrong password I get the following: [EMAIL PROTECTED] deniedfr $ ssh [EMAIL PROTECTED] Password: wrong password here Password: the same wrong password Password: the same wrong password [EMAIL PROTECTED]'s password: the same wrong password Last login: Wed Jun 16 17:03:11 2004 from dettnb80.tt.de.ifm dettlx18:~# uname -a Linux dettlx18 2.4.18-bf2.4 #1 Son Apr 14 09:53:28 CEST 2002 i686 GNU/Linux dettlx18:~# The /var/log/auth.log: sshd[1335]: (pam_securetty) access denied: tty 'ssh' is not secure ! sshd[1335]: (pam_unix) authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=dettnb80.tt.de.ifm user=root sshd[1333]: error: PAM: Authentication failure sshd[1336]: (pam_securetty) access denied: tty 'ssh' is not secure ! sshd[1336]: (pam_unix) authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=dettnb80.tt.de.ifm user=root sshd[1333]: error: PAM: Authentication failure sshd[1337]: (pam_securetty) access denied: tty 'ssh' is not secure ! sshd[1337]: (pam_unix) authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=dettnb80.tt.de.ifm user=root sshd[1333]: error: PAM: Authentication failure sshd[1333]: Failed keyboard-interactive/pam for root from 172.16.15.80 port 32896 ssh2 sshd[1333]: Accepted password for root from 172.16.15.80 port 32896 ssh2 sshd[1338]: (pam_unix) session opened for user root by root(uid=0) If I try to use 'x' as wrong password, ssh won't let me in: [EMAIL PROTECTED]'s password: Permission denied (publickey,password,keyboard-interactive). Just as I would expect it. If I use a longer or similar password as the real root password, ssh will let me log in, example: real root password = linux4me - success :) fake root password = fun4linux - success! :( The ssh package version: ii ssh 3.8p1-3 Secure rlogin/rsh/rcp replacement (OpenSSH) Any idea about that behavor? Regards, Frank -- Mail: [EMAIL PROTECTED] XMPP: [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: SSH permits root-Logins with wrong password
On Wed, 16 Jun 2004 10:35:33 Patrick Lane [EMAIL PROTECTED] wrote: I have a Debian testing server on my network with OpenSSH running. If I try to log in as root but with wrong password I get access... tried to duplicate this on a sid box and a sarge box (that hasn't been upgraded for awhile). I couldn't duplicate your results. I think my results are so strange because the wrong password contains parts of the right password. As I said, if I try to log in with 'x' as password I get the same results as you described. The sid box has ii ssh3.8.1p1-4 Secure rlogin/rsh/rcp replacement I've done an upgrade to the testing packages today after my posting to the list but ssh still is in version 3.8p1-3 ... I'll update the ssh package to unstable tomorrow at work and hope the problem will be gone but how can we be sure that there is no general issue about this version of sshd? Does it make sense to you to see my sshd-config? Or could this be a misconfigured pam or something like this? Regards, Frank -- Mail: [EMAIL PROTECTED] XMPP: [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: SSH permits root-Logins with wrong password
On Wed, 16 Jun 2004, Frank Niedermann wrote: On Wed, 16 Jun 2004 10:35:33 Patrick Lane [EMAIL PROTECTED] wrote: I have a Debian testing server on my network with OpenSSH running. If I try to log in as root but with wrong password I get access... tried to duplicate this on a sid box and a sarge box (that hasn't been upgraded for awhile). I couldn't duplicate your results. I think my results are so strange because the wrong password contains parts of the right password. As I said, if I try to log in with 'x' as password I get the same results as you described. Quick questions: (1) how long is the password?; and (2) is the variation you're trying at the end? some hash techniques limit password length and truncate the string after that point, so if you're changing or appending a character after that point you would get the behavior you describe. -- Andrew J Perrin - http://www.unc.edu/~aperrin Assistant Professor of Sociology, U of North Carolina, Chapel Hill [EMAIL PROTECTED] * andrew_perrin (at) unc.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: SSH permits root-Logins with wrong password
On 2004-06-16 at 16:02:59, Andrew Perrin wrote: I have a Debian testing server on my network with OpenSSH running. If I try to log in as root but with wrong password I get access... Quick questions: (1) how long is the password?; and (2) is the variation you're trying at the end? (1) password is 8 chars long (2) no it's not, example: correct password: one4two wrong password: three4one some hash techniques limit password length and truncate the string after that point, so if you're changing or appending a character after that point you would get the behavior you describe. this case does not apply with the two passwords used. Regards, Frank -- Mail: [EMAIL PROTECTED] XMPP: [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: SSH permits root-Logins with wrong password
I hate to ask, but: have you checked the MD5 sum for sshd? For the PAM library? -- Carl Fink [EMAIL PROTECTED] Jabootu's Minister of Proofreading http://www.jabootu.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
securité ssh login root
Bonjour, Pouvez-vous m'ouvrir l'esprit? ;o) En règle général, le login sous root est déconseillé en dehors d'une console locale sous surveillance. Même pour SSH, j'ai lu qu'il était conseillé de désactiver la connexion sous root et d'utiliser 'sudo' pour autoriser certaines actions à un utilisateur accrédité. Si je dois administrer une machine à distance avec SSH, quelle amélioration de la sécurité puis-je espérer avec ce principe? Un quidam peut arriver à truander le système, faire usage de mon userid et bénéficier des droits que j'ai grâce à 'sudo'. De même, '/etc' n'est pas protégé en lecture et les fichiers de configurations sont lisibles. Il aura donc un catalogue des droits qui me sont attribué par 'sudo'? Merci à vous et joyeuses fêtes à tous. Patrick __ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/
Re: securité ssh login root
Patrick wrote: Bonjour, Pouvez-vous m'ouvrir l'esprit? ;o) En règle général, le login sous root est déconseillé en dehors d'une console locale sous surveillance. Même pour SSH, j'ai lu qu'il était conseillé de désactiver la connexion sous root et d'utiliser 'sudo' pour autoriser certaines actions à un utilisateur accrédité. Si je dois administrer une machine à distance avec SSH, quelle amélioration de la sécurité puis-je espérer avec ce principe? Et bien il faudra deja que le quidam casse 2 mots de passes: celui du user, ensuite celui de root. Un quidam peut arriver à truander le système, faire usage de mon userid et bénéficier des droits que j'ai grâce à 'sudo'. Non, s'il n'a pas le mot de passe. De même, '/etc' n'est pas protégé en lecture et les fichiers de configurations sont lisibles. Il aura donc un catalogue des droits qui me sont attribué par 'sudo'? Admettons qu'il ai reussi a obtenir le mot de passe root. Crois tu vraiment que c'est *que* pour lire /etc ;-)? Merci à vous et joyeuses fêtes à tous. Donc ce que je fais: 1) tres peu de comptes user sur une machine sensible 2) pas d'acces root par ssh 3) les mots de passe user sont changes *tous* les mois 4) les mots de passe font minimum 8 caracteres, melangent chiffres et lettres, majuscules et minuscules 5) pour ceux qui se connectent par ssh, installation de leur cle publique sur le serveur. Donc plus de saisie de mot de passe user donc s'il y a un sniffer ... perdu ;-) 6) si le user a ses mails sur la machine, rediriger les mails user console vers ceux de user/mail accede avec un _autre_ mot de passe. Ca ne sert a rien de fermer toutes les portes au niveau console s'il suffit de sniffer pop3 pour voir circuler le mot de passe en clair! Bonnes fetes a toi aussi. -- : __ __ __ __ __ __ [EMAIL PROTECTED] : /_// __ // __ //_// __ // / phone.: +48 32 285 5276 : / / / /_/ // /_/ / / / / /_/ // / fax: +48 32 285 5276 : /_/ /_//_/ /_/ /_/ /_//_/ mobile..: +48 602 284 546
Re: securité ssh login root
Patrick wrote: Bonjour, Pouvez-vous m'ouvrir l'esprit? ;o) En règle général, le login sous root est déconseillé en dehors d'une console locale sous surveillance. Même pour SSH, j'ai lu qu'il était conseillé de désactiver la connexion sous root et d'utiliser 'sudo' pour autoriser certaines actions à un utilisateur accrédité. Si je dois administrer une machine à distance avec SSH, quelle amélioration de la sécurité puis-je espérer avec ce principe? Et bien il faudra deja que le quidam casse 2 mots de passes: celui du user, ensuite celui de root. Un quidam peut arriver à truander le système, faire usage de mon userid et bénéficier des droits que j'ai grâce à 'sudo'. Non, s'il n'a pas le mot de passe. De même, '/etc' n'est pas protégé en lecture et les fichiers de configurations sont lisibles. Il aura donc un catalogue des droits qui me sont attribué par 'sudo'? Admettons qu'il ai reussi a obtenir le mot de passe root. Crois tu vraiment que c'est *que* pour lire /etc ;-)? Merci à vous et joyeuses fêtes à tous. Donc ce que je fais: 1) tres peu de comptes user sur une machine sensible 2) pas d'acces root par ssh 3) les mots de passe user sont changes *tous* les mois 4) les mots de passe font minimum 8 caracteres, melangent chiffres et lettres, majuscules et minuscules 5) pour ceux qui se connectent par ssh, installation de leur cle publique sur le serveur. Donc plus de saisie de mot de passe user donc s'il y a un sniffer ... perdu ;-) 6) si le user a ses mails sur la machine, rediriger les mails user console vers ceux de user/mail accede avec un _autre_ mot de passe. Ca ne sert a rien de fermer toutes les portes au niveau console s'il suffit de sniffer pop3 pour voir circuler le mot de passe en clair! Bonnes fetes a toi aussi. -- : __ __ __ __ __ __ [EMAIL PROTECTED] : /_// __ // __ //_// __ // / phone.: +48 32 285 5276 : / / / /_/ // /_/ / / / / /_/ // / fax: +48 32 285 5276 : /_/ /_//_/ /_/ /_/ /_//_/ mobile..: +48 602 284 546
Re: securité ssh login root
Le 12409ième jour après Epoch, [EMAIL PROTECTED] écrivait: Bonjour, Pouvez-vous m'ouvrir l'esprit? ;o) Je n'ai pas cette prétention, alors si quelqu'un pouvait me relire et me corriger, je serais ravi. En règle général, le login sous root est déconseillé en dehors d'une console locale sous surveillance. Oui, ça évite d'avoir des droits sur une machine depuis un endroit différent d'où est le clavier. Même pour SSH, j'ai lu qu'il était conseillé de désactiver la connexion sous root et d'utiliser 'sudo' pour autoriser certaines actions à un utilisateur accrédité. Pas forcément. Tu peux aussi interdire l'accès par mot de passe et forcer l'échange de clefs. Dans l'absolu c'est la règle de ma première réponse qui s'applique. Mais si tu autorises l'accès à un user avec le droit de faire des 'sudo', alors le vilain craker essayera de faire pareil. Si je dois administrer une machine à distance avec SSH, quelle amélioration de la sécurité puis-je espérer avec ce principe? Un quidam peut arriver à truander le système, faire usage de mon userid et bénéficier des droits que j'ai grâce à 'sudo'. Clair. Dans cette situation, le principe d'obligation de clefs SSH est à mon avis un bon niveau de sécurité. A condition évidemment que la machine à partir de laquelle tu fais ça soit protégée. Tu peux aussi pousser le vice (la parano) jusqu'à stocker la clef SSH sur une clef USB. De même, '/etc' n'est pas protégé en lecture et les fichiers de configurations sont lisibles. Il aura donc un catalogue des droits qui me sont attribué par 'sudo'? Oui, mais si ces droits sont assez restrictifs, il ne pourra rien faire. La sécurité par l'obscurantisme n'est pas une bonne sécurité. -- The good oxymoron, to define it by a self-illustration, must be a planned inadvertency. -Wilson Follett
Re: securité ssh login root
OoO En cette nuit striée d'éclairs du mardi 23 décembre 2003, vers 02:56, [EMAIL PROTECTED] (François TOURDE) disait: Clair. Dans cette situation, le principe d'obligation de clefs SSH est à mon avis un bon niveau de sécurité. A condition évidemment que la machine à partir de laquelle tu fais ça soit protégée. Tu peux aussi pousser le vice (la parano) jusqu'à stocker la clef SSH sur une clef USB. Cela ne protège pas de la compromission de la machine depuis laquelle tu te connectes. Il faudrait avoir un périphérique USB qui réponde lui même au challenge (à l'aide d'une clef qu'il garde en interne). Cela existe. Une solution pour se logguer depuis les machines non sûres est les One Time Password : le mot de passe utilisé ne peut être utilisé qu'une fois. Toutefois, cela reste simplement une protection contre les keyloggers ou assimilés. En effet, rien n'empêche un client ssh modifié de te présenter un prompt et de forker pour installer un rootkit en parallèle. Cela reste toutefois sans doute plus sûr que le mot de passe traditionnel. Enfin, PAM permet de combiner plusieurs moyens comme par exemple mot de passe classique et mot de passe à usage unique (utile si on se fait voler la liste de mots de passe). On peut imaginer développer des modules qui envoie le challenge par SMS sur un portable, ce serait sans doute assez original. :) -- BOFH excuse #82: Yeah, yo mama dresses you funny and you need a mouse to delete files. pgpzcLESbnqXN.pgp Description: PGP signature
Re: securité ssh login root
OoO En ce milieu de nuit étoilée du mardi 23 décembre 2003, vers 03:02, daniel huhardeaux [EMAIL PROTECTED] disait: Et bien il faudra deja que le quidam casse 2 mots de passes: celui du user, ensuite celui de root. sudo demande le mot de passe de l'utilisateur et noncelui de sudo. Cela est par contre vrai pour su. -- BOFH excuse #143: had to use hammer to free stuck disk drive heads. pgpyVBzVDRNrT.pgp Description: PGP signature
Re: securité ssh login root
OoO En cette nuit nuageuse du mardi 23 décembre 2003, vers 01:37, Patrick [EMAIL PROTECTED] disait: Un quidam peut arriver à truander le système, faire usage de mon userid et bénéficier des droits que j'ai grâce à 'sudo'. S'il parvient à obtenir ton mot de passe. Tu as de plus une meilleure traçabilité. De plus,sudo mémorisant les droits pendant quelques instants, cela t'évite de laisser traînerdes consoles root. Personnellement, j'ai pris l'habitude de tout faire via sudo, je pense que cela améliore sensiblement la sécurité. De même, '/etc' n'est pas protégé en lecture et les fichiers de configurations sont lisibles. Il aura donc un catalogue des droits qui me sont attribué par 'sudo'? /etc/sudoers n'est lisible que par root. -- Replace repetitive expressions by calls to a common function. - The Elements of Programming Style (Kernighan Plaugher) pgpMeJXjvLq7g.pgp Description: PGP signature
SSH w/ root and keypair authentication problem
I'm trying to create a backup script that will, when run, connect to another computer, and rsync all of its partitions into the local computer. In order to be able to rsync properly and copy all the files, the user logging in must be root. However, this poses a problem, as PermitRootLogin was no in sshd_config. So here is how I went about trying to solve the problem. First, some names. The source computer is called dh3. The target computer is dh2. On dh2, I ran: ssh-keygen -t rsa1 ssh-keygen -t rsa ssh-keygen -t dsa I chose the default values for all three, so I have 3 key files in /root/.ssh/, id_rsa, id_dsa, and identity, each with a corresponding .pub file. For each key, I chose an empty passphrase. Then, I coped the .pub files to dh3, and concatenated them all into /root/.ssh/authorized_keys. The authorized_keys file contains the three public keys, delimited by endlines. Here are the contents of sshd_config on dh3: dh3:~/.ssh# cat /etc/ssh/sshd_config # Package generated configuration file # See the sshd(8) manpage for defails # What ports, IPs and protocols we listen for Port 22 # Use these options to restrict which interfaces/protocols sshd will bind to #ListenAddress :: #ListenAddress 0.0.0.0 Protocol 2,1 # HostKeys for protocol version 2 HostKey /etc/ssh/ssh_host_rsa_key HostKey /etc/ssh/ssh_host_dsa_key # HostKey for protocol version 1 HostKey /etc/ssh/ssh_host_key # Lifetime and size of ephemeral version 1 server key KeyRegenerationInterval 3600 ServerKeyBits 768 # Logging SyslogFacility AUTH LogLevel VERBOSE # Authentication: LoginGraceTime 600 PermitRootLogin forced-commands-only StrictModes yes RSAAuthentication yes PubkeyAuthentication yes AuthorizedKeysFile %h/.ssh/authorized_keys # rhosts authentication should not be used RhostsAuthentication no # Don't read the user's ~/.rhosts and ~/.shosts files IgnoreRhosts yes # For this to work you will also need host keys in /etc/ssh_known_hosts RhostsRSAAuthentication no # similar for protocol version 2 HostbasedAuthentication no # Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication #IgnoreUserKnownHosts yes # To enable empty passwords, change to yes (NOT RECOMMENDED) PermitEmptyPasswords no # Uncomment to disable s/key passwords #ChallengeResponseAuthentication no # To disable tunneled clear text passwords, change to no here! PasswordAuthentication yes # Use PAM authentication via keyboard-interactive so PAM modules can # properly interface with the user PAMAuthenticationViaKbdInt yes # To change Kerberos options #KerberosAuthentication no #KerberosOrLocalPasswd yes #AFSTokenPassing no #KerberosTicketCleanup no # Kerberos TGT Passing does only work with the AFS kaserver #KerberosTgtPassing yes X11Forwarding no X11DisplayOffset 10 PrintMotd no #PrintLastLog no KeepAlive yes #UseLogin no #MaxStartups 10:30:60 #Banner /etc/issue.net #ReverseMappingCheck yes Subsystem sftp/usr/lib/sftp-server Note the use of PermitRootLogin forced-commands-only which should allow me to ssh in as root, using my keys, as long as I run a command afterwards. The actual command being run on dh2 (as root) is something to the effect of: ssh dh3.doggus.com rsync . Doing that, or substituting any command instead of rsync, results in dh3 asking me for a password for root@dh3. With the various -v options, more information is displayed, but I can't really understand any of it. Why isn't this keypair scheme working? Some ideas: 1) dh2 is behind a router, whereas dh3 is not. Not sure how this would affect ssh. 2) The format of authorized_keys on dh3 is incorrect somehow. Any ideas would be greatly appreciated. Thanks! -Adar Dembo PS: I'm not subscribed to debian-user, so please reply directly back to me. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: SSH w/ root and keypair authentication problem
* Adar Dembo ([EMAIL PROTECTED]) [021218 03:02]: I'm trying to create a backup script that will, when run, connect to another computer, and rsync all of its partitions into the local computer. In order to be able to rsync properly and copy all the files, the user logging in must be root. However, this poses a problem, as PermitRootLogin was no in sshd_config. So here is how I went about trying to solve the problem. First, some names. The source computer is called dh3. The target computer is dh2. On dh2, I ran: ssh-keygen -t rsa1 ssh-keygen -t rsa ssh-keygen -t dsa Just use one key, not 3. 3 keys is 3 times as many ways to get root on that other machine; your backup script only needs one. Let's just use -t rsa to make an ssh protocol version 2 rsa key. Note the use of PermitRootLogin forced-commands-only which should allow me to ssh in as root, using my keys, as long as I run a command afterwards. The actual command being run on dh2 (as root) is something to the effect of: ssh dh3.doggus.com rsync . No, that's not quite how it works. forced-commands-only will allow login with that key and will automatically execute the command listed in the authorized_keys file, ignoring anything specified on the ssh command line[*]. Your authorized_keys should look something like this: from=other.host,command=rsync --server something,no-port-forwarding,no-X11-forwarding,no-agent-forwarding ssh-rsa 1231241234123(key data) backup-key(comment) Just use one key, not 3, and set up some options to make it more secure, as in the above example. Invoke rsync from the client as rsync, which will try to use rsh (which is really ssh on your system, right? Or give rsync -e /usr/bin/ssh). That is to say you shouldn't be invoking ssh other host rsync something To figure out the rsync command to place in your authorized_keys file, use ssh -v to see the command rsync tries to run on the server side (it'll be rsync --server something) and stick that in the command= option in your authorized_keys. [*] The original command line is placed in SSH_ORIGINAL_COMMAND in the environment of the executed command. This can be used e.g. in a wrapper script that needs variable arguments: it can parse $SSH_ORIGINAL_COMMAND and use the args specified on the ssh command line. For a backup script, you shouldn't need variable arguments at all: it'll be run the same all the time (assuming you're always backing up the same directories). good times, Vineet -- http://www.doorstop.net/ -- One nation, indivisible, with equality, liberty, and justice for all. msg19916/pgp0.pgp Description: PGP signature
Re: SSH w/ root and keypair authentication problem
On Wed, Dec 18, 2002 at 03:00:43AM -0800, Adar Dembo wrote: Note the use of PermitRootLogin forced-commands-only which should allow me to ssh in as root, using my keys, as long as I run a command afterwards. Beware that 'PermitRootLogin forced-commands-only' was broken in 1:3.4p1-1, the version of ssh in stable. It was fixed in 1:3.5p1-1. See bug #166184. I haven't investigated your problem deeply enough to know if that's definitely the cause (sorry, work Christmas parties don't leave me entirely sober), but it seems like a pretty good candidate. Vineet's reply could be part of it too. Cheers, -- Colin Watson [[EMAIL PROTECTED]] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: connexion ssh en root sur debian
- Original Message - From: Philippe Marzouk [EMAIL PROTECTED] To: debian-user-french@lists.debian.org Sent: Sunday, November 18, 2001 3:15 PM Subject: Re: connexion ssh en root sur debian Le ven, 16 nov 2001 12:02:59, kamel a écrit : merci à tous, apres modif de sshd_config et kill 6HUP sur sshd, l'utilisateur root est accepter à réaliser des connexions ssh. maintenant une seconde question : je veux realiser des connexions ssh en utilisant mes clés public-privée. Je réalise mes connexions ssh avec le logiciel putty je crée mes clés avec puttykeygen et je travail avec l'agent pageant. sur mes serveur HP-UX, voici comment je procède: j'ai unrépertoire .ssh ou j'ai le fichier authorized_keys en chmod 600 je crée mes clés avec puttykeygen, je stocke la clé privée sur mon poste et je copie la clé public dans le fichier authorized_keys Si c'est du ssh v2, le fichier est authorized_keys2. En tout cas c'est ce que j'utilise chez moi. Philippe kamel : aujourdhui, tout fonctionne, connexion avec clé public-privée et exactement avec ce que j'avais écris précédement. Mon érreur était de croire que le répertoire d'acceuil de root était à la racine. voila, je vous remercie. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: connexion ssh en root sur debian
Le ven, 16 nov 2001 12:02:59, kamel a écrit : merci à tous, apres modif de sshd_config et kill 6HUP sur sshd, l'utilisateur root est accepter à réaliser des connexions ssh. maintenant une seconde question : je veux realiser des connexions ssh en utilisant mes clés public-privée. Je réalise mes connexions ssh avec le logiciel putty je crée mes clés avec puttykeygen et je travail avec l'agent pageant. sur mes serveur HP-UX, voici comment je procède: j'ai unrépertoire .ssh ou j'ai le fichier authorized_keys en chmod 600 je crée mes clés avec puttykeygen, je stocke la clé privée sur mon poste et je copie la clé public dans le fichier authorized_keys Si c'est du ssh v2, le fichier est authorized_keys2. En tout cas c'est ce que j'utilise chez moi. Philippe
connexion ssh en root sur debian
j'ai installé le package sshd, je réalise des connexions ssh mais en tant que root, pourtant j'ai supprimé le fichier securetty ainsi, comment fait on pour authoriser les connexions ssh sous root ? merci
Re: connexion ssh en root sur debian
On Fri, 2001-11-16 at 11:06, kamel wrote: j'ai installé le package sshd, je réalise des connexions ssh mais en tant que root, pourtant j'ai supprimé le fichier securetty ainsi, comment fait on pour authoriser les connexions ssh sous root ? merci dans /etc/ssh/sshd_config mettre : PermitRootLogin à 'yes' par defaut il est à 'no'. Olivier -- \\\ /// (ô ô) --ooO-(_)-Ooo- |AurorA-linux.com tel : +33 (0)1 58 17 03 20 | |69-71 Avenue Pierre Grenier92100 Boulogne-Billancourt | --
Re: connexion ssh en root sur debian
Le Fri, Nov 16, 2001 at 11:06:40AM +0100, kamel a écrit : j'ai installé le package sshd, je réalise des connexions ssh mais en tant que root, pourtant j'ai supprimé le fichier securetty Je pensse que tu veux te connecter en root par mot de passe, via ssh sur une machine. Le fichier /etc/securetty ne sert que pour telnet. Donc un man sshd nous donne : PermitRootLogin Specifies whether the root can log in using ssh(1). The argument must be ``yes'', ``without-password'' or ``no''. The default is ``yes''. If this options is set to ``without-password'' only password authentication is disabled for root. Root login with RSA authentication when the command option has been specified will be allowed regardless of the value of this setting (which may be useful for taking remote backups even if root login is normally not allowed). ainsi, comment fait on pour authoriser les connexions ssh sous root ? Il faut donc mettre PermitRootLogin yes dans le fichier /etc/ssh/sshd_config. Mais c'est deconseillé, car il y à d'autre méthodes pour ça : - Se loguer avec un autre utilisateur sur la machine et faire un su -. Dans ce cas on sait grace aux logs qui est passé root sur la machine. - Comme le point précédent mais faire un sudo la commande, dans ce cas on sait qui à fait quoi en tant que root. - Creer une clé avec ssh-keygen en tant que root sur la machine de dapart, transferer le fichier identity.pub sur la machine de destination. Ajouter la ligne de ce fichier dans le fichier ~/ssh/authorized_keys sur la machine de destination. Cette méthode est utile pour des connection sans mot de passe. Par exemple pour des script de backup... merci Pas de quoi... -- Quand un imbecile fait quelque chose dont il a honte, il affirme toujours que c'est son devoir. -- George Bernard Shaw Nicolas Ledez - Virtual Net (www.virtual-net.fr)
Fw: connexion ssh en root sur debian
- Original Message - From: kamel [EMAIL PROTECTED] To: Fabrice Cartron [EMAIL PROTECTED] Sent: Friday, November 16, 2001 11:22 AM Subject: Re: connexion ssh en root sur debian apres avoir modifier le /etc/ssh/sshd_config et rajouté PermitRootLogin yes j'ai effectué un kill -HUP sur sshd pourtant à chaque demande de connexion en tant que root, j'ai Access denied voici mon fichier de configuration ssh_config Host * # ForwardAgent no # ForwardX11 no RhostsAuthentication no # RhostsRSAAuthentication yes # RSAAuthentication yes # PasswordAuthentication yes # FallBackToRsh no # UseRsh no # BatchMode no # CheckHostIP yes StrictHostKeyChecking yes # IdentityFile ~/.ssh/identity # Port 22 # Cipher blowfish # EscapeChar ~ PermitRootLogin yes merci merci - Original Message - From: Fabrice Cartron [EMAIL PROTECTED] To: kamel [EMAIL PROTECTED] Cc: debian-french@lists.debian.org Sent: Friday, November 16, 2001 10:51 AM Subject: Re: connexion ssh en root sur debian En réponse à kamel [EMAIL PROTECTED]: j'ai installé le package sshd, je réalise des connexions ssh mais en tant que root, pourtant j'ai supprimé le fichier securetty ainsi, comment fait on pour authoriser les connexions ssh sous root ? merci dans /etc/ssh/sshd_config PermitRootLogin yes -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] Fabrice Cartron APM-online www.apm-online.fr -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: connexion ssh en root sur debian
Bonjour, voici mon fichier de configuration ssh_config Non, non, il faut modifier le fichier sshd_config, pas ssh_config, qui lui est un fichier type de configuration de client ssh ! Cordialement, Laurent PETIT.
Re: connexion ssh en root sur debian
merci à tous, apres modif de sshd_config et kill 6HUP sur sshd, l'utilisateur root est accepter à réaliser des connexions ssh. maintenant une seconde question : je veux realiser des connexions ssh en utilisant mes clés public-privée. Je réalise mes connexions ssh avec le logiciel putty je crée mes clés avec puttykeygen et je travail avec l'agent pageant. sur mes serveur HP-UX, voici comment je procède: j'ai unrépertoire .ssh ou j'ai le fichier authorized_keys en chmod 600 je crée mes clés avec puttykeygen, je stocke la clé privée sur mon poste et je copie la clé public dans le fichier authorized_keys ensuite, je lance pageant en lui indiquant la localisation de ma clé privée. enfin je fais ma connexion ssh avec putty sans que le serveur ma demande de m'authentifier. j'ai réalise la même opération sur mon serveur debian, et ca na fonctionne pas. qq1 utilise-t-il les logicile putty pour réaliser ses connexions ssh avec échange de clé ? La ou je suis perdu, c'est que cela fonctionne sur mes HP-UX. merci PS : si je n'y arrive pas, j'essairait de créer mes clé avec keygen sur le serveur ssh. merci - Original Message - From: Laurent PETIT [EMAIL PROTECTED] To: kamel [EMAIL PROTECTED]; debian-french@lists.debian.org Sent: Friday, November 16, 2001 12:43 PM Subject: Re: connexion ssh en root sur debian Bonjour, voici mon fichier de configuration ssh_config Non, non, il faut modifier le fichier sshd_config, pas ssh_config, qui lui est un fichier type de configuration de client ssh ! Cordialement, Laurent PETIT. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ssh as root
You can't connect to another box with ssh using the root account. It's a security feature. The default is to use your current username, which would be root in this instance. A way to get around this is with the -l option and then su on the remote box. So, #ssh -l user_name_to_login_as remotehost I don't use scp directly, but I use sftp, and it supports the -l option also. [EMAIL PROTECTED] wrote: I'm curious if this is a bug or a config option or am i smoking crack. I have 2 identical (more or less) potato systems, and wanted to scp a tar file to the other machine. the command was: # scp /tmp/filename.tar [EMAIL PROTECTED]:/tmp I get ssh_exchange_identification: Connection closed by remote host lost connection when i exit back out of the su, it connects fine. since i am not logging in as root i don't understand why it would(if it is) drop the connection. i checked the sshd_config and it looked ok ..i don't have identd running on either host, maybe SSH is telling the remote system what user i am? somehow i would think that would be bad if it was. or maybe my crackpipe needs cleaning .. any ideas?? thanks! nate ::: http://www.aphroland.org/ http://www.linuxpowered.net/ [EMAIL PROTECTED] 5:55pm up 88 days, 3:13, 2 users, load average: 0.00, 0.02, 0.00 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- It's a shame that a family can be torn apart by something as simple as wild dogs.
ssh as root
I'm curious if this is a bug or a config option or am i smoking crack. I have 2 identical (more or less) potato systems, and wanted to scp a tar file to the other machine. the command was: # scp /tmp/filename.tar [EMAIL PROTECTED]:/tmp I get ssh_exchange_identification: Connection closed by remote host lost connection when i exit back out of the su, it connects fine. since i am not logging in as root i don't understand why it would(if it is) drop the connection. i checked the sshd_config and it looked ok ..i don't have identd running on either host, maybe SSH is telling the remote system what user i am? somehow i would think that would be bad if it was. or maybe my crackpipe needs cleaning .. any ideas?? thanks! nate ::: http://www.aphroland.org/ http://www.linuxpowered.net/ [EMAIL PROTECTED] 5:55pm up 88 days, 3:13, 2 users, load average: 0.00, 0.02, 0.00
