scp "perte de connexion" mais ssh fonctionne bien

10

Un serveur que je peux ssh très bien a commencé à refuser de scp.

$ scp ~/tmp/foo user@some.example.com:~/tmp/
lost connection

Avec scp -v -vje peux voir que la connexion réussit et que le transfert semble réussir, mais aucun fichier n'apparaît de l'autre côté.

OpenSSH_5.9p1, OpenSSL 0.9.8r 8 Feb 2011
debug1: Reading configuration data /Users/schwern/.ssh/config
debug1: /Users/schwern/.ssh/config line 1: Applying options for *
debug1: Reading configuration data /etc/ssh_config
debug1: /etc/ssh_config line 20: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to testcurrent01.dev.liquidweb.com [10.30.152.254] port 22.
debug1: Connection established.
debug1: identity file /Users/schwern/.ssh/id_rsa type -1
debug1: identity file /Users/schwern/.ssh/id_rsa-cert type -1
debug1: identity file /Users/schwern/.ssh/id_dsa type -1
debug1: identity file /Users/schwern/.ssh/id_dsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_4.3
debug1: match: OpenSSH_4.3 pat OpenSSH_4*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.9
debug2: fd 3 setting O_NONBLOCK
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
...lots of authentication details...
debug1: Enabling compression at level 6.
debug1: Authentication succeeded (publickey).
Authenticated to user@some.example.com ([1.2.3.4]:22).
debug2: fd 5 setting O_NONBLOCK
debug2: fd 6 setting O_NONBLOCK
debug1: channel 0: new [client-session]
debug2: channel 0: send open
debug1: Entering interactive session.
debug2: callback start
debug2: client_session2_setup: id 0
debug2: fd 3 setting TCP_NODELAY
debug1: Sending environment.
debug1: Sending env LANG = en_US.UTF-8
debug2: channel 0: request env confirm 0
debug1: Sending command: scp -v -t -- ~/tmp/
debug2: channel 0: request exec confirm 1
debug2: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug2: channel 0: rcvd adjust 2097152
debug2: channel_input_status_confirm: type 99 id 0
debug2: exec request accepted on channel 0
debug2: channel 0: rcvd eof
debug2: channel 0: output open -> drain
debug2: channel 0: obuf empty
debug2: channel 0: close_write
debug2: channel 0: output drain -> closed
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug2: channel 0: rcvd close
debug2: channel 0: close_read
debug2: channel 0: input open -> closed
debug2: channel 0: almost dead
debug2: channel 0: gc: notify user
debug2: channel 0: gc: user detached
debug2: channel 0: send close
debug2: channel 0: is dead
debug2: channel 0: garbage collecting
debug1: channel 0: free: client-session, nchannels 1
debug1: fd 0 clearing O_NONBLOCK
debug1: fd 1 clearing O_NONBLOCK
Transferred: sent 4576, received 2520 bytes, in 0.0 seconds
Bytes per second: sent 167737.0, received 92372.6
debug1: Exit status 0
debug1: compress outgoing: raw data 135, compressed 121, factor 0.90
debug1: compress incoming: raw data 66, compressed 52, factor 0.79
lost connection

Il s'agit d'une machine CentOS 5.9.

Ce que j'ai vérifié ...

J'ai la permission d'écrire dans ce répertoire.
L'utilisateur a un shell sensible (/ bin / bash).
J'ai essayé de déplacer mon ~/.ssh/configchemin.
scp'ing à cette machine à partir d'autres avec des systèmes d'exploitation entièrement différents échouent également.
Le disque n'est pas plein.
Redémarrage de sshd.

/ var / log / secure contient ...

Apr  4 14:23:22 some sshd[12576]: Postponed publickey for user from 1.2.3.4 port 33581 ssh2
Apr  4 14:23:22 some sshd[12575]: Accepted publickey for user from 1.2.3.4 port 33581 ssh2
Apr  4 14:23:22 some sshd[12575]: pam_unix(sshd:session): session opened for user user by (uid=0)
Apr  4 14:23:22 some sshd[12575]: pam_unix(sshd:session): session closed for user user

Que puis-je vérifier ensuite?

ssh scp

— Schwern
source

2

Pas l'erreur à laquelle je m'attendais, mais juste au cas où, faites votre ~/.bashrcou ~/.profileou /etc/bash.bashrcou /etc/profileimprimez quelque chose sur STDOUT? bugzilla.redhat.com/show_bug.cgi?id=20527 . Et je suppose que vous utilisez Linux?

— terdon

Nan. Je reçois juste l'habituel Last login: Thu Apr 4 10:15:28 2013 from 1.2.3.4.

— Schwern

Quelque chose dans l'un des journaux du système sur l'hôte cible?

— Flup

@Flup semble normal. J'ai publié ce qui apparaît dans les journaux lorsque je me connecte.

— Schwern

Pourriez-vous démarrer strace -f -o /tmp/sshd.strace -p [pid of sshd]sur le serveur, réessayer, puis publier quoi que ce soit de ce fichier qui semble pertinent?

— Flup

1

Eu le même problème.

Si vous avez effectué une installation minimale de Centos, il installe uniquement les packages opensshet openssh-servermais pas le openssh-clients. sudo yum install openssh-clientsva résoudre votre problème.

— qux
source

Je n'ai plus accès à cette machine, mais cela semble une réponse probable.

— Schwern

4

scpfonctionne en établissant une sshconnexion à l'hôte distant, puis en lançant une autre copie du scpprogramme sur cet hôte. Les deux instances scp communiquent via la connexion ssh pour effectuer le transfert de fichiers.

"perte de connexion" est imprimée par le scpprogramme local lorsque la connexion ssh tombe prématurément. La raison habituelle en est que le scpprogramme sur l'hôte distant n'a pas pu démarrer ou qu'il s'est arrêté prématurément. Cela a pu se produire parce que le programme scp n'existe pas sur l'hôte distant, ou il n'est pas dans votre commande PATH, ou il n'est pas marqué comme exécutable, ou il s'est écrasé après le démarrage, ou quelque chose du genre.

— Kenster
source

0

Nous avons récemment rencontré ce problème sur l'un de nos systèmes.

Nous avons pu ssh de manière appropriée sur le serveur hôte, mais nous avons découvert que nous ne pouvions pas rentrer ssh du serveur sur la machine. C'est un bon endroit pour enquêter, si vous ne pouvez pas le faire, vous ne pourrez pas utiliser SCP.

Dans notre cas, en quelque sorte (peut-être une installation bâclée) avait remplacé nos fichiers binaires ssh par des fichiers vides de 0 octet. Chaque fois que "ssh" était exécuté, rien ne se passait.

En réinstallant openssh-clients, nous avons rectifié les binaires et scp a commencé à fonctionner.

yum reinstall openssh-clients

— Ultimation
source