I am trying to practice ethical hacking in my own lab. I have got limited shell in a fedora box in addition I am able to read root files like /etc/shadow trough another vulnerability.

Now, I need to get the box rooted, I tried to crack the root hash in /etc/shadow but no luck. I though of getting in using ssh keys.

I managed to get the content of /root/.ssh/authorized_keys and thought that I can use it to authenticate without a password. however, when I issued the following command :

     root@kali:~/Desktop# ssh -o BatchMode=yes -i ~/Desktop/x.pem [email protected]

Permission denied (publickey,gssapi-with-mic,password).

I get the error above -where x.pem is just a file i used to save a copy of the key found in authorized_keys as it is on the victim machine. any idea what is the problem? or another suggested way to get a root privileges ?


  • Out of curiosity, what vulnerability allows you to read /etc/shadow and /root ?
    – Matrix
    Commented Oct 15, 2013 at 7:18

2 Answers 2


~/.ssh/authorized_keys contains the public key, you need the corresponding private key to login. Private keys usually look like ~/.ssh/id_rsa, ~/.ssh/id_dsa, ~/.ssh/something.id_rsa, etc.

Unfortunately you didn't post enough information on what privileges you exactly have / the possibilities your vulnerability provides (can you only read files as root, can you execute anything as root?).

  • I can only read files as root but can not execute. Regarding the box, It is publishing Webmin Service at the following port: 10000/tcp open http MiniServ 0.01 (Webmin httpd). I noticed that there is a file for Webmin that contains both private and public key for Webmin but can not figure out how to use this -the file that contains both public and private key is /etc/webmin/miniserv.pem ! Commented Oct 17, 2013 at 0:18

As @RSchulze points out, you need the private key to log in, not the public key. Specifically, the sshd server will grant access if the client demonstrates control (by computing a signature on a challenge) of the private key corresponding to one of the public keys stored in the .ssh/authorized_keys.

Note that this implies that if you can write in .ssh/authorized_keys, not merely read it, then you can put a public key of your choice here, e.g. one for which you know the private key (because you generated it). Alternatively, if this box was meant to be hacked for educational purposes, then it is possible that there is a weak public key in the .ssh/authorized_keys put there on purpose (it depends on whether whoever installed this system wanted to educate you on cryptography specifically).

Also note that in many systems, root login through SSH is deactivated. See the /etc/ssh/sshd_config file; this is the PermitRootLogin option. You may want to check that before pursuing this path. Although if the local root user has a .ssh/authorized_keys, then root login is probably permitted (that file would not make a lot of sense otherwise).

  • This is really a very good hint to know. however, is there is a practical/online/tool way for cracking a public key ? Commented Oct 17, 2013 at 0:24

You must log in to answer this question.

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