Archives par mot-clé : ssh

Supprimer une clé SSH de ses hôtes connus

Publié le par
Répondre

J’ai profité de mes récentes migrations de serveur pour re-générer des clés SSH toutes neuves. Je ne pense pas avoir été piraté ni visité depuis que je tiens ce blog mais de temps en temps, une petite remise à frais de la sécurité ne fait pas de mal.

Remise à frais de la sécurité implique que tous mes shells, qui avaient enregistrés l’ancienne clé SSH, détectaient une modification et pensaient à un piratage. Il fallait donc enlever l’ancienne clé de la base des hôtes connus.

On peut faire ça manuellement en modifiant le fichier ~/.ssh/known_hosts mais il faut être sûr de soi quant-à la ligne que l’on enlève. Pas toujours évident.

La manière la plus simple est la commande :

ssh-keygen -f "/home/<USERNAME>/.ssh/known_hosts" -R <NOM_DU_DOMAINE_OU_ADRESSE_MACHINE>

qui se charge d’enlever la clé SSH correspondante à la machine que l’on vise sans risquer d’enlever la mauvaise clé. Il ne reste plus qu’à se connecter de nouveau et les nouvelles informations de connexion seront ajoutées à la liste des hôtes connus.

Désactiver la commande sudo

Publié le par
1

Pour l’administration de mes serveurs, afin d’éviter tout risque de piratage, il est nécessaire d’avoir 2 mots de passe pour effectuer des commandes root.

Imaginons que notre compte utilisateur a accès à la fonction sudo, comme c’est le cas du première utilisateur créé dans la plupart des distributions GNU/Linux, et que le mot de passe de connexion en SSH est le mot de passe de ce compte. Si quelqu’un arrive à prendre connaissance du mot de passe lors de la connexion (keylogger, regard indiscret, …), il pourra ensuite se reconnecter et avoir un contrôle total du serveur distant.

Afin d’éviter cela, nous allons désactiver la fonction sudo pour l’utilisateur en question. Ainsi, pour effectuer des commandes administrateurs, il faudra se connecter préalablement en tant que super utilisateur.

On changera aussi le mot de passe du super utilisateur pour qu’il soit différent de celui du compte de l’utilisateur, sinon ceci n’a aucun intérêt.

Pour changer le mot de passe de root, rien de plus simple :

  • Si il a déjà été fixé, il suffit de faire
su
passwd

et de taper son nouveau mot de passe.

  • Si il n’a jamais été fixé, il faut se connecter avec un utilisateur possédant le droit d’utilisation de la fonction sudo et faire :
sudo su
passwd

et de taper le nouveau mot de passe.

Maintenant que nous sommes sûr d’avoir un utilisateur root avec un mot de passe que l’on connait, on va désactiver la fonction sudo. Pour ceci plusieurs possibilités :

  • Désinstaller purement et simplement la fonction sudo avec :
apt-get purge sudo
  • Modifier le fichier /etc/sudoers et commenter/supprimer les lignes correspondantes aux utilisateurs. Vous pouvez choisir de laisser ou d’enlever root du fichier. L’intérêt de le laisser est de na pas avoir une erreur lorsque, machinalement, on tape sudo alors qu’on est connecté en root. L’enlever vous forcera à bien séparer les commandes administrateurs des commandes utilisateur dans votre tête. Une autre solution pour se forcer est de retirer la commande sudo du path de l’utilisateur root. Ne connaissant plus la commande sudo, il indiquera systématiquement une erreur.

Il ne reste plus qu’à valider les changements soit en redémarrant la machine, soit à l’aide de la commande :

/etc/init.d/sudo restart

Comment personnaliser sa bannière de connexion SSH

Publié le par
Répondre

Lorsque l’on se connecte à son serveur en SSH, on a souvent un texte de base contenant des informations sur le serveur. Nous allons ici personnaliser le texte affiché.

La première étape consiste à activer la bannière dans le fichier de configuration d’openSSH. Pour ce faire, on va dans /etc/ssh/ et on modifie le fichier sshd_config. On décommentera la ligne :

#Banner /etc/issue.net

ou on la créera si elle n’y est pas. L’URI indique le fichier qui contiendra notre message d’accueil. On peut modifier son emplacement si on le veut ou simplement utiliser celui qui existe déjà. Après modification du fichier de bannière, un redémarrage à l’aide de la commande

/etc/init.d/ssh restart

suffit à faire prendre en compte les modifications. La bannière est maintenant affichée dès qu’une demande de connexion est effectuée.

Configuration de mes connexions SSH

Publié le par
Répondre

J’administre tous mes serveurs (tous sous Linux) en ligne de commande. L’interface graphique consomme en effet beaucoup de ressources inutilement et n’est pas nécessaire pour seulement quelques accès par mois. De plus, la ligne de commande est plus puissante.

Pour me connecter simplement et en toute sécurité j’utilise le protocole SSH qui est parfaitement adapté à la situation. Voici les quelques configurations que j’applique systématiquement.

Je commence tout d’abord par me générer une paire de clés qui me serviront à me connecter par la suite. Cette étape peut n’être faite qu’une fois, puisqu’il suffira d’utiliser la même clé pour tous ses serveurs après. La commande est :

ssh-keygen -t rsa -b 2048

Ceci générera une paire de clés RSA de 2048 bits. Il suffit de suivre les instructions lors de la génération des clés pour mettre un mot de passe à ces clés. Je copie ensuite la clé publique générée dans <HOME>/.ssh/authorized_keys sur le serveur.

Je modifie ensuite le fichier /etc/ssh/sshd_config de la manière suivante pour appliquer mes réglages de sécurité (ATTENTION : sans accès physique à la machine, laisser le paramètre PasswordAuthentication à yes jusqu’à ce que la connexion soit réussie avec la clé, autrement il sera très contraignant d’arriver à se reconnecter) :

# Numéro du port en écoute sur lequel on se connecte
Port <NUMERO DE PORT>

# Vérifier que la version est bien la 2 car la version 1 avait une faille critique
Protocol 2

# Bannière affichée avant l’autorisation de connexion (Je le met rarement mais ça égaye un peu la console à la connexion)
#Banner /etc/issue.net

# Empêche la connexion directe en root
# N’empêche pas de se connecter en root depuis un autre utilisateur
PermitRootLogin no

# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key

# Temps en seconde pendant laquelle une connexion est ouverte sans être loggué
LoginGraceTime 10

# Nombre maximum d’essais d’authentification autorisés
MaxAuthTries 1

#Types d’authentifications autorisés
PubkeyAuthentication yes
RSAAuthentication no
KerberosAuthentication no
GSSAPIAuthentication no
UsePAM no
PasswordAuthentication no

# Fichier contenant les clés autorisées
AuthorizedKeysFile %h/.ssh/authorized_keys

#Privilege Separation is turned on for security
UsePrivilegeSeparation yes

# Logging
SyslogFacility AUTH
LogLevel INFO

# check file modes and ownership of the user’s files and home directory before accepting login
StrictModes yes

# 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

# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication no

# Kerberos options
#KerberosAuthentication no
#KerberosGetAFSToken no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes

X11Forwarding yes
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
#UseLogin no
#MaxStartups 10:30:60

# Allow client to pass locale environment variables
AcceptEnv LANG LC_*

Subsystem sftp /usr/lib/openssh/sftp-server

# Set this to ‘yes’ to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication. Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of « PermitRootLogin without-password ».
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to ‘no’.

# La plupart du temps je n’autorise que mon compte à se connecter
AllowUsers <NOM_DES_UTILISATEURS_AUTORISES>

# Si il faut mettre plusieurs comptes, mieux vaut utiliser ceci
#AllowGroups <NOM_DU_GROUPE_AUQUEL_APPARTIENNENT_TOUS_LES_COMPTES_AUTORISES>

# On peut aussi choisir de refuser juste certains utilisateurs/groupes
#DenyUsers <NOM_DES_UTILISATEURS_REFUSES>
# DenyGroups <NOM_DU_GROUPE_AUQUEL_APPARTIENNENT_TOUS_LES_COMPTES_REFUSES>

Une fois ce fichier modifié, je relance ssh à l’aide de :

/etc/init.d/ssh restart

et me voilà avec un serveur disposant d’une connexion SSH correctement sécurisée.