Eu tenho dois sistemas chamados Interface (10.1.1.87) e Client-Interface (10.1.1.91). Eu quero montar automaticamente um compartilhamento sshfs da interface do cliente na interface na inicialização.
Estou usando o comando:
sshfs [email protected]:/opt/lampp/ /media/CIDrive/ -o allow_other
Mas pede minha senha. Eu tentei o seguinte para torná-lo sem senha:
Como root na interface:
# ssh-keygen -t rsa
# chmod 700 ~/.ssh
# cat ~/.ssh/id_rsa.pub | ssh [email protected] 'cat > .ssh/authorized_keys'
Na interface do cliente, adicionei ao arquivo sshd_config :
RSAAuthentication yes
PubkeyAuthentication yes
StrictModes no
e reiniciou o daemon SSH. No entanto, ainda está pedindo a senha:
root@JMGDDS-Interface:~# ssh -v [email protected]
OpenSSH_5.1p1 Debian-3ubuntu1, OpenSSL 0.9.8g 19 Oct 2007
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to 10.1.1.91 [10.1.1.91] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: identity file /root/.ssh/identity type -1
debug1: identity file /root/.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 /root/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.1p1 Debian-3ubuntu1
debug1: match: OpenSSH_5.1p1 Debian-3ubuntu1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.1p1 Debian-3ubuntu1
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc 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 '10.1.1.91' is known and matches the RSA host key.
debug1: Found key in /root/.ssh/known_hosts:2
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: /root/.ssh/identity
debug1: Offering public key: /root/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /root/.ssh/id_dsa
debug1: Next authentication method: password
[email protected]'s password:
A permissão para a pasta .ssh é 700; .pub e authorized_keys são 600. Qual poderia ser a causa possível? Como posso consertar isso?
Eu não verifiquei recentemente, mas se qualquer diretório no caminho para o .ssh for mundial, o SSH recusaria usar chaves autorizadas dele. Essas permissões podem permitir que outros usuários façam você com o diretório .ssh.
Se o diretório pessoal for gravável por qualquer outra pessoa, ele não será usado, a menos que o StrictModes esteja desativado.
Verifique se na sua máquina local você tem um arquivo ~/.ssh/id_dsa com o modo 600 e se o conteúdo do local ~/.ssh/id_dsa.pub também está no arquivo ~/.ssh/authorized_keys remoto.
Estou dizendo id_dsa porque é uma das suas chaves privadas de acordo com seus registros (você também tem uma chave identity privada). Talvez você possa especificar qual PrivateKey deseja usar em ~/.ssh/config under Host your.server.here . Alternativamente, você pode verificar o mesmo para ~/.ssh/id_rsa e ~/.ssh/id_rsa se você tiver um par de chaves rsa.
Usar ssh_copy_id -i ~/.ssh/id_dsa.pub user@host (se disponível) é outra maneira de configurar pares de chaves, que também cuida das permissões, etc.
Verifique as permissões no host 10.1.1.91 do diretório .ssh/ e no arquivo .ssh/authorized_keys . Talvez o sshd nesse host não goste das permissões nesse ponto.
Como seu sshd_conf se parece? Tem certeza de que "StrictModes não" não é comentado?
Execute o servidor no modo de depuração.
No servidor, como root:
# /etc/init.d/ssh stop
# /usr/sbin/sshd -ddd
Agora conecte-se ao cliente e leia a saída de depuração do servidor. Isso deve dar uma indicação de por que você não pode entrar. Corrija o que for .
Se acontecer de você estar executando o RedHat (ou possivelmente o Fedora), eu me deparei com um problema com o pam_fprintd não sendo instalado .
Tarde demais para responder, mas acho que esses dois pontos são muito importantes Verifique a permissão do seu diretório pessoal no servidor também. Eu enfrentei um problema semelhante e o problema era a permissão do diretório inicial. Então duas coisas
sshd por padrão registra algumas mensagens em /var/log/secure pelo menos na distribuição do fedora. Verifique a razão pela qual você está com permissão recusada.
Procure por esta linha
sshd[1234]: Authentication refused: bad ownership or modes for file /home/user/.ssh/authorized_key
sshd[1234]: Authentication refused: bad ownership or modes for file /home/user