Secure Shell

Là c'est du lourd, non c'est très simple surtout quand on va pas voir les détails, pour resumer et rester très simple, il faut :

  • [ ] Une clé standard
  • [ ] Une clé robuste
  • [ ] Etre sérieux avec sa clé privée et sa pass-phrase
  • [ ] Etre de nouveau sérieux avec les configurations des serveurs
  • [ ] Avoir un agent-ssh

qui suis-je ?

Bon si on va dans les détails, RSA,DSA,EdDSA cela se complique très vite. RSA très bien pour la compatibilité mais il faut au moins une clé de 2048, DSA n'est plus actif dans openssh depuis la version 7.0 et pour EdDSA qui sur le papier est semble t'il aussi bien que ces petit copins en étant plus légé, en cherchant un peu il semble que la NSA aurait quelque facilité. Du coup restons classique et facile avec RSA.

ssh-keygen -t rsa -b 2048 -C persokey -f ./id_rsa

Deux beau fichier, id_rsa et id_rsa.pub, cela commence à devenir sérieux. Les deux premiers item sont ok, clé standard et robuste, maintenant la clé privée, première chose vérifier que le mode de fichier est bien 600 et il va de soit que la pass-phrase est suffisamment complexe. Une très bonne option est de mettre cette clé dans l'espace du coffre-fort.

Les serveurs openssh

Encore une fois je ne suis pas un spécialiste de la sécurité, ce que je donne comme informations me semble évidentes mais reste à ma seule appréciation. Il faut de façon raisonnable s’autoriser ce dont on a besoin et bloquer le reste.

Ce dont j'ai besoin :

  1. connexion en certificats RSA uniquement.
  2. port classique ou pas suivant l'exposition du serveur
  3. en root ( oui je sais c'est pas le mieux )
  4. rebonds autorisés
  5. tracer les connexions
  6. Un belle bannière

Ce que je ne veux pas !

  1. Le "forwarding" des ports, X11 etc ...
  2. la possibilité de connexion par mot de passe.
  3. Un prise de contrôle trop importante ( variable env etc ...)

je ne précise que les lignes qui sont modifiées ou à modifier du fichier sshd_config

# Pour un serveur exposé sur internet ou en interne il faut absolument changer le port d'ecoute
#Port 22  
# 0.0.0.0 toutes sinon limiter a celle d'utile si plusieurs carte réseaux
#ListenAddress 0.0.0.0  
#ListenAddress ::  
# Logging  
SyslogFacility AUTH  
LogLevel VERBOSE  
# Authentication:  
LoginGraceTime 30  
PermitRootLogin prohibit-password 
StrictModes yes  
MaxAuthTries 3
MaxSessions 2

PubkeyAuthentication yes  

# Don't read the user's ~/.rhosts and ~/.shosts files  
IgnoreRhosts yes  

# To disable tunneled clear text passwords, change to no here!  
PasswordAuthentication no
PermitEmptyPasswords no  

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

# Kerberos options  
KerberosAuthentication no  

# GSSAPI options  
GSSAPIAuthentication no

# PAM
UsePAM no

AllowAgentForwarding yes  
AllowTcpForwarding no  
GatewayPorts no  
X11Forwarding no

PermitTTY yes  
PrintMotd no  
PrintLastLog yes  
PermitUserEnvironment yes
PermitTunnel no  

# banner path  
Banner /etc/issue

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

Diffusion

Avant de valider ce nouveau mode de fonctionnement, il faut diffuser notre clé RSA sinon après plus possible de se connecter avec un mot de passe en ssh puisque l'option PermitRootLogin prohibit-password sera activé, alors avant de relancer le service sshd, on utilise ssh-copy-id

ssh-copy-id -i /media/veracrypt1/Keys/id_rsa.pub root@192.168.1.245

Avec le chemin de la clé à diffuser, ici sur un dossier particulier dans un volume chiffré et la cible avec son utilisateur.

Si jamais cela tourne mal avec le serveur openssh, il faut se connecter en physique sur le serveur ou par console si sous proxmox.

Petit bonus avec le fichier de bannière, il y a de très beau fichier réalisé en Ascii art.

ssh_capture

un agent ssh

Ok, nos serveurs openssh sont sous contrôle avec une configuration et une clé en place. Pour lier tout cela on va utiliser l'agent ssh sous linux ou windows. Il faut juste le nourrir avec :

ssh-add /media/veracrypt1/Keys/id_rsa

Il y a deux commande pour vérifier tout cela sous linux, la liste des certificats en cours

ssh-add -l

Et pour vider

ssh-add -D

Forwarding agent

Bon comme il ne suffit pas d'activer le "AllowAgentForwarding yes" pour que cela soit utilisable on va voir les deux méthodes :

Basique -> je lance mes connexion ssh avec

ssh -A root@serveur IP

Class -> je fais mon petit fichier de configuration ~/.ssh/config

Host myhost.com
  ForwardAgent yes
Host Ip de myhost.com
  ForwardAgent yes

Enjoy

Next Post Previous Post