Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

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. Does anybody have any suggestions?

Thanks,

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
share|improve this question
    
Have you checked that root as a proper shell in /etc/passwd? Also, if you can write every file you don't need ssh. –  Stéphane Gimenez Jan 27 '12 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. –  Stephen Quan Jan 27 '12 at 12:57
add comment

migrated from superuser.com Jan 27 '12 at 8:37

This question came from our site for computer enthusiasts and power users.

2 Answers

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.

share|improve this answer
add comment

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?

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.