"scp - FATAL: Executing ssh1 in compatibility mode failed (check that scp1 is in your PATH)."
Quote 1:
This problem is often quite perplexing, since a ssh -V trace may show that you're using SSH-2 - so what
is a message about "ssh1 compatibility mode " doing in there?
What's happening is this:
1. On the OpenSSH client, you run say, scp foo
server:bar
2. scp runs ssh in a subprocess to connnect to the server, and run the remote command scp -t bar. This
is intend to start an instance of the scp program on the server, and the two scp's will cooperate by
speaking over the SSH connection, to retrieve the file.
3. ssh connects to the server (using either protocol 1 or 2, it doesn't matter), and runs the remote scp
command. However, the "scp" that gets run on the server is the SSH2 scp program (scp2), not the
OpenSSH one. The crux of the problem is: besides the name, these two scp's have exactly nothing in
common. scp2 cannot speak the file-transfer protocol that OpenSSH scp does. However, scp2 recognizes
from the "-t" flag what's expected, and tries exec scp1 to service the connection (this is the extent
of SSH2's SSH-1 compatibility; where OpenSSH has code for both protocols in a single set of programs,
SSH2 expects to execute programs from a parallel SSH1 installation). It fails (presumably because
you don't have SSH1 installed), and reports the problem.
The solution is to install either the OpenSSH or SSH1 version of scp on the server under the name "scp1",
somewhere in the sshd2's PATH.
Quote 2:
OpenSSH implements "scp" via RCP over an SSH channel.
ssh.com implement "scp" via FTP over an SSH channel.
OpenSSH's server has both implementations, but it's client only uses
the RCP version.
So if the client is OpenSSH, use "s
上述情況發生的場景一般是openssh作為client，要連接一個ssh2都server，
如果上述兩種解決方案都覺得麻煩的話，可以通過tar來繞過這個問題：
scp2() {
tar cf - -C $(dirname $1) $(basename $1) | ssh user_name@server_ip -- "tar xmf - -C $2"
}
scp2r () {
ssh user_name@server_ip -- "tar cf - -C $(dirname $1) $(basename $1)" | tar xmf - -C ${2:-.};
}