PUBLIC MARKS from camel with tag ssh

If you have multiple servers with similar or identical configurations (such as nodes in a cluster), it’s often difficult to make sure the contents and configuration of those servers are identical. It’s even more difficult when you need to make configuration modifications from the command line, knowing you’ll have to execute the exact same command on a large number of systems . In this tutorial we will see some tools to execute one command on multiple remote servers using ssh.First you need to make sure you have ssh installed in your machine or you can install using the following command

’Scripts Shell sous Linux’ chez ENI 10 novembre 2008 dans Livres Ce livre sur les scripts shell présente la mise en œuvre de projets dans un environnement industriel. Les 5 projets détaillés couvrent la plupart des besoins en scripts rencontrés en entreprise. Ils ont été conçus et présentés de telle sorte que leur adaptation à des besoins spécifiques sera aisée pour le lecteur. Les thèmes couverts traitent de la gestion des comptes utilisateurs, des sauvegardes de fichiers, des sauvegardes systèmes, de la gestion des disques, des communications entre serveurs, des mécanismes de surveillance et des scripts de démarrage. Ces projets abordent des approches différentes de la programmation en shell, tels que les gros projets qui utilisent plusieurs scripts avec des fichiers de configuration et de journalisation, ou le script unique complet et autonome. Des concepts de base sont détaillés comme les menus interactifs, la crontab, des fichiers systèmes, la sécurité SSH et les clés. Les scripts shell traités dans le livre sont en téléchargement sur cette page. A noter que le livre numérique est offert par l’éditeur pour l’achat du livre imprimé jusqu’au 31 décembre 2008. "Scripts Shell sous Linux : Mise en œuvre de 5 projets", de Théo SCHOMAKER et Jean-Marc BARANGER", ENI Editions. 37 euros. ISBN : 978-2-7460-4617-7

Many people use SSH to log in to remote machines, copy files around, and perform general system administration. If you want to increase your productivity with SSH, you can try a tool that lets you run commands on more than one remote machine at the same time. Parallel ssh, Cluster SSH, and ClusterIt let you specify commands in a single terminal window and send them to a collection of remote machines where they can be executed. Why you would need a utility like this when, using openSSH, you can create a file containing your commands and use a bash for loop to run it on a list of remote hosts, one at a time? One advantage of a parallel SSH utility is that commands can be run on several hosts at the same time. For a short-running task this might not matter much, but if a task needs an hour to complete and you need to run it on 20 hosts, parallel execution beats serial by a mile. Also, if you want to interactively edit the same file on multiple machines, it might be quicker to use a parallel SSH utility and edit the file on all nodes with vi rather than concoct a script to do the same edit. Many of these parallel SSH tools include support for copying to many hosts at once (a parallel version of scp) or using rsync on a collection of hosts at once. Because the parallel SSH implementations know about all the hosts in a group, some of them also offer the ability to execute a command "on one host" and will work out which host to pick using load balancing. Finally, some parallel SSH projects let you use barriers so that you can execute a collection of commands and explicitly have each node in the group wait until all the nodes have completed a stage before moving on to the next stage of processing.

Many times, you want to execute a command not only on one server, but also on several servers. For example, find out * Version of kernel * Version of Apache web server * Update static html or images files on all web servers via rsync * Find out user information, server information, memory usage etc * Security/patch checking tentakel I have already covered how to execute commands on multiple Linux or UNIX servers via shell script. The disadvantage of script is commands do not run in parallel on all servers. However, several tools exist to automate this procedure in parallel. With the help of tool called tentakel, you run distributed command execution. It is a program for executing the same command on many hosts in parallel using ssh (it supports other methods too). Main advantage is you can create several sets of servers according requirements. For example webserver group, mail server group, home servers group etc. The command is executed in parallel on all servers in this group (time saving). By default, every result is printed to stdout (screen). The output format can be defined for each group.

Have you ever wanted to ssh to your Linux box that sits behind NAT? Now you can with reverse SSH tunneling. This document will show you step by step how to set up reverse SSH tunneling. The reverse SSH tunneling should work fine with Unix like systems.

L’idée était de profi ter du dimensionnement de ce petit monstre pour monter une plate-forme architecturée autour de Xen. Vous le savez peut-être, chez GCU, on est très BSD. Nous avions donc à l’esprit de monter l’architecture suivante : * dom0 sous NetBSD ; * domU shells, destiné à accueillir des accès ssh pour les membres du groupe ayant cotisé à la mirobolante dîme annuelle ; * domU services, qui hébergera les services classiques hors HTTP ; * domU gcu où se trouvera le site principal et ses moult plugins ; * domU www, domaine où nous hébergerons les sites tiers. Afin de profi ter au maximum de ce nouveau matériel, nous envisagions également, naïfs que nous sommes, de n’avoir que des systèmes de type amd64. Nous verrons que cet espoir s’est envolé. Il est important de noter que si NetBSD dispose d’une version dotée d’un noyau de type domU, ce n’est pas le cas d’OpenBSD, aussi, c’est uniquement grâce au mode HVM (Hardware Virtual Machine) de Xen que nous serons en mesure de mettre en place des domUs ne bénéficiant pas de noyaux modifiés.

Commençons tout d’abord par expliquer les quelques termes alambiqués du titre de ce billet pour les néophytes : * SFTP signifie « Secure File Transfer Program », c’est un programme permettant de transférer des fichiers en utilisant une liaison chiffrée par SSH (Secure SHell) ; attention à ne pas confondre SFTP avec FTPS qui signifie pour sa part « File Transfer Protocol over SSL » ! * chroot est un programme permettant de changer le répertoire racine d’un processus afin que ce dernier n’ai accès qu’à une partie limitée de l’arborescence. * scponlyc est un shell limité destiné uniquement aux transferts de fichiers dans un chroot. Le but du jeu est donc de permettre à un utilisateur de transférer des fichiers sur un serveur de manière sécurisée sans qu’il n’obtienne pour autant un shell et sans qu’il lui soit permit de voir l’arborescence du serveur.

Host * ServerAliveInterval 60 ServerAliveCountMax 60

voici quelques outils pour travailler efficacement sur un groupe de machines

SSH has numerous uses beyond just logging into a remote system. In particular, SSH allows you to forward ports from one machine to another, tunnelling traffic through the secure SSH connection. This provides a convenient means of accessing a service hosted behind a firewall, or one blocked by an outgoing firewall. However, forwarding an individual port still requires you to change where your program connects, telling it to use a non-standard port on localhost rather than the standard port on the remote machine, and it requires a separate port forward for each machine you want to access. Dynamic port forwarding via SOCKS provides a more convenient alternative. The examples in this article assume that you reside behind a restrictive firewall which does not allow outgoing SMTP connections except to a designated mail server. You want to connect to a different mail server, mail.example.net, on port 25. You have an SSH account on a machine shell.example.org, which does not reside within the restrictive firewall and can thus access port 25 on mail.example.net.

Si vous faites de nombreuses connexions ssh à une machine, soit pour lancer plusieurs shells, soit pour exécuter des séries de commandes, votre client ssh va initialiser une nouvelle connexion à chaque fois. Ceci peut devenir très lourd pour une machine un peu ancienne. En effet, ceci implique le handshake tcp, la négociation du cryptage, l'échange de clés et donc un certain temps de calcul.

rdiff-backup backs up one directory to another, possibly over a network. The target directory ends up a copy of the source directory, but extra reverse diffs are stored in a special subdirectory of that target directory, so you can still recover files lost some time ago. The idea is to combine the best features of a mirror and an incremental backup. rdiff-backup also preserves subdirectories, hard links, dev files, permissions, uid/gid ownership, modification times, extended attributes, acls, and resource forks. Also, rdiff-backup can operate in a bandwidth efficient manner over a pipe, like rsync. Thus you can use rdiff-backup and ssh to securely back a hard drive up to a remote location, and only the differences will be transmitted. Finally, rdiff-backup is easy to use and settings have sensical defaults.

Ever had to make the same change on more than one Linux/unix server? Find it annoyingly painful to keep repeating the exact same commands again and again and again? This tool addresses exactly this problem. You run a utility (cssh) providing a number of server names as parameters, and then xterms opens up to each server with an extra “console” window. Anything typed into the console is replicated into each server window (so, for examples, you can edit the same file on N machines at the same time, or run the same commands with the same parameters across those servers). It is also possible to type into the server windows directly, or temporarily disable replication to one or more of the servers through the “Hosts” menu.

Savez vous qu'en ssh vous pouvez imposer des contraintes à certains utilisateurs seulement.

il existe une directive dans ssh pour protéger le serveur contre les attaques. Il s'agit de MaxStartups qui indique le maximum de connexions non authentifiées autorisées, par défaut il vaut 10. Au delà, il faudra attendre que l'une de ces connexions tcp se termine, ce qui peut prendre beaucoup de temps. Un petit malin peut donc vous bloquer indéfiniment l'accès à votre serveur.

This tutorial describes two ways how to give users chrooted SSH access. With this setup, you can give your users shell access without having to fear that they can see your whole system. Your users will be jailed in a specific directory which they will not be able to break out of. The users will also be able to use SFTP in their chroot jails.

ctail is a tool for operating tail(1) across large clusters of machines, with many log files. It relies upon existing SSH authentication infrastructure, rather than introducing central points of log collection, or other large infrastructure changes, which aren't easily changed in many systems.

Si vous avez plusieurs machines ubuntu sur votre réseau, et que vous devez faire des taches répétitives sur ces machines, dsh va bien vous aider. Dsh (Distributed SHell ou Dancer's SHell) permet de lancer une commande sur une/des machines ou encore mieux des groupes de machines.

GCU-Squad! » DéFONce lui le r2 avec kolofonium !

Howto: secure your sshd using DenyHosts - Ubuntu Forums