A couple of weeks ago I was pen testing a selection of Linux and Unix hosts in a relatively mature environment where they had build standards that were applied across all the hosts. One of these was setting up a standard batch user with SSH keys to allow jobs to be run across host from another one. This is a common configuration for *ix environments.

1. Ssh Generate Dsa Host Key Mac
2. Ssh Generate Dsa Host Key File

I had managed, through nefarious means (ok, the user had a weak password), to gain root access to a development server which had no production data on it. Could I gain access to other things?

Of course I could, or I wouldn’t be writing this article here and now!

How to Generate a Public/Private Key Pair for Use With Solaris Secure Shell. Users must generate a public/private key pair when their site implements host-based authentication or user public-key authentication. For additional options, see the ssh-keygen(1) man page. Before You Begin. Create RSA and DSA Keys for SSH Private and public RSA keys can be generated on Unix based systems (such as Linux and FreeBSD) to provide greater security when logging into a server using SSH. The ssh-keygen command allows you to generate, manage and convert these authentication keys. If both your client and server have OpenSSH 6.8 or newer, you can use the UpdateHostKeys yes option in your sshconfig or /.ssh/config.For example: Host. UpdateHostKeys yes This makes SSH store all host keys that the server has to knownhosts, and when a server changes or removes one host key, the key is also changed or removed in your knownhosts. Only 1024-bit DSA keys are interoperable in SSH, and this key size is no longer considered adequate when using the DSA algorithm. Generate either an ECDSA keypair, or an RSA keypair of size 2048 bits or larger.

SSH keys

So, whilst looking around the file system and looking for passwords in the various shell histories and standard scripts, I noticed that one user, let’s call it batchuser, had an SSH keypair defined; implying that it had been used to connect to other servers. Call of duty 2 download.

A bit of background: SSH can support a number of different authentication mechanisms, from the basic password to using keys. SSH keys follow conventional asymmetric authentication schemes: a keypair, consisting of a public and private key, is generated (saved, by default in the .ssh/id_rsa and .ssh/id-rsa.pub files on the client) and the public key is sent to the destination host. When the client tries to authenticate it signs the request with the private key and the server verifies with its copy of the public key and decides whether to give access.

All this is set up in files in the user’s .ssh directory, with authorised keys saved in the .ssh/authorized_keys file on the server.

So I found some keys, that doesn’t tell me which servers the user has access to does it? No, not really. Now I could farm through the shell histories or looks at the scripts, or I could just be lazy and use another facility of the SSH protocol.

Host keys

Each SSH server has its own key and signature which it presents upon initial connection by a client. This is an extra integrity step to minimise the risk of man-in-the-middle attacks. Once the host key has been accepted its signature is saved in .ssh/known_hosts on the client.

This means that we would have, at least the following files on the server

• .ssh/authorized_keys – holding the signature of the public key of any authorised clients

And the following files on the client:

• .ssh/id_rsa – Holds the private key for the client
• .ssh/id_rsa.pub – Holds the public key for the client
• .ssh/known_hosts – Holds a list of host signatures of hosts that the client has previously connected to

A couple of caveats:

1. This is for OpenSSH, commercial SSH uses different file names and formats.
2. id_rsa covers keypairs generate using the RSA algorithm. If DSA is used the filename is id_dsa

Making an Attack

Ssh Generate Dsa Host Key Mac

So… assuming we’ve compromised a client we had the private key and a list of servers that the host has connected to in the past, that means we can assume that some of the hosts in .ssh/known_hosts will have a password SSH connection set up.

So, let’s try it (in my mocked up recreation). We could do this by hand, but I’m lazy, so have a tiny bit of shell script that will do this for us:

What this does is ping the host (to make sure it’s up, then just tries to connect and run the simple command of “echo -n yes”. Running this in my mocked up environment returns with:

[[email protected] .ssh]$ for i in $(awk -F ‘[ ,]’ ‘{print $1}’ known_hosts);do echo -n “$i “;ping -n $i -c 1 2>&1 >/dev/null && ssh $i “echo -n yes” ;echo; done192.168.112.138 yes

192.168.112.133 yes

Ssh Generate Dsa Host Key File

192.168.112.131

So that’s it, I can assume I now have user access on 192.168.112.138 and 192.168.112.133, let’s try it:

Recommendations

This is mainly just to show how horizontal privilege escalation can be performed if an account has already been compromised.

There is an easy way to prevent this happening: don’t allow passwordless SSH keys to be used. Of course doing this makes it difficult to perform many cross-host activities that may be essential, or introduces more risk by having to store passwords in scripts. So this risk should be balanced with the requirements for regular tasks performed in your enterprise.

Diablo 3 key code generator. Features include: classic dungeon crawling gameplay, a new batch of character classes, multiplayer options with friends and single player support with the help of AI companions, a new take on character skill assignment and health, online item auctioning, and compatibility with Windows and Mac operating systems. Only the third major release in what is considered by many gamers as the most iconic RPG franchise of all time, Diablo 3 continues the land of Sanctuary's battle against a reoccurring demonic evil, and provides players around the world with the opportunity to create the ultimate hero to quest against it with friends online, or on their own. Diablo III is a fantasy Action Role-Playing Game (RPG).

Either way, the *ix administrators need to understand the risks of using SSH keys and to ensure that different environments (e.g. production and development) are not crossed.

Another way of minimising the risk is to minimise the number of hosts that have access by restricting it to one or two management hosts.

How do I create a host key file to use with my applications as I can not use system defined /etc/ssh/ssh_host_rsa_key for non-root account under Linux / Unix / Apple OS X / *BSD operating systems?
You need to use a command called ssh-keygen. This command generates, manages and converts authentication keys for ssh. It can create RSA keys for use by SSH protocol version 1 and RSA or DSA keys for use by SSH protocol version 2. he type of key to be generated is specified with the -t option. If invoked without any arguments, ssh-keygen will generate an RSA key for use in SSH protocol 2 connections. The -f option specifies the filename of the key file.

Why create a new host key files?

You may need a new key file:

1. Your system is compromised.
2. Your keys are stolen.
3. You forgotten the passphrase.
4. Your application need a new host key.
5. You can not read the default system key files stored in /etc/ssh/ directory but your non-root application needs key.
6. You got an error message which read as “Could not load host key: /etc/ssh/ssh_host_key*”.

ssh-keygen Syntax

The syntax is:

Example

Create a host key file in your $HOME/.ssh/myapp as follows. First, create a directory to store your host key file, enter:
$ mkdir -p $HOME/.ssh/myapp
To create a host RSAv2 key file, run:
$ ssh-keygen -t rsa -f $HOME/.ssh/myapp/rsa_key_file
Sample outputs:

Type the following commands to verify the keys:
$ ls -l $HOME/.ssh/myapp/
Sample outputs:

You can now use keys with your app:
$ mycool-app -key $HOME/.ssh/myapp/rsa_key_file -d

ADVERTISEMENTS