ssh root @ erro localhost; me ajude a hackear esta caixa

Question

Eu preciso ganhar um shell de root em um linux vm para uma classe de segurança. Eu tenho uma conta de usuário no sistema e um meio de gravar em qualquer arquivo (ou seja, / etc ...) e quero escalar meus privilégios com:

ssh root@localhost

Eu usei ssh-keygen para criar chaves rsa e adicionei-as a /root/.ssh/authorized_keys e modifiquei / etc / ssh / sshd_config para permitir conexões root. No entanto, não consigo me conectar à caixa como root. Esta é a saída:

Last login: Fri Jan 27 00:43:01 2012 from localhost
Connection to localhost closed.

Parece-me que a autenticação foi bem sucedida, no entanto a conexão é fechada imediatamente. Eu não tenho idéia porque isso não está funcionando.

A saída detalhada é:

OpenSSH_4.6p1 Debian-7, OpenSSL 0.9.8g 19 Oct 2007
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to localhost [127.0.0.1] port 22.
debug1: Connection established.
debug1: identity file /home/user/.ssh/identity type -1
debug1: identity file /home/user/.ssh/id_rsa type 1
debug1: identity file /home/user/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_4.6p1 Debian-7
debug1: match: OpenSSH_4.6p1 Debian-7 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.6p1 Debian-7
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 'localhost' is known and matches the RSA host key.
debug1: Found key in /etc/ssh/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,hostbased
debug1: Next authentication method: publickey
debug1: Trying private key: /home/user/.ssh/identity
debug1: Offering public key: /home/user/.ssh/id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 277
debug1: read PEM private key done: type RSA
debug1: Authentication succeeded (publickey).
debug1: channel 0: new [client-session]
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending command: /bin/bash
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: channel 0: free: client-session, nchannels 1
debug1: Transferred: stdin 0, stdout 0, stderr 0 bytes in 0.0 seconds
debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 0.0
debug1: Exit status 255

    

Answer 1

Existem três etapas gerais em um login SSH:

1. O SSH autentica o usuário (verificando se o solicitado possui uma senha ou chave privada ou algum outro método).
2. O SSH inicia uma sessão, que pode passar pelo PAM (e, portanto, pode falhar dependendo da configuração do PAM).
3. O SSH inicia um shell.

Desta parte do ssh -v trace:

debug1: Authentication succeeded (publickey).
debug1: channel 0: new [client-session]
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending command: /bin/bash

vemos que a autenticação foi bem-sucedida no nível do SSH, e o daemon ssh iniciou um shell ( /bin/bash ). Então é algo em /bin/bash ou sua configuração que impede o login. Verifique os arquivos de inicialização bash: ~root/.bash_login , ~root/.bash_profile , /etc/profile e outros arquivos que eles possam incluir. Tente um login não interativo: ssh root@localhost ls ; isso ainda vai passar pelo bash mas não pelos mesmos arquivos de inicialização (o bash é estranho, ele lê ~/.bashrc para um login não interativo quando seu pai é rshd ou sshd ).

Se houver algo quebrado em um arquivo de inicialização, você pode quebrar pressionando Ctrl + C no momento exato (após a sessão SSH ser estabelecida, para que O SSH enviará o Ctrl + C para o host remoto e não fechará a conexão, mas antes que a instrução problemática no arquivo de inicialização seja executada). Na prática, o momento certo pode ser alcançado manualmente com algumas tentativas; isso pode ajudar a carregar a máquina. Se você não conseguir fazer isso manualmente, um pequeno programa expect deve levá-lo até lá.

    

Answer 2

Além do que o Gilles mencionou, você também pode tentar mudar o shell do root para outra coisa em /etc/passwd . Além disso, verifique se /bin/bash não está (sym) vinculado a algo como /bin/false . A propósito, você já verificou, que id root é zero mesmo?