Ssh - Historique des versions

127.0.0.1 le 21 novembre 2015 à 09:11

2015-11-21T09:11:38Z

← Version précédente		Version du 21 novembre 2015 à 09:11
Ligne 156 :		Ligne 156 :
	On est dans le cas ici, que nos ordinateurs ne peuvent sortir uniquement sur les ports 80 & 443, et doivent obligatoirement passer par le proxy de l'entreprise. La méthode ci-dessous		On est dans le cas ici, que nos ordinateurs ne peuvent sortir uniquement sur les ports 80 & 443, et doivent obligatoirement passer par le proxy de l'entreprise. La méthode ci-dessous
	va nous permettre de faire du ssh sur notre serveur, et aussi de passer par notre proxy pour les navigateurs internet sans que nos requetes soient enregistrées dans le proxy de la		va nous permettre de faire du ssh sur notre serveur, et aussi de passer par notre proxy pour les navigateurs internet sans que nos requetes soient enregistrées dans le proxy de la
	société.		société. On va aussi installer sslh qui permet de faire écouter le port 443 et de rediriger vers ssh ou vers apache suivant si c'est une connexion ssh ou https qui arrive.
	Sur le serveur perso :		Sur le serveur perso :
	- faire écouter ssh sur le port 80 ou 443 (pour faire une connexion ssh et un tunnel)		- faire écouter ssh sur le port 80 ou 443 (pour faire une connexion ssh et un tunnel)& modifier apache en conséquence
	- installer un proxy qui écoute en localhost sur le port 8888 (par exemple)		- installer un proxy qui écoute en localhost sur le port 8888 (par exemple)

5.49.89.223 le 21 novembre 2015 à 08:41

2015-11-21T08:41:47Z

← Version précédente		Version du 21 novembre 2015 à 08:41
Ligne 151 :		Ligne 151 :
	sur 127.0.0.1:5900, il passe par le tunnel et nous connecte.		sur 127.0.0.1:5900, il passe par le tunnel et nous connecte.
	</pre>		</pre>

			== Tunnel ssh avec Putty & contournement de proxy ==
			<pre>
			On est dans le cas ici, que nos ordinateurs ne peuvent sortir uniquement sur les ports 80 & 443, et doivent obligatoirement passer par le proxy de l'entreprise. La méthode ci-dessous
			va nous permettre de faire du ssh sur notre serveur, et aussi de passer par notre proxy pour les navigateurs internet sans que nos requetes soient enregistrées dans le proxy de la
			société.
			Sur le serveur perso :
			- faire écouter ssh sur le port 80 ou 443 (pour faire une connexion ssh et un tunnel)
			- installer un proxy qui écoute en localhost sur le port 8888 (par exemple)

			Dans putty :
			- connexion / proxy : mettre le "proxy type" sur http, et renseignerl ip / port du proxy agarik
			- connexion / ssh / tunnel : source port 8888 / Destination 127.0.0.1:8888

			Puis dans son navigateur lui mettre comme proxy 127.0.0.1:8888
			</pre>

	== Sftp ==		== Sftp ==
Ligne 197 :		Ligne 213 :
	!!! Attention, une fois les clés supprimées, il ne faut pas fermer la session avant de regénerer les nouvelles clés, car on ne peut plus se logguer en ssh !!!		!!! Attention, une fois les clés supprimées, il ne faut pas fermer la session avant de regénerer les nouvelles clés, car on ne peut plus se logguer en ssh !!!
	</pre>		</pre>


	[[Catégorie:Software]]		[[Catégorie:Software]]

217.174.206.178 le 23 décembre 2014 à 14:49

2014-12-23T14:49:36Z

← Version précédente		Version du 23 décembre 2014 à 14:49
Ligne 157 :		Ligne 157 :
	On rajoute alors ce path complet dans /etc/shell, et on donne ce shell au user qui veut faire du scp / sftp		On rajoute alors ce path complet dans /etc/shell, et on donne ce shell au user qui veut faire du scp / sftp
	</pre>		</pre>

			== Forward X11 ==
			On peut avoir besoin d'avoir un export de display (via putty : activer dans "connexion / ssh / x11 / enable x11 forwarding" ; ou via ssh -Y), il faut installer sur le serveur linux les
			packages suivant : libaio-devel.x86_64 libaio.x86_64 sysstat.x86_64 glibc-devel.x86_64 compat-glibc.i386 glibc-devel.i386 compat-libstdc++-33-3.2.3-61 compat-libgcc-296-2.96-138
			compat-libstdc++-296-2.96-138 xorg-x11-xauth.x86_64 libXp.i386 libXt.i386 libXtst.i386

			<pre>
			ssh_config : ForwardX11 yes
			sshd_config : X11Forwarding yes & X11DisplayOffset 10
			</pre>

			Il n'est pas nécessaire de faire des export display, xhost +x

	== Upgrade de version ==		== Upgrade de version ==

217.174.206.178 : /* SSH regénération des clés */

2014-12-10T16:14:51Z

SSH regénération des clés

← Version précédente		Version du 10 décembre 2014 à 16:14
Ligne 181 :		Ligne 181 :
	== SSH regénération des clés ==		== SSH regénération des clés ==
	<pre>		<pre>
	Si l'on veut regénérer les clés suite à un clonage ou une autre version, supprimer tous les ssh_host_* présents dans /etc (ou dans /opt/applis/openssh/etc & /opt/applis/openssh), puis faire un ssh-keygen -A (cela va générer tous les types de clés : rsa, dsa...) et faire un restart de ssh pour finir de générer les clés.		Si l'on veut regénérer les clés suite à un clonage ou une autre version, supprimer tous les ssh_host_* présents dans /etc (ou dans /opt/applis/openssh/etc & /opt/applis/openssh),
			puis faire un ssh-keygen -A (cela va générer tous les types de clés : rsa, dsa...) et faire un restart de ssh pour finir de générer les clés.
	!!! Attention, une fois les clés supprimées, il ne faut pas fermer la session avant de regénerer les nouvelles clés, car on ne peut plus se logguer en ssh !!!		!!! Attention, une fois les clés supprimées, il ne faut pas fermer la session avant de regénerer les nouvelles clés, car on ne peut plus se logguer en ssh !!!
	</pre>		</pre>

	[[Catégorie:Software]]		[[Catégorie:Software]]

217.174.199.129 le 12 juin 2014 à 13:54

2014-06-12T13:54:28Z

← Version précédente		Version du 12 juin 2014 à 13:54
Ligne 61 :		Ligne 61 :
	http://www.debian-administration.org/articles/590		http://www.debian-administration.org/articles/590

	== ~~Ssh~~ sans mot de passe ==		== SSH sans mot de passe ==
	<pre>		<pre>
	Générer sur le serveur local les clés ssh (ssh-keygen -t rsa), copier le contenu de /home/user1/.ssh/id_rsa.pub sur le serveur distant dans /home/user2/.ssh/autorized_keys		Générer sur le serveur local les clés ssh (ssh-keygen -t rsa), copier le contenu de /home/user1/.ssh/id_rsa.pub sur le serveur distant dans /home/user2/.ssh/autorized_keys
Ligne 68 :		Ligne 68 :
	</pre>		</pre>

	== ~~Ssh~~ avec restriction de commande ==		== SSH avec restriction de commande ==
	1er cas		1er cas
	<pre>		<pre>
Ligne 179 :		Ligne 179 :
	</pre>		</pre>

	== ~~SSh~~		== SSH regénération des clés ==
			<pre>
			Si l'on veut regénérer les clés suite à un clonage ou une autre version, supprimer tous les ssh_host_* présents dans /etc (ou dans /opt/applis/openssh/etc & /opt/applis/openssh), puis faire un ssh-keygen -A (cela va générer tous les types de clés : rsa, dsa...) et faire un restart de ssh pour finir de générer les clés.
			!!! Attention, une fois les clés supprimées, il ne faut pas fermer la session avant de regénerer les nouvelles clés, car on ne peut plus se logguer en ssh !!!
			</pre>

	[[Catégorie:Software]]		[[Catégorie:Software]]

217.174.199.129 le 12 juin 2014 à 13:50

2014-06-12T13:50:10Z

← Version précédente		Version du 12 juin 2014 à 13:50
Ligne 1 :		Ligne 1 :
	== ~~Ssh~~ Chroot ==		== SSH Chroot ==

	On peut avoir facilement un user chroot en ssh / sftp. Rajouter dans le fichier /etc/ssh/sshd_config		On peut avoir facilement un user chroot en ssh / sftp. Rajouter dans le fichier /etc/ssh/sshd_config

217.174.199.129 le 12 juin 2014 à 13:50

2014-06-12T13:50:02Z

← Version précédente		Version du 12 juin 2014 à 13:50
Ligne 178 :		Ligne 178 :
	# rm -rf /opt/applis/openssh-oldversion		# rm -rf /opt/applis/openssh-oldversion
	</pre>		</pre>

			== SSh

	[[Catégorie:Software]]		[[Catégorie:Software]]

Admin : /* Rsync over ssh secure */

2014-05-07T15:05:56Z

Rsync over ssh secure

← Version précédente		Version du 7 mai 2014 à 15:05
Ligne 94 :		Ligne 94 :

	== Rsync over ssh secure ==		== Rsync over ssh secure ==
			Permet d executer un rsync dans un script bash lancé sous root, et que le rsync utilise le user vision ainsi que sa clé

	<pre>		<pre>
Ligne 108 :		Ligne 109 :
	dans /home/vision/.ssh/authorized_keys doit se trouver le contenu de /home/vision/.ssh/id_dsa.pub du serveur A		dans /home/vision/.ssh/authorized_keys doit se trouver le contenu de /home/vision/.ssh/id_dsa.pub du serveur A
	</pre>		</pre>


	== Tunnel ssh ==		== Tunnel ssh ==

Admin le 9 octobre 2013 à 11:53

2013-10-09T11:53:44Z

← Version précédente		Version du 9 octobre 2013 à 11:53
Ligne 50 :		Ligne 50 :

	* Le répertoire /opt/data/in a les propriétés suivantes :		* Le répertoire /opt/data/in a les propriétés suivantes :
	drwxr-xr-x 8 root root 4096 Jul 2 14:12 /opt/data/in		drwxr-xr-x 8 root root 4096 Jul 2 14:12 /opt/data/in
			/!\ Se mettre dans /opt/data/in, et faire un ls -la, s'assurer que le répertoire "." soit bien en 755 et pas en 777

	* Le répertoire /opt/data/in/sogec1 a les propriétés suivantes :		* Le répertoire /opt/data/in/sogec1 a les propriétés suivantes :

Admin : /* Ssh Chroot */

2013-10-09T11:50:25Z

Ssh Chroot

← Version précédente		Version du 9 octobre 2013 à 11:50
Ligne 39 :		Ligne 39 :
	vipw : sogec1:x:503:503::/sogec1:/sbin/nologin		vipw : sogec1:x:503:503::/sogec1:/sbin/nologin

	chown -R $login:daemon /opt/data/$login (dans notre exemple chown sogec1:daemon /opt/data/in/sogec1/sogec1)		chown -R $login:daemon /opt/data/in/$login/$login (dans notre exemple chown sogec1:daemon /opt/data/in/sogec1/sogec1)

	chown root:$groupuser /opt/data/in/$login (ici chown root:sogec1 /opt/data/in/sogec1)		chown root:$groupuser /opt/data/in/$login (ici chown root:sogec1 /opt/data/in/sogec1)