Não é possível o SSH para o Google Cloud Engine do Ubuntu ou Debian

1

Eu tento usar o ssh no meu google cloud insance usando o linux local. Gerei as chaves usando os documentos

ssh-keygen -t rsa -f ~ / .ssh / minha-chave-ssh-C [NOME DE USUÁRIO]

Em seguida, colocar a chave do pub nos metadados. Mas isso não funciona eu sempre obter uma conexão negada por permissão negada (publickey). Além disso, a conexão com o shell da web não funciona. Com as chaves ssh antigas em outra máquina, funciona.

Alguém tem uma idéia de qual é o problema?

Atenciosamente, Alex

    
por Alexander Meis 13.07.2017 / 08:20

2 respostas

2

A menos que você diga especificamente para fazer o contrário, o SSH oferece ~/.ssh/id_<type> (por exemplo, ~/.ssh/id_rsa ) para autenticação.

Você criou uma chave em um local não padrão (dentro de ~ / .ssh, mas com um nome de arquivo não padrão).

Como a autenticação de chave pública em geral funciona para você, a primeira coisa que eu verificaria é que o SSH oferece a chave correta para autenticação. Você pode verificar isso executando ssh com a opção -v para ativar um nível de saída detalhada (depuração). Entre as mensagens, você deve ver algo como:

debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/you/.ssh/something

Veja quais chaves públicas ele oferece. (Você pode ter várias linhas Offering ... public key , para diferentes arquivos-chave.) Se ele não oferecer sua chave recém-criada, essa chave será nunca ser um candidato para autenticação.

Se a sua chave recém-criada não for oferecida, tente dizer explicitamente ao SSH para oferecê-la, adicionando a opção -i . Por exemplo, ssh -i ~/.ssh/my-ssh-key -v username@hostname . Note que o SSH irá adicionar .pub ao nome onde precisa acessar a chave pública, então você dá o nome do arquivo de chave privada.

Se isso funcionar, você pode editar seu ~/.ssh/config para informar ao SSH que ofereça essa chave a esse host. Por exemplo, você poderia adicionar um bloco como o seguinte. Certifique-se de adicioná-lo acima de qualquer bloco Host * que você possa ter.

Host hostname
    User username
    IdentityFile ~/.ssh/my-ssh-key

Então você deve conseguir se conectar usando apenas ssh hostname .

Veja man 1 ssh e man 5 ssh_config para mais detalhes.

    
por 13.07.2017 / 08:35
0

Obrigado pela sua resposta. Eu acho que id fez assim. Aqui está um log, talvez haja algo errado, mas não consigo identificá-lo.

OpenSSH_7.2p2 Ubuntu-4ubuntu2.2, OpenSSL 1.0.2g  1 Mar 2016
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to ccc.ccc.cc [aaa.aaa.aaa.aa] port 22.
debug1: Connection established.
debug1: identity file /home/foo/.ssh/id_rsa type 1
debug1: key_load_public: No such file or directory
debug1: identity file /home/foo/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/foo/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/foo/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/foo/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/foo/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/foo/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/foo/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.2p2 Ubuntu-4ubuntu2.2
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.7p1 Debian-5+deb8u3
debug1: match: OpenSSH_6.7p1 Debian-5+deb8u3 pat OpenSSH* compat 0x04000000
debug1: Authenticating to sdev.meilon.de:22 as 'foo'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: [email protected]
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: [email protected] MAC: <implicit> compression: none
debug1: kex: client->server cipher: [email protected] MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:D8f511w+xDWBS2z8E212LT369D3og2J4CYRsmE1ETwM
debug1: Host 'sdev.meilon.de' is known and matches the ECDSA host key.
debug1: Found key in /home/foo/.ssh/known_hosts:1
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/foo/.ssh/id_rsa
debug1: Authentications that can continue: publickey
debug1: Offering RSA public key: foo@foo-x1
debug1: Authentications that can continue: publickey
debug1: Trying private key: /home/foo/.ssh/id_dsa
debug1: Trying private key: /home/foo/.ssh/id_ecdsa
debug1: Trying private key: /home/foo/.ssh/id_ed25519
debug1: No more authentication methods to try.
Permission denied (publickey).
    
por 13.07.2017 / 12:35