Od pewnego czasu mam bardzo dziwne zachowanie SCP: za każdym razem, gdy próbuję skopiować plik, wynik SCP zawiera kilka podkreślników, a plik nie jest kopiowany.
$ scp test.txt 192.168.0.2:~
[email protected]'s password:
________________________________________
Kiedy tworzę połączenie SSH za pomocą Midnight Commander i kopiuję pliki, działa.
Kilka informacji o mojej maszynie:
$ ssh -V
OpenSSH_5.8p1 Debian-1ubuntu3, OpenSSL 0.9.8o 01 Jun 2010
$ uname -a
Linux squatpc 2.6.38-10-generic #46-Ubuntu SMP Tue Jun 28 15:05:41 UTC 2011 i686 i686 i386 GNU/Linux
Używam Kubuntu 11.04.
Edycja: Więcej informacji zgodnie z żądaniem komentarzy:
$ scp -v test.txt 192.168.0.2:~
Executing: program /usr/bin/ssh host 192.168.0.2, user (unspecified), command scp -v -t -- ~
OpenSSH_5.8p1 Debian-1ubuntu3, OpenSSL 0.9.8o 01 Jun 2010
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to 192.168.0.2 [192.168.0.2] port 22.
debug1: Connection established.
debug1: identity file /home/job/.ssh/id_rsa type 1
debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
debug1: identity file /home/job/.ssh/id_rsa-cert type -1
debug1: identity file /home/job/.ssh/id_dsa type -1
debug1: identity file /home/job/.ssh/id_dsa-cert type -1
debug1: identity file /home/job/.ssh/id_ecdsa type -1
debug1: identity file /home/job/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.8p1 Debian-1ubuntu3
debug1: match: OpenSSH_5.8p1 Debian-1ubuntu3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.8p1 Debian-1ubuntu3
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA 28:f3:2b:31:36:43:9b:07:d8:33:ca:43:4f:ca:6c:4c
debug1: Host '192.168.0.2' is known and matches the ECDSA host key.
debug1: Found key in /home/job/.ssh/known_hosts:20
debug1: ssh_ecdsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/job/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /home/job/.ssh/id_dsa
debug1: Trying private key: /home/job/.ssh/id_ecdsa
debug1: Next authentication method: password
[email protected]'s password:
debug1: Authentication succeeded (password).
Authenticated to 192.168.0.2 ([192.168.0.2]:22).
debug1: channel 0: new [client-session]
debug1: Requesting [email protected]
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending env LANG = en_US.UTF-8
debug1: Sending command: scp -v -t -- ~
________________________________________
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: channel 0: free: client-session, nchannels 1
debug1: fd 0 clearing O_NONBLOCK
debug1: fd 1 clearing O_NONBLOCK
Transferred: sent 2120, received 1872 bytes, in 0.3 seconds
Bytes per second: sent 7783.1, received 6872.6
debug1: Exit status 0
i
$ type scp
scp is hashed (/usr/bin/scp)
type scp?ssh 192.168.0.2 echo hello, czy otrzymujesz jakieś wyniki inne niżhello?Odpowiedzi:
Ok LOL, właśnie zorientowałem się, na czym polega problem.
Ponieważ bardzo lubię krowy, umieściłem
fortune | cowsayu góry mojego.bashrcpliku, który generuje dane wyjściowe w następujący sposóbbash:To wszystko jest w porządku (a czasem śmieszne), gdy działa się
bashinteraktywnie. Jednak bash czyta,~/.bashrcgdy jest interaktywna, a nie powłoka logowania, lub gdy jest powłoką logowania, a jej proces nadrzędny torshdlubsshd. Po uruchomieniuscpserwer uruchamia powłokę, która uruchamia zdalnąscpinstancję. Dane wyjściowe są.bashrcmylone,scpponieważ są wysyłane w taki sam sposób, jakscpdane protokołu. Najwyraźniej jest to znany błąd, więcej informacji znajdziesz tutaj .Zauważ również, że podkreślenia, o których wspomniałem w pytaniu, są podkreślone w górnej linii balonu tekstowego.
Więc rozwiązanie było proste: umieściłem następujące na górze
.bashrcna zdalnej (docelowej) maszynie:Ta linia jest domyślnie obecna,
.bashrcale została odłożona z powodu moich wielu (najwyraźniej nieostrożnych) edycji.źródło
echo "don't have a cow" | cowsaymv ~/.bashrc ~/.bashrc.baktest i upewniłem się, że to jest problem, i zadziałało po tym..bashrc. Lokalny nie ma znaczenia. Zauważ, że nie była to literówka w moim komentarzu (odpowiedź jest prawidłowa): to*i*nie*-*.AFAIK, właściwym sposobem na włączenie nieskrępowanego
scpjest mniej o tym, które warunkowe wyjście standardowe w~/.bashrcskrypcie, a więcej o po prostu ograniczeniu wyświetlania ekranu do~/.bash_profileskryptu. Przynajmniej tak to działa dla mojej dystrybucji (CentOS.)Edytuj dla jasności:
źródło
screendane wyjściowe rozumiemecho "Greetings, Master"lub cokolwiek innego, co wyświetla dane wyjściowe w oknie terminala. Nie umieszczaj tego w swoim ~ / .bashrc - utrzymuj to w swoim skrypcie ~ / .bash_profile.