Reponse de Anonymous sur configuration SSH

Tags: #<Tag:0x00007fb417c33520>

Bonjour a tous et a Anonymous @AnonymousCoward

Vu que tu as répondu tantôt

La question était au sujet de la configuration SSH dont tu m’avais conseiller de faire …
Ayant encore des lacunes a ce sujet: j’ai laisser en suspend :alien: :no_mouth:

Voila ceci était ta réponse et mes questions !!

Et ensuite, depuis ton mac, tu peux utiliser une commande telle que

ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no admin@192.168.55.33

Bonjour cher Anonymous
comment ca va depuis tout ce temps?

Apparement ici cette commande me permet de créer un fichier de données des utilisateurs sous le périphérique " null"et interdire tout nouvel utilisateur
J’ai reçu un tuto pour ssh sur netcadad mais très basique

je peux effacer aussi le contenu dans le fichier ~/.ssh/known_hosts ???
*Je peux aussi éditer avec nano les files ssh et sshd _config ??

C’est assez brouiller pour le moment , et la formation NDG est très très light au sujet du chapitre Network Configuration
:pleading_face: :grimacing: :triumph: :alien: :alien:

désoler j’en repose d’autres

  1. /dev/null est un fichier ?? on dirait un périphérique
    je dois créer un fichier dans ce fichier ?? /dev/null il y a déja un fichier ~/.ssh/knownhosts ?

UserKnownHostsFile :Est un fichier d’utilisateur connus qui peuvent accéder or ce je n’ai rien configurer et je retrouve des clés RSA dans le fichier dédier avec je pense un « User name » bizarre
StrictHostKeyChecking: Permet d’ajouter de nouvelles cléfs RSA suivant oui non ou null
il y des restrictions ou pas …

2)Vu que j’ai j’essayer de tester des connections avec d’autres Hosts y a pas d’accès donc a premières vues
il n’y a rien qui a été configurer … … MAIS HMMM je suis sceptique
Mais je ne comprend pas toutes les options aussi.
surtout -J plus [:port] :no_mouth: :expressionless: :alien:

Faut avoir de multiple Users qui ont on une cléfs RSA stocker dans une files dans /etc/ssh/known_hosts et qui « MATCH » ??
C’est assez confus surtout que plusieurs DIR /var ou /lib ou /usr contiennent des files ssh dans les Logs aussi ???
Quels fichiers configurer exactement ???
Est ce ma CMD ssh +user@hostname est valable faut il ajouter un ip non si car j’essaye dans ma propre VM?

Est ce qu’il n’y a vraiment aucun accès via u autre user ?qui peut taper « user@hostname » et taper mon code
qui est très basique vu que c’est une VM
Apparement je n’ai pas de configuration de base pour le root ce qui est normal apparement sur debian??
Je dois utiliser un autre user root avec sudo su mais apparement je n’ai pas les super privilèges …

Mais je vois que c’est important pour la sécurité de ma VM , et si ca se trouve j’ai laisser des accès libre
comme le spécifie RKHunter sous les Fichiers ici en captures

Capture d’écran 2024-09-11 à 19.12.25
Capture d’écran 2024-09-11 à 19.12.33
Capture d’écran 2024-09-11 à 19.12.41
Capture d’écran 2024-09-11 à 19.13.08
Capture d’écran 2024-09-11 à 19.13.25
Capture d’écran 2024-09-11 à 19.13.37
Capture d’écran 2024-09-11 à 19.14.31
Capture d’écran 2024-09-11 à 19.17.09

Surtout que mnt avec le peu de savoir je sais voyager dans les répertoire et fichier et je trouve des trucs bizarres des fichiers de comp musicales , des info sur des prises de photos , des trucs que je comprend pas ce qu’ils foutent la ???
Surtout que j 'ai installer cette VM pour les cours et formations
J’ai l’impression que d’autres user ont accès a cette VM

Voila cher @AnonymousCoward
désoler pour le pavé que je t’ai envoyer
mais j’essaye de comprendre et je reçoit un flux nombreux d’infos et comme je suis perfectionniste
je sature un peu

Merci a tous pour les conseils

Oui, comme la totalité des fichiers présents dans /dev , c’est un périphérique. « dev » comme dans « device ».

On peut le voir avec :

$ ls -l /dev/null
crw-rw-rw- 1 root root 1, 3 Aug  1 11:30 /dev/null

Ici, le C en tout début de ligne indique que c’est un périphérique de type « character », par opposition aux périphériques de type « block » comme celui qui peut représenter un disque dur.
Il y a une référence de ces périphériques ici : kernel.org , devices.txt .

En l’occurrence, /dev/null est comme un trou noir. Ce que l’on y écrit est oublié et lorsque l’on tente de lire son contenu, on obtient rien : zéro octets.

Cela permet de faire croire à ssh que le ficher contenant la liste des hôtes déjà connus est totalement vide et que l’on ne peut donc pas vérifier l’identité de la machine ( ici 192.168.55.33 ).
Et que ssh écrive l’identité de la machine dans le fichier /dev/null , c’est à dire qu’il passe l’information à la trappe .


AnonymousCoward

:ok_hand: :+1: :+1: :+1: :+1:
Super excellente réponse
c’est un script avancé c’est pour cela que je n’ai pas compris pourquoi mettre cela dans un repertoire /dev/null
a contrario de ~/. ssh:known_hosts qui garde les logs empreintes rsa ou autres …
Ok c’est plus clair
merci c’est cool

Bonjour,
Pour la configuration de ton ssh et des fichiers relatifs:
$HOME/.known_hosts c’est le fichier qui conserve les empreintes des ordinateurs auquel un user s’est connecté. Si un des serveurs change d’empreinte il y a une alerte qui est affichée lors de la tentative de connection. Il faut donc se préoccuper si c’est un serveur qu’on ne controle pas et contacter l’admin su serveur en question.

Cotés paramètres, il est préférable de mettre ses propres paramètres dans un fichier /etc/sshd_config.d/maconfig.conf (ou autre nom).
voici des conseils de paramétrages relatif à l’amélioration de la sécurité de la configuration du serveur SSH (issue de CIS Workbench et d’ailleurs):

Vérifier que /etc/ssh/sshd_config et les fichiers se terminant par . conf dans le répertoire /etc/ssh/sshd_config. d sont :

  • Mode 0600 ou plus restrictif
  • Propriété de l’utilisateur root
  • Groupe appartenant à la racine du groupe.

Vérifier que les fichiers de clé hôte privée SSH appartiennent à l’utilisateur root et :

  • appartenant à la racine du groupe et au mode 0600 ou plus restrictif

Ou

  • appartenant au groupe désigné pour posséder les clés privées openSSH et le mode 0640 ou plus restrictif

Vérifier que les fichiers de clés d’hôte publique SSH sont en mode 0644 ou plus restrictifs, appartenant à l’utilisateur root et au groupe root

AllowUsers <userlist>
 - ET/OU -
AllowGroups <grouplist>

S’assurer que l’accès sshd est configuré

sshd -T | grep -Pi -- '^\h*(allow|deny)(users|groups)\h+\H+'

Vérifier que la sortie correspond à au moins une des lignes suivantes :

allowusers <userlist>
-Ou-
allowgroups <grouplist>
-Ou-
denyusers <userlist>
-Ou-
denygroups <grouplist>

S’assurer que la banière est configurée (option Banner)
Ex:

banner /etc/issue.net

Ciphers: n’utioliser que des algo fiables:

Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr

Vérifier que ClientAliveInterval et ClientAliveCountMax sont supérieurs à zéro :

clientaliveinterval 15
clientalivecountmax 3

Désactiver le forwarding:

DisableForwarding yes

Vérifier que GSSAPIAuthentication est défini sur no :

GSSAPIAuthentication no

S’assurer que l’authentification de base d’hôte sshd est désactivée:

HostbasedAuthentication no

S’assurer que sshd IgnoreRhosts est activé:

IgnoreRhosts yes

Utiliser des algos fiables pour KexAlgorithms:

KexAlgorithms -diffie-hellman-group1-sha1,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1

Configurer le temps de login:

LoginGraceTime 60

Configurer les logs:

LogLevel VERBOSE
   - Ou -
LogLevel INFO

Utiliser des algos MACs fiables:

MACs -hmac-md5,hmac-md5-96,hmac-ripemd160,hmac-sha1-96,umac-64@openssh.com,hmac-md5-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,umac-64-etm@openssh.com,umac-128-etm@openssh.com

S’assurer que la maximum de tentatives de connexion est configuré:

MaxAuthTries 4

S’assurer que le nombre maximum de sessions de connexion est configuré:

MaxSessions 10

S’assurer que le nombre maximum de sessions concurrentes de connexion est configuré:

MaxStartups 10:30:60

Désactiver les mot de passe vide:

PermitEmptyPasswords no

Désactiver l’accès distant à l’utilisateur root:

PermitRootLogin no

Désactiver les environnements utilisateurs (distants):

PermitUserEnvironment no

Utiliser PAM pour sshd:

UsePAM yes

Voilà c’est tout pour SSH, mais il ne faut pas oublier qu’il y a aussi d’autres configuration périphériques de sécurité concernant:

  • PAM
  • SUDO
  • SU
  • Les comptes utilisateurs et leurs environnements

Et bien sur le Parefeu.
Si la machine le permet, un IDS comme suricata est aussi utile, allié aux outils apparmor, auditd et aide.

2 J'aime

Lors de l’installation de Debian, on peut entrer un mot de passe pour le compte root lorsque c’est demandé, ou l’on peut ne rien entrer.
Dans le cas où l’on ne saisit pas de mot de passe pour root, l’utilisateur que l’on crée à l’étape suivante est automatiquement configuré pour pouvoir faire appel à sudo.

Par exemple, si le mot de passe root a été défini sur la machine distante, tu peux te connecter en root sur cette machine avec :

$ ssh samberman88@192.168.55.33
samberman88@machine:~$ su -l
# entrer le mot de passe du user root
root@machine:~#

Et si le mot de passe root n’a pas été défini sur la machine distance, tu peux :

$ ssh samberman88@192.168.55.33
samberman88@machine:~$ sudo -i
# entrer le mot de passe du user samberman88
root@machine:~#

Si tu utilises la commande id alors que tu est connecté, tu peux voir la liste des groupes dont l’utilisateur fait partie. Si cette liste contient le groupe sudo, tu dois pouvoir utiliser cette commande.


AnonymousCoward

1 J'aime

Il est d’ailleurs préférable d’avoir un mot de passe pour root et du’iliser un configuration pam + groupe su pour accéder à l’utilisation de su.

Ok super mnt je commence à comprendre un petit peu mieux
avec cette formation que je viens de terminer

Bon mnt je vois que vous maîtrisez des super cmd :ok_hand:

je vais ici repartir sur deux formations networking cisco
avant de refaire la formation linux NDG introduction part 1
je pense que d’ici la fin automne je pourrais configurer un micro réseau local ,un pare feu ,un vpn, etc
avec ma VM
et j’espère attacker la cybersécurité pour l’hiver a venir
Merci Zargos c’est bien expliquer en détail
Super cool

oui comme ca été un peu chaotique lors de cette installation
Mnt je ne me rappelle plus ou je n’ai pas compris les differences entre user super user et les mots de passes et d’ailleurs ce que j’ai écrit comme passwd
Bon sudo su fonctionne mais pas su -
su -l niet su -i fctionne
j’ai essayer de me connecter de mon hôte a la vm il est indiquer :
connect to host … port 22: Operation timed out
Puis de ma vm a mon hôte :
connect to host …port 22 :Connection refused

.

les DIR ssh_config.d et sshd_config.d sont en mode 0755 root root
les fichiers /etc/ssh/*_config sont en 0655 root root

les fichiers /etc/ssh/ *_key sont en 0600 root root
les fichiers/etc/ssh/ *_key.pub sont en 0644 root root
voila pour commencer après je vais voir

tu as regardé du coté du parefeu de ton hote?
Sur quel réseau tu te connectes de ta VM vers ton hôte?
Si c’est du VirtualHost et le réseau virtuel host-only (vboxnet0 par défaut pour le premier) tu ne peux pas te connecter de la VM vers le host, c’est uniquement fait pour se connecter du host vers la VM. Prends ça pour un réseau d’administration.

A priori, là aussi regarde ton parefeu.

Dans les deux cas, regardes aussi les logs pour ce que tu as.

Comme l’a indiqué Zargos, cela semble être des problèmes de parefeu.

Apple explique comment ouvrir l’accès SSH sur son mac .


AnyonmousCoward