Articles taggués ‘ssh’

Administration réseau sous Linux: SSH

24/09/2020 Aucun commentaire

Source: Wikilivres

SSH signifie Secure SHell. C’est un protocole qui permet de faire des connexions sécurisées (i.e. cryptées) entre un serveur et un client SSH.

On peut l’utiliser pour se connecter à une machine distante comme avec telnet, pour transférer des fichiers de manière sécurisée ou pour créer des tunnels. Les tunnels permettent sécuriser des protocoles qui ne le sont pas en faisant passer les données par une connexion SSH.


Le système de clés de SSH

Cryptographie asymétrique

SSH utilise la cryptographie asymétrique RSA ou DSA. En cryptographie asymétrique, chaque personne dispose d’un couple de clé : une clé publique et une clé privée. La clé publique peut être librement publiée tandis que chacun doit garder sa clé privée secrète. La connaissance de la clé publique ne permet pas d’en déduire la clé privée.

Si la personne A veut envoyer un message confidentiel à la personne B, A crypte le message avec la clé publique de B et l’envoie à B sur un canal qui n’est pas forcément sécurisé. Seul B pourra décrypter le message en utilisant sa clé privée.

Cryptographie symétrique

SSH utilise également la cryptographie symétrique. Son principe est simple : si A veut envoyer un message confidentiel à B, A et B doivent d’abord posséder une même clé secrète. A crypte le message avec la clé sécrète et l’envoie à B sur un canal qui n’est pas forcément sécurisé. B décrypte le message grâce à la clé secrète.

Toute autre personne en possession de la clé secrète peut décrypter le message.

La cryptographie symétrique est beaucoup moins gourmande en ressources processeur que la cryptographie asymétrique, mais le gros problème est l’échange de la clé secrète entre A et B. Dans le protocole SSL, qui est utilisé par les navigateurs Web et par SSH, la cryptographique asymétrique est utilisée au début de la communication pour que A et B puissent s’échanger une clé secrète de manière sécurisée, puis la suite la communication est sécurisée grâce à la cryptographie symétrique en utilisant la clé secrète échangée.

Lire la suite…

Categories: Réseau, Système, Tutoriel Tags: ,

How To SSH Run Multiple Command On Remote Machine And Exit Safely

16/09/2020 Aucun commentaire

Source: nixCraft

I have a backup sync program on local server. I have an ssh password less login set up, and I can run commands on an external server in bash script doing:

ssh root@server2 "sync; sync; /sbin/shutdown -h now"

How do I run multiple commands in bash on a remote Unix or Linux server? What is the best Way to SSH in and Run various unix commands in bash?

There are various ways to run multiple commands on a remote Unix server. The syntax is as follows:

Simple bash syntax to run multiple commands on remote machine

Simply run command2 if command1 successful on a remote host called foo
$ ssh bar@foo "command1 && command2"
Run date and hostname commands:
$ ssh user@host "date && hostname"
You can run sudo command as follows on a remote box called
$ ssh -t "sudo /sbin/shutdown -h now"
And, finally:
$ ssh "sync && sync && /sbin/shutdown -h now"

Lire la suite…

Categories: Système Tags: , ,

Linux Security Basics

15/09/2020 Comments off

One of the most daunting prospects of administering your own server on a public network is dealing with your server’s security. While security threats in a networked world are real and it is always important to be mindful of security issues, protecting against possible attacks is often a matter of exercising basic common sense and adhering to some general best practices.

This guide takes a broad overview of common security concerns and provides a number of possible solutions to common security problems. You are encouraged to consider deploying some of these measures to “harden” your server against possible attacks.

It’s important to remember that all of the solutions we present in this document are targeted at specific kinds of attacks, which themselves may be relevant only in specific configurations. Security solutions need to be tailored to the kind of services that you’re providing and the software you’re running, and the decision whether or not to deploy a specific security solution is often a matter of personal discretion and cost-benefit analysis.

Perhaps most importantly, it should be understood that security is a process, not a product (credit to Bruce Schneier.) There is no “magic bullet” set of guidelines that can be followed to ensure the security of any system. Threats are constantly evolving, so vigilance is required on the part of network administrators to prevent unauthorized access to systems.

Keep Systems and Software Up To Date

One of the most significant sources of security vulnerabilities are systems running out of date software with known security holes. Make a point of using your system’s package management tools to keep your software up to date; this will greatly assist in avoiding easily preventable security intrusions.

Running system updates with the package management tool, using apt-get update && apt-get upgrade (for Debian and Ubuntu Systems) or yum update (for CentOS and Fedora systems) is simple and straightforward. This practice ensures that if your distribution maintains active security updates, your system will be guarded against many security holes in commonly used software packages.

System update tools will, however, not keep software up to date that you’ve installed outside of package management. This includes software that you’ve compiled and installed “by hand” (e.g. with ./configure && make && make install) and web-based applications that you’ve installed from a software developer’s site, as is often the case with applications like WordPress and Drupal. Also excluded from protection will be libraries and packages you’ve installed with supplementary package management tools like Ruby’s Gems, Perl’s CPAN tool, Python easy_install, and Haskell Cabal. You will have to manage the process of keeping these files up to date yourself.

The method you use to make sure that your entire system is kept up to date is a matter of personal preference, and depends on the nature of your workflow. We would recommend trying very hard to use the versions of software provided by your operating system or other programming platform-specific package management tools. If you must install from “source,” we would recommend that you save the tarballs and source files for all such software in /src/ or ~/src/ so that you can keep track of what software you’ve installed in this manner. Often, you can remove a manually compiled application by issuing make uninstall in the source repository (directory). Additionally, it may be helpful to maintain a list of manually installed software, with version numbers and download locations. You may also want to investigate packaging your own software so that you can install it with apt, yum or pacman.

Because of the complexity of maintaining software outside of the system’s package management tools we strongly recommend avoiding manually installing software unless absolutely necessary. Your choice in a Linux distribution should be heavily biased by the availability of software in that distro’s repositories for the systems you need to run on your server.

Lire la suite…

Munin: Monitoring the “unreachable” hosts

07/09/2020 Comments off

There are a number of situations where you’d like to run munin-node on hosts not directly available to the Munin server. This article describes a few scenarios and different alternatives to set up monitoring. Monitoring hosts behind a non-routing server.

In this scenario, a *nix server sits between the Munin server and one or more Munin nodes. The server in-between reaches both the Munin server and the Munin node, but the Munin server does not reach the Munin node or vice versa.

To enable for Munin monitoring, there are several approaches, but mainly either using SSH tunneling or “bouncing” via the in-between server.

SSH tunneling

The illustration below shows the principle. By using SSH tunneling only one SSH connection is required, even if you need to reach several hosts on “the other side”. The Munin server listens to different ports on the localhost interface. A configuration example is included. Note that there is also a FAQ entry on using SSH that contains very useful information.



This workaround uses netcat and inetd/xinetd to forward the queries from the Munin server. All incoming connections to defined ports are automatically forwarded to the Munin node using netcat.



Utiliser la commande ssh-copy-id depuis Mac OSX

05/09/2020 Comments off

Comment rendre la commande ssh-copy-id disponible sur Mac OS X

Si vous avez tenté d’utiliser la commande ssh-copy-id sur Mac OS X, vous avez dû vous rendre compte que, même si openssh est installé nativement, cette commande n’est pas disponible.

Heureusement, cette commande est un simple script qu’il suffit de copier au bon endroit, de lui donner les bons droits et SURPRISE la commande est disponible.

Et comme je suis sympa, eh bien je vous donne tout ça. 😉 Pour commencer le script ssh-copy-id

Ensuite, la méthodologie à suivre pour le mettre en place:

  • Télécharger le fichier
  • Déplacer le fichier dans le répertoire /usr/bin
  • Lui donner les droits nécessaires
$ chmod 755 /usr/bin/ssh-copy-id


Si vous utilisez homebrew, il existe un package pour faire la même chose :
brew install ssh-copy-id


Source: Mikael Randy

Categories: Système Tags: , , ,