1

I need to gain a root shell on a linux vm for a security class. I have a user account on the system and a means to write to any file (i.e. /etc...) and want to escalate my privileges with:

ssh root@localhost

I used ssh-keygen to make rsa keys and added them to /root/.ssh/authorized_keys, and modified /etc/ssh/sshd_config to allow root connections. However, I cannot connect to the box as root. This is the output:

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

It seems to me that the authentication succeded, however the connection is closed immediately. I have no idea why this isn't working.

The verbose output is:

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
2
  • Have you checked that root as a proper shell in /etc/passwd? Also, if you can write every file you don't need ssh. Commented Jan 27, 2012 at 9:20
  • 1
    I would expect ssh root is not allowed. The root account should only be accessed by somebody sitting at the console or by a user who must login to their user account then use su. Commented Jan 27, 2012 at 12:57

3 Answers 3

7

There are three broad steps in an SSH login:

  1. SSH authenticates the user (by checking that the requested possesses a password or private key, or some other method).
  2. SSH initiates a session, which can go through PAM (and so may fail depending on the PAM configuration).
  3. SSH starts a shell.

From this part of the 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

we see that the authentication succeeded at the SSH level, and the ssh daemon started a shell (/bin/bash). So it's something in /bin/bash or its configuration that prevents the login. Check the bash initialization files: ~root/.bash_login, ~root/.bash_profile, /etc/profile and other files they may include. Try a non-interactive login: ssh root@localhost ls; this will still go through bash but not through the same initialization files (bash is weird, it reads ~/.bashrc for a non-interactive login when its parent is rshd or sshd).

If there's something broken in an initialization file, you can break out by pressing Ctrl+C at exactly the right time (after the SSH session is established, so that SSH will send the Ctrl+C to the remote host and not close the connection, but before the troublesome instruction in the initialization file is executed). In practice the right time can often be achieved manually with a few tries; it may help to load the machine. If you can't make it manually, a small expect program should get you there.

0

Apart from what Gilles mentioned, you can also try to change root's shell to something else in /etc/passwd. Also check, that /bin/bash is not (sym)linked to something like /bin/false. By the way, have you checked, that id root is zero indeed?

0

My wild guess is that the home path in /etc/passwd, doesn't exist or has wrong ownership/permissions.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .