2015-01-28 5 views
0

Я хотел бы использовать Беспарольную ScpУПП аутентифицируют, но дает только приветственное сообщение

scp -i ~/.ssh/id_rsa -P 2022 ~/report.pdf [email protected]:~/ 

, но я только получить

Добра user1 в p6. Среда, 28 января 2015 г. - 14:46 вечера EST

Я добавил необходимые ключи и подтвердил правильность аутентификации. Когда я делаю это в подробном режиме, я получаю

Executing: program /usr/bin/ssh host myserver.com, user user1, command scp -v -t ~/ 
OpenSSH_6.2p2, OSSLShim 0.9.8r 8 Dec 2011 
debug1: Reading configuration data /etc/ssh_config 
debug1: /etc/ssh_config line 20: Applying options for * 
debug1: /etc/ssh_config line 53: Applying options for * 
debug1: Connecting to myserver.com [X.X.X.X] port 2022. 
debug1: Connection established. 
debug1: identity file /Users/morteza/.ssh/id_rsa type 1 
debug1: identity file /Users/morteza/.ssh/id_rsa-cert type -1 
debug1: Enabling compatibility mode for protocol 2.0 
debug1: Local version string SSH-2.0-OpenSSH_6.2 
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6.1p1 Ubuntu-2ubuntu2 
debug1: match: OpenSSH_6.6.1p1 Ubuntu-2ubuntu2 pat OpenSSH* 
debug1: SSH2_MSG_KEXINIT sent 
debug1: SSH2_MSG_KEXINIT received 
debug1: kex: server->client aes128-ctr [email protected] none 
debug1: kex: client->server aes128-ctr [email protected] none 
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent 
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP 
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent 
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY 
debug1: Server host key: RSA 65:b1:52:b3:b5:1a:ff:f6:c7:3a:e7:82:dd:e2:16:32 
debug1: Host '[myserver.com]:2022' is known and matches the RSA host key. 
debug1: Found key in /Users/morteza/.ssh/known_hosts:15 
debug1: ssh_rsa_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: /Users/morteza/.ssh/id_rsa 
debug1: Server accepts key: pkalg ssh-rsa blen 279 
debug1: read PEM private key done: type RSA 
debug1: Authentication succeeded (publickey). 
Authenticated to myserver.com ([X.X.X.X]:2022). 
debug1: channel 0: new [client-session] 
debug1: Requesting [email protected] 
debug1: Entering interactive session. 
debug1: Sending environment. 
debug1: Sending env LC_MONETARY = en_US.utf-8 
debug1: Sending env LC_NUMERIC = en_US.utf-8 
debug1: Sending env LC_ALL = POSIX 
debug1: Sending env LC_MESSAGES = en_US.utf-8 
debug1: Sending env LC_COLLATE = en_US.utf-8 
debug1: Sending env LC_CTYPE = en_US.utf-8 
debug1: Sending env LC_TIME = en_US.utf-8 
debug1: Sending command: scp -v -t ~/ 
Welcome user1 to p6.    Wed, 28 Jan 2015 - 14:42 PM EST 
debug1: client_input_channel_req: channel 0 rtype exit-signal reply 0 
debug1: channel 0: free: client-session, nchannels 1 
debug1: fd 0 clearing O_NONBLOCK 
debug1: fd 1 clearing O_NONBLOCK 
Transferred: sent 3480, received 3336 bytes, in 0.7 seconds 
Bytes per second: sent 5245.4, received 5028.3 
debug1: Exit status -1 

Любые подсказки, что не так? выглядит независимо от того, какой путь я ему даю в машине назначения, это все равно.

+1

Что такое печать этого приветственного сообщения? Сценарий инициализации оболочки? Если вы отключите это сообщение, это сработает? –

+0

Я не могу отключить его. это не из .bashrc, некоторая библиотека мониторинга linux, установленная на сервере, генерирует приветственное сообщение, когда вы делаете ssh –

+1

Что-то вроде 'ssh -i ~/.ssh/id_rsa -P 2022 [email protected] id' или' .. .. ls' или какая-то другая простая команда работает правильно? Есть ли sftp? Моя теория заключается в том, что сообщение заворачивает 'scp' вверх. Я знаю, что неожиданный вывод будет винить 'sftp' up (вопрос об этом раньше был для подтверждения). –

ответ

0

Основная проблема - статистика и приветственные сообщения, напечатанные в начале сеанса ssh. Единственное решение - избавиться от любого выражения echo в .bashrc или связанных файлах или любых сценариев, которые могут печатать некоторые строки сообщений статистики, такие как сообщения, напечатанные landscape.canonical.com в ubuntu.

Смежные вопросы