ssh logou com sucesso, mas scp password me dá “Permission denied”

4

Estou tentando colocar alguns softwares de blog em um servidor remoto organizacional. Eu tentei configurar uma chave SSH, mas estava tendo problemas e decidi que colocar o blog em funcionamento era mais importante do que lidar com o problema da chave SSH, então eu ssh-keygen -R remoteserver.com .

Agora posso fazer login com sucesso com ssh -v [email protected] e a senha correta. Uma vez logado, posso me mover e ler qualquer arquivo e diretório que eu possa ler.

Mas quando tento editar um arquivo -rw-r--r-- existente com o VIM, ele aparece como somente leitura, se eu tentar editar as permissões, recebo chmod: file.ext: Operation not permitted e, se eu tentar, scp , um novo arquivo de Na minha máquina local, sou solicitada a senha do usuário remoto e, em seguida, obtenho scp: /home/path/to/file.ext: Permission denied .

Como não tive nenhum desses problemas antes de tentar configurar a chave ssh, suspeito que essas anomalias sejam um efeito colateral disso, mas não sei como solucionar isso. Então, o que um servidor newb tolo, como eu, precisa fazer para recuperar o recurso de edição como um usuário remoto?

Adendo 1:

Meus userids são diferentes entre minha máquina local e o servidor remoto.

  • Para ssh, eu ssh -v [email protected] .
    • se eu whoami obtiver remoteuser
  • Para scp eu scp file.ext [email protected]:/path/to/file.ext do diretório local com file.ext enquanto logado como o usuário local.
    • se eu whoami obtiver localuser

O ls -l para dois arquivos diferentes que eu tentei scp:

-rw-r--r--@   1 localuser  localgroup    20 Feb 11 21:03 phpinfo.php
-rw-r--r--    1 root       localgroup     4 Feb 11 22:32 test.txt

O ls -l do arquivo que eu tentei para o VIM:

-rw-r--r--   1 remoteuser  remotegroup      76 Jul 27  2009 info.txt

Adendo 2:

No passado, eu configurei ssh-keys para repositórios git. Eu não quero destruí-los completamente, então, em uma tentativa de seguir linha de pensamento de um cervo eu renomeado meu ~/.ssh/ para ~/.ssh-bak/ , depois testei os diferentes tipos de acesso. A versão abreviada dos comandos e resultados do terminal está abaixo; Eu acho que tudo está funcionando até a 8ª linha do final.

ssh -v

localcomputer:~ localuser$ ssh -v [email protected]
OpenSSH_5.2p1, OpenSSL 0.9.8l 5 Nov 2009
debug1: Reading configuration data /etc/ssh_config
debug1: Connecting to remoteserver.com [###.###.###.###] port 22.
debug1: Connection established.
debug1: identity file /Users/localuser/.ssh/identity type -1
debug1: identity file /Users/localuser/.ssh/id_rsa type -1
debug1: identity file /Users/localuser/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.8p2 FreeBSD-20110503
debug1: match: OpenSSH_5.8p2 FreeBSD-20110503 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.2
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: 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
The authenticity of host 'remoteserver.com (###.###.###.###)' can't be established.
RSA key fingerprint is ##:##:##:##:##:##:##:##:##:##:##:##:##:##:##:##.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'remoteserver.com,###.###.###.###' (RSA) to the list of known hosts.
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
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: Trying private key: /Users/localuser/.ssh/identity
debug1: Trying private key: /Users/localuser/.ssh/id_rsa
debug1: Trying private key: /Users/localuser/.ssh/id_dsa
debug1: Next authentication method: password
[email protected]'s password: 
debug1: Authentication succeeded (password).
debug1: channel 0: new [client-session]
debug1: Requesting [email protected]
debug1: Entering interactive session.
Last login: Sun Feb 12 18:00:54 2012 from 68.69.164.123
FreeBSD 6.4-RELEASE-p8 (VKERN) #1 r101746: Mon Aug 30 10:34:40 MDT 2010

permissões remotas

[remoteuser@remoteserver /home]$ ls -l
total ###
-rw-r--r--   1 remoteuser remotegroup      76 Aug 12  2009 info.txt

[remoteuser@remoteserver /home]$ vim info.txt                                                                                                                                                                                                
~ {at the bottom of the VIM screen it tells me it's [read only]}                                                                                                                                                                                                    

[remoteuser@remoteserver /home]$ whoami 
remoteuser

[remoteuser@remoteserver /home]$ logout
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: client_input_channel_req: channel 0 rtype [email protected] reply 0
debug1: channel 0: free: client-session, nchannels 1
Connection to remoteserver.com closed.
Transferred: sent 3872, received 12496 bytes, in 107.4 seconds
Bytes per second: sent 36.1, received 116.4
debug1: Exit status 0

scp -v

localcomputer:localdirectory name$ scp -v phpinfo.php [email protected]:/home/www/remotedirectory/phpinfo.php
Executing: program /usr/bin/ssh host remoteserver.com, user remoteuser, command scp -v -t /home/www/remotedirectory/phpinfo.php
OpenSSH_5.2p1, OpenSSL 0.9.8l 5 Nov 2009
debug1: Reading configuration data /etc/ssh_config
debug1: Connecting to remoteserver.com [###.###.###.###] port 22.
debug1: Connection established.
debug1: identity file /Users/localuser/.ssh/identity type -1
debug1: identity file /Users/localuser/.ssh/id_rsa type -1
debug1: identity file /Users/localuser/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.8p2 FreeBSD-20110503
debug1: match: OpenSSH_5.8p2 FreeBSD-20110503 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.2
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: 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: Host 'remoteserver.com' is known and matches the RSA host key.
debug1: Found key in /Users/localuser/.ssh/known_hosts:1
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
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: Trying private key: /Users/localuser/.ssh/identity
debug1: Trying private key: /Users/localuser/.ssh/id_rsa
debug1: Trying private key: /Users/localuser/.ssh/id_dsa
debug1: Next authentication method: password
[email protected]'s password: 
debug1: Authentication succeeded (password).
debug1: channel 0: new [client-session]
debug1: Requesting [email protected]
debug1: Entering interactive session.
debug1: Sending command: scp -v -t /home/www/remotedirectory/phpinfo.php
Sending file modes: C0644 20 phpinfo.php
Sink: C0644 20 phpinfo.php
scp: /home/www/remotedirectory/phpinfo.php: Permission denied
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 1456, received 2160 bytes, in 0.6 seconds
Bytes per second: sent 2322.3, received 3445.1
debug1: Exit status 1
    
por YANewb 12.02.2012 / 19:39

3 respostas

3

Sua conta de usuário no host remoto provavelmente não tem permissões de gravação para o diretório /home/www/remotedirectory/ . Você pode testar isso executando:

scp -v phpinfo.php [email protected]:/tmp/phpinfo.php

Depois que isso for confirmado, você poderá definir permissões e / ou propriedade nesse diretório. Para uma correção rápida, chmod 777 /home/www/remotedirectory/ as root funcionará, mas essa não é uma solução segura. Dependendo de como o servidor é usado, melhor seria alterar o grupo do diretório usando chgrp para um grupo no qual você deseja que todos os escritores desse diretório estejam e chmod g+w /home/www/remotedirectory/

    
por 16.12.2013 / 01:46
2

Isso é puramente um problema de permissões. O usuário "remoteuser" em "remoteserver" não tem permissões para gravar arquivos em /home/www/remotedirectory/phpinfo.php . Veja este erro na saída dos comandos scp -v .. :

debug1: Sending command: scp -v -t /home/www/remotedirectory/phpinfo.php
Sending file modes: C0644 20 phpinfo.php
Sink: C0644 20 phpinfo.php
scp: /home/www/remotedirectory/phpinfo.php: Permission denied
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: channel 0: free: client-session, nchannels 1

Você pode confirmar isso fazendo ssh'ing em "remoteserver" exatamente como você fez originalmente e tentar e touch um arquivo neste diretório:

$ ssh remoteuser@remoteserver

no remoteserver

$ touch /home/www/remotedirectory/afile
touch: cannot touch ‘/home/www/remotedirectory/afile’: Permission denied

Você pode ver a propriedade desse diretório com este comando:

$ ls -ld /home/www/remotedirectory
drwxrwx---. 125 someuser somegroup 16384 Feb 22 14:03 /home/www/remotedirectory

Então você precisa alterar as permissões aqui ou tomar cuidado para adicionar "remoteuser" ao grupo "somegroup".

    
por 23.02.2014 / 15:18
0

bem, eu acho que a sua melhor opção é fazer funcionar com as teclas, mas aqui estão 2 opções

tente excluir o diretório ~/.ssh/authorized-keys ou todo ~/.ssh/ para se livrar das sobras de chaves

tente configurar as chaves corretamente e divirta-se sem senhas! link

    
por 12.02.2012 / 22:44