
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 :
- connexion en certificats RSA uniquement.
- port classique ou pas suivant l'exposition du serveur
- en root ( oui je sais c'est pas le mieux )
- rebonds autorisés
- tracer les connexions
- Un belle bannière
Ce que je ne veux pas !
- Le "forwarding" des ports, X11 etc ...
- la possibilité de connexion par mot de passe.
- 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.
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