O ssh interativo funciona, mas não o rsync ou o scp, no OSX

2

A motivação é que há um servidor no qual eu posso ssh (com ou sem pares de chaves configurados ... ou seja, sem ou com uma senha), mas não consigo enviar arquivos para rsync , scp ou sftp . Alguém mencionou que eu deveria verificar se estou usando a mesma porta para o ssh e para os protocolos de transferência de arquivos, mas não sei como verificar isso.

Se você tiver alguma outra opinião sobre como eu poderia ter o rsync para trabalhar, eu também gostaria disso.

Quando eu corro rsync -avvvvvPt ./ [USER]@[REMOTE]:. Eu recebo:

FILE_STRUCT_LEN=24, EXTRA_LEN=4
cmd=<NULL> machine=[REMOTE] user=[USER] path=.
cmd[0]=ssh cmd[1]=-l cmd[2]=[USER] cmd[3]=[REMOTE] cmd[4]=rsync cmd[5]=--server cmd[6]=-vvvvvlogDtpre.iLsfx cmd[7]=--partial cmd[8]=. cmd[9]=. 
opening connection using: ssh -l [USER] [REMOTE] rsync --server -vvvvvlogDtpre.iLsfx --partial . .  (10 args)
msg checking charset: UTF-8

e depois trava até ctrl-c .

    
por dslack 09.11.2014 / 16:58

5 respostas

1

Ambos os servidores precisam ter a mesma porta ssh.

Se sua porta em um servidor for 22 e outra for 44, o scp não funcionará.

    
por 01.12.2014 / 19:05
1

No meu caso, era uma diretiva ForceCommand definida no arquivo de configuração sshd do servidor remoto /etc/ssh/sshd_config . Depois de comentar o & recarregando o servidor, ele começou a funcionar bem.

    
por 01.02.2018 / 15:22
0

Se todos eles estiverem disponíveis, conforme acordado, você poderá verificar os arquivos .plist das portas:

Abra um prompt de terminal e execute cat /System/Library/LaunchDaemons/ssh.plist .

Desça um pouco e você verá:

           <key>Listeners</key>
           <dict>
                  <key>SockServiceName</key>
                   <string>ssh</string>
                  <key>Bonjour</key>
                  <array>
                          <string>ssh</string>
                          <string>sftp-ssh</string>
                 </array>
          </dict>

O <string>...<string> abaixo de <Key> SockServiceName </key> é o que você procura. Se o texto é ssh como acima, então é usando a porta padrão que é a porta 22. Se for um número, esse número é a porta.

O Rsync sobre o ssh usa a mesma porta que envia os dados através do ssh tunnel e o iirc sftp e o scp usam o ssh tunnel para que suas portas sejam as mesmas que o ssh.

Fontes: link

    
por 09.11.2014 / 17:59
0

Experimente e use o rsync com ssh.

rsync -avvvvvPt --rsh=ssh ./ [USER]@[REMOTE]:.
    
por 10.11.2014 / 11:10
0

Nova resposta depois de ler mais sobre o sinalizador iconv e as informações adicionadas à pergunta.

De acordo com as perguntas frequentes: link

You can avoid a charset problem by passing an appropriate --iconv option to rsync that tells it what character-set the source files are, and what character-set the destination files get stored in. For instance, the above Mac OS X problem would be dealt with by using --iconv=UTF-8,UTF8-MAC (UTF8-MAC is a pseudo-charset recognized by Mac OS X iconv in which all characters are decomposed).

Portanto, você precisa descobrir qual é o charset da fonte e o charset usado pelo sistema operacional no computador de destino.

Nota: Também é possível que @stefan esteja certo sobre os arquivos serem grandes e está demorando para calcular, mas isso está relacionado à geração de hash não com charset e não deveria importar com isso.

    
por 10.11.2014 / 16:33

Tags