accès ssh impossible sur mon serveur Debian Lenny

Support Debian
#1

Je coince …

j’ai un serveur LAMP sous Lenny pour faire mumuse et apprendre des bases d’administration en tant que noob caractérisé.

ssh installé et fonctionnel sur mon réseau local via nautilus ou terminal et via putty sur un XP virtualisé dans mon Ubuntu du portable…
iptables full Open ( oui je sais , pas bien mais je ne connais pas et j’ai pas encore pris le temps de creuser )

j’essaye de me connecter du boulot via putty sur le xp et via le proxy pour faire mes devoirs en journée sans trop grèver mes soirées en amoureux avec madame.

j’ai installé firefox et je le connecte à Internet sans souci via le proxy donc mon proxy.montaf.fr port 8080 sont A priori OK

je configure putty sur la base du tuto suivant : michauko.org/blog/2009/02/23/tun … putty-etc/ … j’avais trouvé ailleurs mais ce tuto là est le plus clair pour vous expliquer ce que je fais.

Et ça ne fonctionne pas :12

je tente l’ouverture de session ssh via webmin ( oui je sais pas bien mais je ne m’en sers qu’au taf et le jour où j’ai mon accès SSH , webmin ne va plus me servir à grand chose :006 ) et j’attends encore l’ouverture d’une session.

Est ce quelqu’un aurait une idée pour m’aider à trouver où est le souci ?

Mon fichier /etc/ssh/sshd_config

[code]# Package generated configuration file

See the sshd(8) manpage for details

What ports, IPs and protocols we listen for

Port 22
Port 443

Use these options to restrict which interfaces/protocols sshd will bind to

#ListenAddress ::
#ListenAddress 0.0.0.0
Protocol 2

HostKeys for protocol version 2

HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
#Privilege Separation is turned on for security
UsePrivilegeSeparation yes

Lifetime and size of ephemeral version 1 server key

KeyRegenerationInterval 3600
ServerKeyBits 768

Logging

SyslogFacility AUTH
LogLevel INFO

Authentication:

LoginGraceTime 120
PermitRootLogin yes
StrictModes yes

RSAAuthentication yes
PubkeyAuthentication yes
#AuthorizedKeysFile %h/.ssh/authorized_keys

Don’t read the user’s ~/.rhosts and ~/.shosts files

IgnoreRhosts yes

For this to work you will also need host keys in /etc/ssh_known_hosts

RhostsRSAAuthentication no

similar for protocol version 2

HostbasedAuthentication no

Uncomment if you don’t trust ~/.ssh/known_hosts for RhostsRSAAuthentication

#IgnoreUserKnownHosts yes

To enable empty passwords, change to yes (NOT RECOMMENDED)

PermitEmptyPasswords no

Change to yes to enable challenge-response passwords (beware issues with

some PAM modules and threads)

ChallengeResponseAuthentication no

Change to no to disable tunnelled clear text passwords

#PasswordAuthentication yes

Kerberos options

#KerberosAuthentication no
#KerberosGetAFSToken no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes

GSSAPI options

#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes

X11Forwarding yes
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
#UseLogin no

#MaxStartups 10:30:60
#Banner /etc/issue.net

Allow client to pass locale environment variables

AcceptEnv LANG LC_*

Subsystem sftp /usr/lib/openssh/sftp-server

UsePAM yes
DenyGroups deniedssh[/code]

#2

Salut,

Si ton entreprise possède un service sécurité digne de ce nom, alors un tunnel ssh via les ports 443 ou 80 sera facilement détecté et des hommes en noir vont débarqués dans ton bureau… Après c’est sur que pas mal de boites se contentent juste d’interdire une panoplie de ports sans vraiment sniffer ce qui circule sur le 443 :unamused:
Si tu as bien scrupuleusement suivi ce tuto, alors as tu bien redirigé le port 443 de ta [freebox|livebox|bbox|neufbox] vers ta machine personnelle ?

Mais perso cette technique je ne peux l’utiliser car la sécu rigole pas dans ma boite… Donc je te propose une autre solution :

  • Monter un serveur https sous apache ou lighttpd ou lamp
  • Héberger l’application ajaxterm en utilisant le mod reverse proxy (cette application te donne un shell de ton serveur dans un navigateur web) Tu rajoutes screen qui permet de lancer plusieurs terminaux dans un même shell, tu peux voir aussi du coté de centerim pour avoir msn/icq/…, irssi pour irc, mutt pour les mails, et toutes la panoplies des applis en console…)
  • Activer aussi la connexion https de webmin en reverse proxy
  • Utiliser éventuellement un webproxy en php comme glype ou phproxy pour naviguer tranquille sur les sites interdits (attention, pas de support de flash par défaut a moins d’utiliser des plugins pour certains sites comme youtube, dalymotion, myspace, etc…) et grace à ce webproxy tu peux même accéder à des webmail comme free, gandi, et d’autre (mais pas tous c’est sur)

Voilà avec tout ça tu peux faire déjà pas mal de chose, et ceci à l’avantage d’utiliser une connexion https tout à fait conventionnelle et qui sera accepté par le proxy de ton boulot. Alors que les tunnels un jour ou l’autre tu en paies les frais.

Et je trouve en plus que cette soluce fait apprendre beaucoup plus de chose intéressante :wink:

Ca fais bientôt 2 ans que je me démerde comme ça et j’ai jamais eu un problème

(mais si je continue à trop parler je vais en avoir… :108)

#3

Port 22 et 443 ouverts et redirigés vers mon serveur sur ma box en effet :023

Pas de surf particulier dans mes objectifs , tout est déjà tout à fait open hors porno , téléchargement , etc …

je veux pouvoir bosser sur mon serveur en ssh via la console , c’est tout :slight_smile:

Je vais tout de même scruter ce que tu proposes! si ça me permet d’avoir un shell et de bosser tranquillement ma ligne de commande , ça me va !

#4

Tu ne sembles pas avoir une politique de sécurité trop restrictive dans ta boite s’il ne s’agit que du porn et du p2p…
Dans ce cas tu peux te connecter directement en ssh avec putty sur le port 443, mais je te conseille de fermer le port 22 de ta box car tu vas subir un paquet de tentative de piratage…

Si tu dis à ton serveur ssh d’écouter sur le port 443 alors enlève le port 22 et surtout ferme le dans ta box.
L’inconvénient par contre c’est que si un jour tu veux t’amuser avec ton serveur apache et monter des sites https et bien tu pourra pas car le 443 sera utilisé pour ssh… D’où l’utilité de ajaxterm…
Le principe étant beaucoup plus évolutif, à savoir, monter un vrai serveur https dans lequel tu mets en place des services multiples et ce grace au module reverse proxy et les virtualhosts.
Le présent et l’avenir sont dans les interfaces web et pas dans un shell, alors autant s’y mettre le plus tôt possible :wink:
(aujourd’hui on peut même faire du quake 3 dans son navigateur ! ça roxe grave :005)

#5

je vais regarder dès que j’ai deux minutes :wink:… oui la politique internet de ma boite est très open :wink:

Ok, je viens de tester depuis un poste windows via internet / putty et port 22 et mon ssh fonctionne … Par contre , ça ne fonctionne pas via le 443 :12

je n’ai pas redirigé le 443 sur le 22 par la box , j’ai juste fait en sorte que le serveur SSH écoute le port 443 … je pense donc qu’ Apache écoutant aussi le 443 , une adresse blablabla …avec un virtualhost sous Apache ne devrait pas m’amener vers le ssh non ?

POurquoi la connexion ssh ne fonctionne pas avec le port 443 comme dans le tuto ?

#6

Par défaut apache n’active pas le https tu peux le vérifier en listant les virtualhosts activés :

Si dedans tu as juste un fichier nommé 000-default c’est que tu n’as pas du toucher grand chose et donc que le port 443 doit être free.

Vérifies ça :

  • il faut que ta box rédirige le traffic entrant par le port 443 vers l’ip de ton serveur sur le port 443

  • il faut que ton /etc/ssh/sshd_config soit congiguré avec Port 443 est surtout que tu ais redémarré ssh ou le serveur !

#7

tout cela est OK port 443 et fichier de conf ssh ( voir au dessus )

#8

Je sais pas si ça peut aider mais tu peux tenter un nmap -A sur ta box, depuis ailleurs (le mieux étant de demander à un ami/de la famille histoire de pas être bloqué par le parefeu de la boite). Ça te permettra de voir quels ports sont ouverts et quels services y sont associés.
Tu verrais tout de suite si ton ssh écoute et si oui sur quel port.

PS : pour ce qui est d’iptables, en fait ça fait peur de loin, mais c’est ultra simple une fois que tu a compris le principe des tables et des chaines (en gros le chemin que suit un paquet), ensuite le plus chiant est de comprendre la syntaxe de certaines commandes, mais y a rien de difficile, en deux heures tu devrais pouvoir te faire un parefeu correct.

#9

Salut et Merci !

Ok pour iptables , j’avais prévu de creuser mais je n’ai pas pris le temps :wink:

comment utilises tu nmap-a sur la box ?

en console ?

#10

Oui en console, mais en fait c’est plus nmap -A ip_externe_de_ta_box
Le faire depuis l’intérieur de ton réseau va scanner la mauvaise interface.