Recientemente actualicé un servidor (que ejecuta RHEL AS 5) del servidor OpenSSH 4 al servidor OpenSSH 5.2.
Desde la actualización, un cliente ya no puede escanear archivos de la máquina. Usan un cliente ssh dehttp://ssh.com/. Puedo escanear archivos desde y hacia la máquina usando openssh sin problemas.
Usamos "Autenticación de clave pública" y aún pueden enviar ssh a la máquina, pero no archivos scp.
¿Existe alguna causa conocida (obvia) para tales incompatibilidades? Si no, ¿cómo puedo profundizar en este problema?
Aquí hay un registro del lado del cliente:
user@srv/home/user> /usr/local/bin/scp -v [email protected]:/home/cdr/test .
scp:SshAppCommon/sshappcommon.c:133: Allocating global SshRegex context.
scp:Scp2/scp2.c:499: Received error "SSH_FC_OK"., msg: Globbing successful.
scp:Scp2/scp2.c:564: Starting transfer...
scp:/home/cdr/test
scp:SshFCTransfer/sshfc_transfer.c:3018: File list has 2 files.
scp:SshFCTransfer/sshfc_transfer.c:2567: Not yet connected, or connection down, waiting...
scp:SshFileCopy/sshfilecopy.c:940: Connecting to remote host. (host = xxx.xxx.xxx.51, user = cdr, port = NULL)
scp:Scp2/scp2.c:1679: argv[0] = /usr/local/bin/ssh2
scp:Scp2/scp2.c:1679: argv[1] = -l
scp:Scp2/scp2.c:1679: argv[2] = cdr
scp:Scp2/scp2.c:1679: argv[3] = -v
scp:Scp2/scp2.c:1679: argv[4] = -x
scp:Scp2/scp2.c:1679: argv[5] = -a
scp:Scp2/scp2.c:1679: argv[6] = -o
scp:Scp2/scp2.c:1679: argv[7] = clearallforwardings yes
scp:Scp2/scp2.c:1679: argv[8] = -o
scp:Scp2/scp2.c:1679: argv[9] = passwordprompt %U@%H's password:
scp:Scp2/scp2.c:1679: argv[10] = -o
scp:Scp2/scp2.c:1679: argv[11] = nodelay yes
scp:Scp2/scp2.c:1679: argv[12] = -o
scp:Scp2/scp2.c:1679: argv[13] = authenticationnotify yes
scp:Scp2/scp2.c:1679: argv[14] = xxx.xxx.xxx.51
scp:Scp2/scp2.c:1679: argv[15] = -s
scp:Scp2/scp2.c:1679: argv[16] = sftp
debug: Connecting to xxx.xxx.xxx.51, port 22... (SOCKS not used)
debug: Ssh2/ssh2.c:2121: Entering event loop.
debug: Ssh2Client/sshclient.c:1403: Creating transport protocol.
debug: SshAuthMethodClient/sshauthmethodc.c:83: Added "publickey" to usable methods.
debug: SshAuthMethodClient/sshauthmethodc.c:83: Added "password" to usable methods.
debug: Ssh2Client/sshclient.c:1444: Creating userauth protocol.
debug: client supports 2 auth methods: 'publickey,password'
debug: Ssh2Common/sshcommon.c:559: local ip = xxx.xxx.xxx.35, local port = 56985
debug: Ssh2Common/sshcommon.c:561: remote ip = xxx.xxx.xxx.51, remote port = 22
debug: SshConnection/sshconn.c:1930: Wrapping...
debug: Ssh2/ssh2.c:899: Opening /dev/tty for queries.
debug: Remote version: SSH-2.0-OpenSSH_5.2
debug: Ssh2Transport/trcommon.c:1306: Remote version has rekey incompatibility bug.
debug: Ssh2Transport/trcommon.c:1308: Remote version is OpenSSH, KEX guesses disabled.
debug: Ssh2Transport/trcommon.c:1647: lang s to c: `', lang c to s: `'
debug: Ssh2Transport/trcommon.c:1712: c_to_s: cipher aes128-cbc, mac hmac-sha1, compression none
debug: Ssh2Transport/trcommon.c:1715: s_to_c: cipher aes128-cbc, mac hmac-sha1, compression none
debug: Remote host key found from database.
debug: Ssh2Common/sshcommon.c:317: Received SSH_CROSS_STARTUP packet from connection protocol.
debug: Ssh2Common/sshcommon.c:367: Received SSH_CROSS_ALGORITHMS packet from connection protocol.
debug: server offers auth methods 'publickey,password,keyboard-interactive'.
debug: Ssh2AuthPubKeyClient/authc-pubkey.c:1535: adding keyfile "/devapp_users/nsdtest/.ssh2/nsdau187" to candidates
debug: Ssh2AuthPubKeyClient/authc-pubkey.c:1535: adding keyfile "/devapp_users/nsdtest/.ssh2/id_dsa_1024_a" to candidates
debug: Ssh2AuthPubKeyClient/authc-pubkey.c:1535: adding keyfile "/devapp_users/nsdtest/.ssh2/id_dsa_1024_b" to candidates
debug: Constructing and sending signature in publickey authentication.
debug: Ssh2AuthPubKeyClient/authc-pubkey.c:772: ssh_client_auth_pubkey_send_signature: reading /devapp_users/nsdtest/.ssh2/nsdau187
debug: Ssh2AuthPubKeyClient/authc-pubkey.c:1751: Public key authentication was successful.
debug: Ssh2Common/sshcommon.c:285: Received SSH_CROSS_AUTHENTICATED packet from connection protocol.
debug: Ssh2/ssh2.c:650: Returning user input stream to original values.
debug: Ssh2Common/sshcommon.c:829: num_channels now 1
scp:SshFCTransfer/sshfc_transfer.c:130: Source file is "raw", and it needs to be parsed.
debug: SshTtyFlags/sshttyflags.c:354: Not a tty. (fd = 0)
scp:SshFCTransfer/sshfc_transfer.c:1319: No connection yet. Waiting...
scp:SshFileXferClient/sshfilexferc.c:981: ssh_file_client_receive_proc: bad VERSION
scp:SshFCTransfer/sshfc_transfer.c:1319: No connection yet. Waiting...
scp:SshFCTransfer/sshfc_transfer.c:1319: No connection yet. Waiting...
scp:SshFCTransfer/sshfc_transfer.c:1319: No connection yet. Waiting...
scp:SshFCTransfer/sshfc_transfer.c:1319: No connection yet. Waiting...
scp:SshFCTransfer/sshfc_transfer.c:1319: No connection yet. Waiting...
[...] same until the user presses Ctrl+C
user@srv/home/user> debug: SshConnection/sshconn.c:405: EOF from channel stream
debug: Ssh2ChannelSession/sshchsession.c:1721: received exit status : 0
debug: Ssh2Common/sshcommon.c:803: num_channels now 0
debug: Got session close with exit_status=0
debug: destroying client struct...
debug: Ssh2Client/sshclient.c:1478: Destroying client.
debug: SshConfig/sshconfig.c:555: Freeing pki. (host_pki != NULL, user_pki = NULL)
debug: SshConnection/sshconn.c:1982: Destroying SshConn object.
debug: Ssh2Client/sshclient.c:1540: Destroying client completed.
debug: SshAuthMethodClient/sshauthmethodc.c:88: Destroying authentication method array.
debug: SshAppCommon/sshappcommon.c:146: Freeing global SshRegex context.
debug: SshConfig/sshconfig.c:555: Freeing pki. (host_pki = NULL, user_pki = NULL)
Y aquí están las entradas del registro del servidor.
Jun 3 07:22:36 localhost sshd[19898]: Accepted publickey for cdr from xxx.xxx.xx.x port 53119 ssh2
Jun 3 07:22:36 localhost sshd[19900]: subsystem request for sftp
Jun 3 07:22:58 localhost snmpd[8500]: netsnmp_assert index == tmp failed if-mib/data_access/interface.c:467 _access_interface_entry_save_name()
Jun 3 07:23:58 localhost last message repeated 4 times
Editar: "Subsistema sftp internal-sftp" ya está habilitado en el archivo conf, y puedo archivos sftp desde el servidor sin problemas.
Editar: intentar sin las claves especificando un nombre de usuario/contraseña tampoco funciona. Volver a la versión anterior funciona, así que eso es lo que estamos haciendo por ahora.
Por cierto, sospechábamos esta línea.
debug: SshTtyFlags/sshttyflags.c:354: Not a tty. (fd = 0)
podría significar que el shell está enviando algo que se muestra en la consola ssh pero estropea el scp, pero parece que no se envía nada en ssh (y .bashrc parece limpio) y no puedo ver el tráfico scp descifrado para ver si se está enviando algo incorrectamente.
Respuesta1
¿Qué significa "no poder escanear archivos"? ¿Cuál es el mensaje de error que reciben?
Verifique sus registros (/var/log/syslog, /var/log/messages, /var/log/daemon.log) para ver si el servidor SSH arroja algún error. Deberían ser bastante descriptivos. Con los registros y el error del cliente, deberíamos poder delimitar cuál es el problema.
Editar
Los registros que publicó indican el problema más probable:
scp:Scp2/scp2.c:1679: argv[16] = sftp
...
scp:SshFileXferClient/sshfilexferc.c:981: ssh_file_client_receive_proc: VERSIÓN incorrecta
Parece que esto está intentando utilizar el protocolo sftp en lugar de scp directamente. OpenSSH, de forma predeterminada, desactiva el subsistema sftp. No sé cuándo se realizó este cambio, pero parece probable. Agregue esto a su sshd_config y vea si cambia las cosas:
Subsistema sftp interno-sftp
Respuesta2
Hay muchos problemas potenciales. Primero, ¿ha examinado los registros de su servidor para ver si hay alguna pista? ¿Es posible que la actualización haya cambiado una configuración que el cliente no puede usar o no está configurado para usar? Por ejemplo, ¿su servidor ahora requiere SSH2 pero el cliente solo usa SSH1?
Los archivos de registro probablemente proporcionarán el camino hacia la respuesta. Si el cliente SCP puede realizar algún registro, eso también podría ser útil.
Respuesta3
Esto puede tener algo que ver con la vulnerabilidad de la clave openssh que se solucionó. Todas las claves vulnerables fueron incluidas en la lista negra y deben volver a crearse. Simplemente verifique si pueden eliminar las huellas digitales almacenadas en caché de su servidor. Una vez hecho esto, el cliente deberá mostrar la nueva huella digital al usuario y preguntarle si la acepta. La razón por la que SSH puede funcionar es que la aplicación podría haberle preguntado al usuario si acepta la nueva clave o que se realizó el contacto inicial después de la actualización.
Respuesta4
Experimenté el mismo problema al usar el registro de error del cliente SSH que muestra... FileTransferWin/filetransferwin.c:217: Error recibido SSH_FC_OK, mensaje de error No hay archivos para transferir.
Después de horas de largos experimentos, entiendo que a SSH no le gusta transferir archivos desde carpetas con caracteres especiales utilizados en su nombre, es decir, "Archivos a (Transferir)". Después de cambiar el nombre de la carpeta a "Archivos_a_Transferir", funcionó bien.