Bonjour à tous,
J'ai vraiment besoin d'aide pour reprendre la main sur un serveur distant. Suite à une mise à jour ssl (grrr), et je ne sais pas pour quelle autre raison, le serveur ssh s'est coupé.
Du coup, plus de connexion à distance possible !
J'ai la possibilité d'envoyer des fichiers par FTP, et de les mettre dans le répertoire du site web (avec php 4). J'ai donc trouvé et testé un utilitaire de shell par le web : phpshell ( http://phpshell.sourceforge.net )
ca marche bien, mais ce n'est pas un shell. J'ai trouvé une astuce avec nc pour éxécuter bash par un socket réseau, sauf que c'est un pseudo shell, et pas un tty, donc on ne peut pas utiliser de commande en mode connectée (et donc on ne peut pas utiliser su).
Avez-vous déjà eu le problème ?
Qu'avez-vous fait ?
Forum Linux.général comment reprendre la main sur un serveur sans ssh ?
23
mai
2008
# Serveur ?
Posté par mururoa69 . Évalué à 2.
C'est quoi ta machine ?
[^] # Re: Serveur ?
Posté par Erwann Robin (site web personnel) . Évalué à 1.
sans sudo ni autre prise de controle que ssh :'(
[^] # Re: Serveur ?
Posté par mururoa69 . Évalué à 2.
Euh, minute, en 2 minutes chez OVH je vois 2 trucs :
- vKVM
- reboot du serveur à distance
T'es sûr que t'as bien RTFM ?
[^] # Re: Serveur ?
Posté par Erwann Robin (site web personnel) . Évalué à 1.
et le vkvn demande une interruption de service que j'aimerai éviter...
[^] # Re: Serveur ?
Posté par khivapia . Évalué à 3.
(service vKVM à la page http://www.ovh.com/fr/particulier/produits/kimsufi08.xml )
# hi hi hi
Posté par aiRVB . Évalué à 1.
...
Personne ?
...
C'est bien pour ça qu'on l'aime notre Unix, il n'a rien d'une passoire comme l'autre bouse de redmond ;)
# la fonction system de php ?
Posté par Cyril . Évalué à 2.
et su/sudo pour relancer ton serveur ssh ...
http://fr.php.net/manual/en/function.system.php
Mais le plus simple semble d'intervenir sur place ...
[^] # Re: la fonction system de php ?
Posté par Erwann Robin (site web personnel) . Évalué à 2.
# Clé SSH ?
Posté par Dan . Évalué à 1.
Résultat : obligé de changer ses clés.
Mais c'est peut-être autre chose.
[^] # Re: Clé SSH ?
Posté par Erwann Robin (site web personnel) . Évalué à 1.
mais j'ai fait des mises à jour et ca a peut-être effacé les clés...
du coup j'aimerais redémarrer le serveur ssh ou bien un serveur telnetd, pour me reconnecter à distance, mais telnetd demande les droits root pour se lancer et sshd me crache qu'il ne trouve plus les clés ...
[^] # Re: Clé SSH ?
Posté par B16F4RV4RD1N . Évalué à 2.
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: Clé SSH ?
Posté par fcartegnie . Évalué à 2.
C'est juste le coup classique des librairies openssl/cpryto et des dépendances avec sshd.
# Expect
Posté par Émilien Tlapale . Évalué à 2.
Avec le programme expect tu devrais pouvoir utiliser su même sans prompt password tty no ?
# ftp sur /etc/cron.hourly
Posté par malin . Évalué à 2.
/etc/init.d/ssh stop
/etc/init.d/ssh start
... sauf que la deuxième commande n'arrive jamais évidemment, je viens de scier la branche sur laquelle je suis assis.
Chance: il me reste la possibilité de faire du ftp sur la machine. Deuxième chance: le répertoire /etc/cron.hourly est en écriture pour l'utilisateur qui a le droit de faire du ftp. Ne reste plus qu'à écrire un script pour démarrer sshd, le placer dans /etc/cron.hourly en s'assurant qu'il est bien exécutable, et attendre la prochaine heure pleine.
Un conseil: bien tester le script de démarrage de sshd avant de l'envoyer par ftp, on n'a qu'une chance toutes les heures.
[^] # Re: ftp sur /etc/cron.hourly
Posté par Erwann Robin (site web personnel) . Évalué à 1.
[^] # Re: ftp sur /etc/cron.hourly
Posté par fcartegnie . Évalué à 2.
Sinon lance un :
nc -l -p 9000 | /bin/bash > /home/www/sortie.txt
par exemple ! (la sortie sera dans sortie.txt)
La liste des packages a remplacer est dans:
rpm -qa --last | head
et les forcer depuis le repo en écrasement:
urpmi --force --nodeps http://xxxxxxxxxxXX/libopensslxxxx.rpm
urpmi --force --nodeps http://xxxxxxxxxxXX/xxopensslxxxx.rpm
Ah oui, bidouille pas trop, qq chose me dit que si ton serveur http roule en https, il se relancera pas non plus !
[^] # Re: ftp sur /etc/cron.hourly
Posté par Lol Zimmerli (site web personnel, Mastodon) . Évalué à 2.
La gelée de coings est une chose à ne pas avaler de travers.
[^] # Re: ftp sur /etc/cron.hourly
Posté par -=[ silmaril ]=- (site web personnel) . Évalué à 2.
ah ?
tu a vu ça ou ?
je fait ça depuis 3 ans sans soucis (même si je préfère activer un telnet a coté, juste au cas ou, pendant l'opération.
le ssh stop, arrête le démon ssh, mais ne tue pas les connections
actives, donc pas de souscis tant que tu ne te déconnecte pas
[^] # Re: ftp sur /etc/cron.hourly
Posté par wismerhill . Évalué à 3.
Mais pour le problème d'Erwann, c'est peut-être simplement parce que la clé du serveur a été regénérée suite à la mise à jour (j'ai eu le cas sur tous mes serveurs debian) et que ton client ssh (local) a encore l'ancienne clé publique et croit que c'est une tentative de hack (suivant la configuration il peu juste avertir ou complètement refuser la connection).
Regarde dans le fichier ~/.ssh/known_hosts et supprime la ligne correspondant à ton serveur (si tu ne trouve pas tu peux supprimer tout le fichier, mais tu perdra les éventuelles configuration d'autres serveurs), il devrait ensuite te redemander d'accepter la nouvelle clé.
[^] # Re: ftp sur /etc/cron.hourly
Posté par Erwann Robin (site web personnel) . Évalué à 1.
(testé avec nmap et telnet 22)
j'ai téléchargé et décompressé le pacquet openssh-server que j'essaye de lancer avec mon compte www-data, mais il refuse :
socket: Address family not supported by protocol
Cannot bind any address.
[^] # Re: ftp sur /etc/cron.hourly
Posté par wismerhill . Évalué à 2.
[^] # Re: ftp sur /etc/cron.hourly
Posté par Erwann Robin (site web personnel) . Évalué à 1.
par contre, je n'arrive pas à me connecter, il me répond :
No supported key exchange algorithms (coté serveur)
et coté client :
Connection closed by XXX.XXX.XXX.XXXavec telnet, on a un peu plus d'infos ;
Trying XXX.XXX.XXX.XXX...
Connected to monsite.com.
Escape character is '^]'.
SSH-2.0-OpenSSH_4.3p2 Debian-5~bpo.1
Protocol mismatch.
Connection closed by foreign host
est ce que vous savez de quelles "key exchange algorithms " il veut parler ?
pour info, voici la trace complète :
$ /tmp/openssh-sarge/usr/sbin/sshd -f sshd_config_new -h .ssh/ssh_host_rsa_key -p 2550 -d
debug1: sshd version OpenSSH_4.3p2 Debian-5~bpo.1
debug1: read PEM private key done: type RSA
debug1: private host key: #0 type 1 RSA
debug1: setgroups() failed: Operation not permitted
debug1: rexec_argv[0]='/tmp/openssh-sarge/usr/sbin/sshd'
debug1: rexec_argv[1]='-f'
debug1: rexec_argv[2]='sshd_config_new'
debug1: rexec_argv[3]='-h'
debug1: rexec_argv[4]='.ssh/ssh_host_rsa_key'
debug1: rexec_argv[5]='-p'
debug1: rexec_argv[6]='2550'
debug1: rexec_argv[7]='-d'
debug1: Bind to port 2550 on 0.0.0.0.
Server listening on 0.0.0.0 port 2550.
socket: Address family not supported by protocol
debug1: Server will not fork when running in debugging mode.
debug1: rexec start in 4 out 4 newsock 4 pipe -1 sock 7
debug1: inetd sockets after dupping: 3, 3
Connection from [mon ip] port 55782
debug1: Client protocol version 2.0; client software version OpenSSH_4.3p2 Debian-9
debug1: match: OpenSSH_4.3p2 Debian-9 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.3p2 Debian-5~bpo.1
debug1: list_hostkey_types:
No supported key exchange algorithms
debug1: do_cleanup
[^] # Re: ftp sur /etc/cron.hourly
Posté par malin . Évalué à 1.
# shell via le web ?
Posté par moudj . Évalué à 2.
si tu as du python sur la machine :
http://antony.lesuisse.org/qweb/trac/wiki/AjaxTerm
Sinon :
http://anyterm.org/
A+
# Ce n'est pas très grave
Posté par Kerro . Évalué à 4.
... mais ... quelle sauvegarde ? :-)
[^] # Re: Ce n'est pas très grave
Posté par Cyril . Évalué à 1.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.