I am attempting to install SLAD installer on Ubuntu 10.04 but have run into installation issues with setting up the RSA key and then try to load it into the SLAD installer as shown below:

Repository:
http://wald.intevation.org/frs/?group_id=29

Download:
http://wald.intevation.org/frs/downl...r-1.1.2.tar.gz

Install guide:
http://www.openvas.org/using-slad.html

Installation:

user@user:~/sladinstaller-1.1.2$

http://www.openvas.org/performing_lsc.html

Howto: Perform local security checks

This text explains how to run local security checks with OpenVAS. So far, this procedure has been tested only with Debian local security checks.
Create users for local security checks

First, you need a key with certificate:

$ ssh-keygen -t rsa -f ~/.ssh/id_rsa_sshovas -C "OpenVAS-Local-Security-Checks-Key"
user@user:~$ ssh-keygen -t rsa -f ~/.ssh/id_rsa_sshovas -C "OpenVAS-Local-Security-Checks-Key"
Generating public/private rsa key pair.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/user/.ssh/id_rsa_sshovas.
Your public key has been saved in /home/user/.ssh/id_rsa_sshovas.pub.
The key fingerprint is:
X:X:X:X:X:X:X:X:X:X:X:X:X:X:X:X:X OpenVAS-Local-Security-Checks-Key
The key's randomart image is:
X:X:X:X:X:X:X:X

ISSUE 1:
The key generation runs fine but verifying the key is the issue as it asks for an encryption password which I did not set and not sure what is:

user@user:~$ openssl pkcs8 -topk8 -v2 des3 -in ~/.ssh/id_rsa_sshovas -out sshovas_rsa.p8
Enter pass phrase for /home/user/.ssh/id_rsa_sshovas:
Enter Encryption Password:
Verifying - Enter Encryption Password:
Verification failure

a second attempt results with this error message:

user@user:~$ openssl pkcs8 -topk8 -v2 des3 -in ~/.ssh/id_rsa_sshovas -out sshovas_rsa.p8
Enter pass phrase for /home/user/.ssh/id_rsa_sshovas:
Enter Encryption Password:
Verifying - Enter Encryption Password:
unable to write 'random state'

How can this be corrected, are the appropriate flags been used?

Create user "sshovas":

user@user:~$ sudo su
root@user:/home/user# adduser --disabled-password sshovas
Adding user `sshovas' ...
root@user:/home/user# su - sshovas
sshovas@user:~$ mkdir .ssh
sshovas@user:~$ logout
root@user:/home/user# cp /home/user/.ssh/id_rsa_sshovas.pub /home/sshovas/.ssh/authorized_keys
When running the SLAD installer the following error message occurs:

root@user:/home/user# /usr/bin/sladinstaller

ISSUE 2:
SLADINSTALLER window will appear, enter the following:

Package: http://www.dn-systems.org/boss/slad-...urrent.tar.bz2
Hostname: 127.0.0.1
Root password: XXXXXXXXXX
SLAD SSH Public Key:/home/user/.ssh/id_rsa_sshovas.pub

Error message:
Installation was not successfull. Could not login via SSH. If you don't have a public key installed be sure to set the following options in the sshd_config file:
PermitRootLogin yes
PasswordAuthentication yes

Apart from editing the sshd_config file how should the key verification process be corrected, plus is the correct keyfile being used and from the correct user?

It sounds like you may have messed up part of the process where you create the SSH key for the OpenVAS user account to allow it to SSH into your system to perform it's checks. From the last link you referenced, see this part:

I have the passphrase but during the setup, it did not ask for an Encryption Password which is different to the passphrase. I assumed the passphrase was all that was needed as the guide did not indicate if an encryption password was to be created which you can see from my ssh key generation.

The verification of the key is the issue as I did not set up an Encryption password at any stage or was prompted to by the openssl command.

Do you know how the encryption password is created and when?

The first command creates the RSA key for SSH. This will prompt you for a password, but not the "encryption" password. The second command which converts this RSA key to a p8 key will prompt you for an "encryption" password. At least it did when I ran these commands as a test a few minutes ago. According to the documentation this second (encryption) passphrase is the one you need to use and remember. If your openSSL command didn't prompt you for an encryption passphrase, what did it say? Was there perhaps an error running this second command?

Here is what the output looked like when I ran this. Note I changed the directories and file names for testing purposes, but this shouldn't matter

The first time I did that this is what happened: Note I did not get the same result as you

Verifying - Enter Encryption Password:
~$

My first attempt:

user@user:~$ openssl pkcs8 -topk8 -v2 des3 -in ~/.ssh/id_rsa_sshovas -out sshovas_rsa.p8
Enter pass phrase for /home/user/.ssh/id_rsa_sshovas:
Enter Encryption Password:
Verifying - Enter Encryption Password:
unable to write 'random state'

I assumed I had to create an Encrytion password, which I tried to by entering a new Encryption password (not the ssh passphrase).
Or, openssl assumed that an Encryption password already existed (maybe from when openssl was installed??)

In any case, subsequent attempts to verify the Encryption password go as follows:

(using password from first Encryption password prompt)
user@user:~$ openssl pkcs8 -topk8 -v2 des3 -in ~/.ssh/id_rsa_sshovas -out sshovas_rsa.p8
Enter pass phrase for /home/user/.ssh/id_rsa_sshovas:
Enter Encryption Password:
Verifying - Enter Encryption Password:
unable to write 'random state'

(using different password for subsequent prompts)
user@user:~$ openssl pkcs8 -topk8 -v2 des3 -in ~/.ssh/id_rsa_sshovas -out sshovas_rsa.p8
Enter pass phrase for /home/user/.ssh/id_rsa_sshovas:
Enter Encryption Password:
Verifying - Enter Encryption Password:
Verify failure

So unless I can create/retrieve this Encryption password, I will have to recreate the ssh-keygen with passphrase and the confusing Encryption Password to verify the key.

Any ideas?

You are getting an error message, possibly a permissions error message when you try to create the p8 key: See the following link for some suggestions on how to address this issue: http://stackoverflow.com/questions/9...dom-state-mean

Fromt the link, the first things to check are the file ownership and permissions. Second, it looks like sometimes openssl needs to be run as root.

Great that worked!

user@user:~$ sudo chown user:user ~/.rnd
user@user:~$ openssl pkcs8 -topk8 -v2 des3 -in ~/.ssh/id_rsa_sshovas -out sshovas_rsa.p8
Enter pass phrase for /home/user/.ssh/id_rsa_sshovas:
Enter Encryption Password:
Verifying - Enter Encryption Password:
user@user:~$

Next issue is the SLAD Installer:

"Installation was not successfull. Could not login via SSH. If you don't have a public key installed be sure to set the following options in the sshd_config file:
PermitRootLogin yes
PasswordAuthentication yes"

I assume it has to do with the .ssh/ file permissions again which I now changed to and ran as both sudo and as user "root":

user@user:~$ sudo chmod 700 ~/.ssh
user@user:~$ sudo chmod 600 ~/.ssh/id_rsa_sshovas
user@user:~$ sudo chmod 644 ~/.ssh/id_rsa_sshovas.pub

Same result as in screenshot attached:

Attached Thumbnails

 

PermitRootLogin yes and PasswordAuthentication yes are dangerous options because it will expose you to brute force dictionary attack against the most common user name in Linux. I would strongly recommend that you not leave these options enabled in your system.

Off the top of my head, I don't have a direct answer for you as far as fixing the problem, but I suspect it has something to do with the location where the public key is stored (~/.ssh/id_rsa_sshovas.pub) versus the user account that is being used to try and gain SSH access. Is there an ovas account with a home directory? If I am not mistaken, when the SSH authentication attempt is made, the check will be made in the .ssh folder under the user home directory.

What I would suggest is turning on ssh debugging. See this link: http://blog.codefront.net/2007/02/28...tion-problems/
Even better, have a look at this one: http://www.tek-tips.com/faqs.cfm?fid=6934 which discusses turning on debugging at the server end (which I think is what you need).

The way I would proceed is to first see if your auth.log (or other log file) shows some additional information that may prove helpful. Then turn on server level debugging and watch the transaction. Once you identify the log file, you can "tail -f" it in a terminal window to watch what is happening in real time. You will probably find either a missing file (not where it is suppose to be) or a permissions problem.

According to the openvas SLAD installer setup, the keys are located in the following directories:

Done using my own account (user)

$ ssh-keygen -t rsa -f ~/.ssh/id_rsa_sshovas -C "OpenVAS-Local-Security-Checks-Key"
$ openssl pkcs8 -topk8 -v2 des3 -in ~/.ssh/id_rsa_sshovas -out sshovas_rsa.p8

user@user:~$ ls -ld /home/user/.ssh/
drwx------ 2 user user 4096 2012-02-21 14:33 /home/user/.ssh/
user@user:~$ ls -l /home/user/.ssh/
total 12
-rw------- 1 user user 1743 2012-02-21 14:33 id_rsa_sshovas
-rw-r--r-- 1 user 415 2012-02-21 14:33 id_rsa_sshovas.pub
-rw-r--r-- 1 user 833 2012-02-21 16:51 known_hosts

Done with root account

# adduser --disabled-password sshovas
Name: OpenVAS Local Security Checks
# su - sshovas
$ mkdir .ssh
$ cp /some/path/id_rsa_sshovas.pub .ssh/authorized_keys
$ chmod 500 .ssh
$ chmod 400 .ssh/authorized_keys

root@user:/home/user# su - sshovas

Done with sshovas account (as you can see it has a home directory)
sshovas@user:~$ ls -ld /home/sshovas/.ssh/
dr-x------ 2 sshovas sshovas 4096 2012-02-21 16:46 /home/sshovas/.ssh/
sshovas@user:~$ ls -l /home/sshovas/.ssh/authorized_keys
-r-------- 1 root root 415 2012-02-21 16:46 /home/sshovas/.ssh/authorized_keys

http://www.openvas.org/using-slad.html

6. It might be necessary for you to adjust the sshd configuration of the target system to enable SLADinstaller to log in. In this case, SLADinstaller will provide you with instructions on how to do this.

Ideally as you said, it should not be changed, the sshd_config file, for security reasons, so I won't change it.

The private key and public key are still in my own account /home/user/.ssh
The public key was copied as the file, authorized_keys, to the sshovas account /home/sshovas/.ssh

So should I delete the public key from my own account /home/user/.ssh or change the permissions in any of the above directories?

I was thinking I could try to log in also this way:

http://www.eng.cam.ac.uk/help/jpmg/s...eys_howto.html

slogin -i ~/.ssh/filename remotehost

user@user:~$ ssh -vvv localhost uptime

debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /home/user/.ssh/identity
debug3: no such identity: /home/user/.ssh/identity
debug1: Trying private key: /home/user/.ssh/id_rsa
debug3: no such identity: /home/user/.ssh/id_rsa
debug1: Trying private key: /home/user/.ssh/id_dsa
debug3: no such identity: /home/user/.ssh/id_dsa
debug2: we did not send a packet, disable method

user@user:~$ /usr/sbin/sshd -p1234 -d
debug1: sshd version OpenSSH_5.3p1 Debian-3ubuntu7
Could not load host key: /etc/ssh/ssh_host_rsa_key
Could not load host key: /etc/ssh/ssh_host_dsa_key
debug1: setgroups() failed: Operation not permitted

user@user:~$ ssh -p1234 localhost uptime
ssh: connect to host localhost port 1234: Connection refused

root@user:/home/user# su - sshovas
sshovas@user:~$ ssh -vvv localhost uptime

debug3: check_host_in_hostfile: filename /home/sshovas/.ssh/known_hosts
debug3: check_host_in_hostfile: filename /etc/ssh/ssh_known_hosts
debug3: check_host_in_hostfile: filename /home/sshovas/.ssh/known_hosts
debug3: check_host_in_hostfile: filename /etc/ssh/ssh_known_hosts
debug2: no key of type 0 for host localhost
debug3: check_host_in_hostfile: filename /home/sshovas/.ssh/known_hosts2
debug3: check_host_in_hostfile: filename /etc/ssh/ssh_known_hosts2
debug3: check_host_in_hostfile: filename /home/sshovas/.ssh/known_hosts
debug3: check_host_in_hostfile: filename /etc/ssh/ssh_known_hosts
debug2: no key of type 2 for host localhost

debug1: Trying private key: /home/sshovas/.ssh/identity
debug3: no such identity: /home/sshovas/.ssh/identity
debug1: Trying private key: /home/sshovas/.ssh/id_rsa
debug3: no such identity: /home/sshovas/.ssh/id_rsa
debug1: Trying private key: /home/sshovas/.ssh/id_dsa
debug3: no such identity: /home/sshovas/.ssh/id_dsa
debug2: we did not send a packet, disable method

sshovas@localhost's password:
debug3: packet_send2: adding 64 (len 52 padlen 12 extra_pad 64)
debug2: we sent a password packet, wait for reply
debug3: Wrote 144 bytes for a total of 1271
Connection closed by UNKNOWN
sshovas@user:~$ #/usr/sbin/sshd -d -p 2222
sshovas@user:~$ /usr/sbin/sshd -d -p 2222
debug1: sshd version OpenSSH_5.3p1 Debian-3ubuntu7
Could not load host key: /etc/ssh/ssh_host_rsa_key
Could not load host key: /etc/ssh/ssh_host_dsa_key
debug1: setgroups() failed: Operation not permitted
debug1: rexec_argv[0]='/usr/sbin/sshd'
debug1: rexec_argv[1]='-d'
debug1: rexec_argv[2]='-p'
debug1: rexec_argv[3]='2222'
debug1: Bind to port 2222 on 0.0.0.0.
Server listening on 0.0.0.0 port 2222.
debug1: Bind to port 2222 on ::.
Server listening on :: port 2222.

sshovas@user:~$ tail -f /var/log/auth.log
tail: cannot open `/var/log/auth.log' for reading: Permission denied
tail: no files remaining
sshovas@user:~$ sudo tail -f /var/log/auth.log
[sudo] password for sshovas:
Sorry, try again.
[sudo] password for sshovas:
Sorry, try again.
[sudo] password for sshovas:
Sorry, try again.
sudo: 3 incorrect password attempts
sshovas@user:~$ ssh-add -l
Could not open a connection to your authentication agent.

The account sshovas had no password created with it hence, when password authentication is required for the tests this is an issue.

Since the target system is on my own machine,should it work?
Instead of setting up the account sshovas on another remote machine and testing it there, I would like to be able to do a security login attempt on my own machine to test it.

Edited /etc/ssh/sshd_config file to this (as both we set to "yes" by default):

# Authentication:

PermitRootLogin no


# Change to no to disable tunnelled clear text passwords
#PasswordAuthentication no

Copied the pub key as it is to the ssh directory of sshovas instead of renaming it as authorized keys:

root@user:/home/user# cp -r /home/user/.ssh/id_rsa_sshovas.pub /home/sshovas/.ssh/

Changed the permissions of the each relative directory so only root has "rwx" in each directory, users and groups have only "r"
i.e. /home/sshovas/.ssh

Ran the SLAD installer:

root@user:/home/user# /usr/bin/sladinstaller

Still get the same error message!

Installation was not successfull. Could not login via SSH. If you don't have a public key installed be sure to set the following options in the sshd_config file:
PermitRootLogin yes
PasswordAuthentication yes

From your previous two posts, it looks like the SSH session is not able to find the correct key file. It looks like you originally named the file id_rsa_sshovas.pub. From the debug information, the SSH login is looking for identity, id_rsa, or id_dsa, none of which are going to match. As part of the configuration process, did you not specify the key file which would be used? (I can't recall and hence I am asking).

When you created the key pair, there would have been a public and a private key. The public key should have been APPENDED INTO the file authorized-keys file in the user's .ssh folder, where user is the user name that will be performing the login (the server). The private key should remain the in the .ssh folder of the system that will be performing the login. It is typically called id_rsa (the remote client).

The Ubuntu documentation has a pretty good explanation of this setup. I suspect that there is a step or two missing from the openVAS installation instructions and that the configuration for keyless SSH isn't quite right. Please have a look at the documentation here and see if it helps conceptually clear up some of what you have been doing and perhaps give you some ideas of where to put the individual key components.

I am doing the installation on my own machine (by creating another user account called sshovas) and not on a separate machine/server.

Originally, I followed the openvas instructions of:

$ ssh-keygen -t rsa -f ~/.ssh/id_rsa_sshovas -C "OpenVAS-Local-Security-Checks-Key"
$ openssl pkcs8 -topk8 -v2 des3 -in ~/.ssh/id_rsa_sshovas -out sshovas_rsa.p8

# adduser --disabled-password sshovas
Name: OpenVAS Local Security Checks
# su - sshovas
$ mkdir .ssh
$ cp /some/path/id_rsa_sshovas.pub .ssh/authorized_keys
$ chmod 500 .ssh
$ chmod 400 .ssh/authorized_keys

So, the id_rsa file should not have sshovas added to the end of it and should remain as it is:
id_rsa_ (Correct?)
not:
id_rsa_sshovas (Incorrect?)

Either I change the file name or change the sshd_config file at this section:
# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key --------> HostKey /etc/ssh/ssh_host_rsa_key(not sure how to edit it)

Did the troubleshooting according to the Ubuntu SSH guide but it did not work assuming the name of public key is the issue:

sshovas@user:/$ sudo mkdir /etc/ssh/sshovas/
[sudo] password for sshovas:
sshovas@user:/$ ls -ld /etc/ssh/sshovas/
drwxr-xr-x 2 root root 4096 2012-02-24 11:22 /etc/ssh/sshovas/
sshovas@user:/$ sudo chmod 755 /etc/ssh/sshovas/
sshovas@user:/$ sudo sudo chown -R sshovas:sshovas /etc/ssh/sshovas/
sshovas@user:/$ ls -ld /etc/ssh/sshovas/
drwxr-xr-x 2 sshovas sshovas 4096 2012-02-24 11:22 /etc/ssh/sshovas/

sshovas@user:/$ sudo cp /home/sshovas/.ssh/authorized_keys /etc/ssh/sshovas/
sshovas@user:/$ sudo chown -R sshovas:sshovas /etc/ssh/sshovas/authorized_keys
sshovas@suser:/$ sudo chmod 644 /etc/ssh/sshovas/authorized_keys
sshovas@user:/$ ls -l /etc/ssh/sshovas/authorized_keys
-rw-r--r-- 1 sshovas sshovas 415 2012-02-24 11:29 /etc/ssh/sshovas/authorized_keys

sshovas@user:/$ sudo nano /etc/ssh/sshd_config
Changed from:
#AuthorizedKeysFile %h/.ssh/authorized_keys
to:
#AuthorizedKeysFile /etc/ssh/sshovas/authorized_keys

The same error message when /usr/bin/installer is launched as root

Installation was not successfull. Could not login via SSH. If you don't have a public key installed be sure to set the following options in the sshd_config file:
PermitRootLogin yes
PasswordAuthentication yes

So either rename the public key file or perform the SLAD installer on another machine (copy the public key to this other machine)?

Ok, I have some good news on the ssh front as I managed to finally ssh from my local machine to a remote machine on the network.

The user "sshovas" on the remote machine needs to be setup with a password in order to authenticate certain stages in the ssh setup and rename the public and private keys as shown below:

$ ssh-keygen -t rsa -f ~/.ssh/id_rsa -C "OpenVASLocalSecurityChecksKey"
$ openssl pkcs8 -topk8 -v2 des3 -in ~/.ssh/id_rsa -out id_rsa.p8

Setup user "sshovas"

# adduser --disabled-password sshovas
Name: OpenVAS Local Security Checks
# su - sshovas
$ mkdir .ssh
$ cp /some/path/id_rsa.pub .ssh/authorized_keys
$ chmod 500 .ssh
$ chmod 400 .ssh/authorized_keys

I had to make changes to this as the user "sshovas" requires a password for authentication as shown later (may impact on the sladinstaller though?)

On the remote machine add the this:
root@remote:~$ sudo visudo

# User privilege specification
root ALL=(ALL) ALL
sshovas ALL=(ALL) ALL

Enable the "sshovas" account and create a password in System/Administration/Users and Groups and add other privileges.

During previous ssh attempts, I got the error:
ssh: connect to host 192.168.100.200 port 22: Connection refused

Check if openssh-server is installed and if not install it:

root@remote:~$ apt-get install openssh-server
Reading package lists... Done
Building dependency tree
Reading state information... Done
Suggested packages:
rssh molly-guard openssh-blacklist openssh-blacklist-extra
The following NEW packages will be installed:
openssh-server
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
........................................
Creating SSH2 RSA key; this may take some time ...
Creating SSH2 DSA key; this may take some time ...
ssh start/running, process 14458

Check that it is running:

root@remote:/home/user# ps -eaf|grep sshd
root 14458 1 0 14:15 ? 00:00:00 /usr/sbin/sshd -D
root 14612 9274 0 14:16 pts/0 00:00:00 grep --color=auto sshd
root@remote:/home/user# netstat -nav|grep :22
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN
tcp6 0 0 :::22 :::* LISTEN

Before debugging the ssh server on the remote machine, first check the permissions on the directories and files are as follows:

On local machine:

user@local:~$ sudo chmod 700 /home/user/.ssh/
drw-r--r-- 1 user user 411 2012-02-24 12:54 /home/user/.ssh/

user@local:~$ sudo chmod 600 /home/user/.ssh/id_rsa
-rw-r--r-- 1 user user 411 2012-02-24 12:54 /home/user/.ssh/id_rsa

user@local:~$ sudo chmod 644 /home/user/.ssh/id_rsa.pub
-rw-r--r-- 1 user user 411 2012-02-24 12:54 /home/user/.ssh/id_rsa.pub

user@local:~$ sudo chmod 644 /home/user/.ssh/known_hosts
-rw-r--r-- 1 user user 411 2012-02-24 12:54 /home/user/.ssh/known_hosts

On remote machine:

sshovas@remote:~$ sudo chmod 644 /home/sshovas/.ssh/authorized_keys
-rw-r--r-- 1 sshovas sshovas 411 2012-02-24 12:54 /home/sshovas/.ssh/authorized_keys

sshovas@remote:~$ sudo chmod 700 /home/sshovas/.ssh/
drwx------ 2 sshovas sshovas 4096 2012-02-24 12:54 /home/sshovas/.ssh/

Debug the ssh server:

sshovas@remote:~$ ssh -vvv localhost uptime
OpenSSH_5.5p1 Debian-4ubuntu6, OpenSSL 0.9.8o 01 Jun 2010
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to localhost [::1] port 22.
debug1: Connection established.
debug1: identity file /home/sshovas/.ssh/id_rsa type -1
debug1: identity file /home/sshovas/.ssh/id_rsa-cert type -1
debug1: identity file /home/sshovas/.ssh/id_dsa type -1
debug1: identity file /home/sshovas/.ssh/id_dsa-cert type -1
...............................................................
The authenticity of host 'localhost (::1)' can't be established.
RSA key fingerprint is XX:XX:XX:XX.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'localhost' (RSA) to the list of known hosts.
............................................................
debug1: Next authentication method: publickey
debug1: Trying private key: /home/sshovas/.ssh/id_rsa
debug3: no such identity: /home/sshovas/.ssh/id_rsa
debug1: Trying private key: /home/sshovas/.ssh/id_dsa
debug3: no such identity: /home/sshovas/.ssh/id_dsa
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
..................................
debug3: channel 0: close_fds r -1 w -1 e 6
Transferred: sent 1496, received 2056 bytes, in 1.2 seconds
Bytes per second: sent 1278.3, received 1756.7
debug1: Exit status 0

No private key is stored on the remote machine only on the local machine that you ssh from.

running sshd in debug mode on the destination server/remote machine:

sshovas@remote:~$ sudo /usr/sbin/sshd -p1234 -d
[sudo] password for sshovas:
debug1: sshd version OpenSSH_5.5p1 Debian-4ubuntu6
debug1: read PEM private key done: type RSA
debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
debug1: private host key: #0 type 1 RSA
debug1: read PEM private key done: type DSA
debug1: Checking blacklist file /usr/share/ssh/blacklist.DSA-1024
debug1: Checking blacklist file /etc/ssh/blacklist.DSA-1024
debug1: private host key: #1 type 2 DSA
debug1: rexec_argv[0]='/usr/sbin/sshd'
debug1: rexec_argv[1]='-p1234'
debug1: rexec_argv[2]='-d'
Set /proc/self/oom_adj from 0 to -17
debug1: Bind to port 1234 on 0.0.0.0.
Server listening on 0.0.0.0 port 1234.
debug1: Bind to port 1234 on ::.
Server listening on :: port 1234.

On local machine, Then attempt to connect to that specific port, no debugging options required:

user@local:~$ ssh -p1234 sshovas@192.168.100.200 uptime

Here if it a successful connection you will get prompted in a window to enter the private key password

Environment:
LANG=en_IE.UTF-8
USER=sshovas
LOGNAME=sshovas
HOME=/home/sshovas
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
MAIL=/var/mail/sshovas
SHELL=/bin/bash
SSH_CLIENT=192.168.20.150 59361 1234
SSH_CONNECTION=192.168.100.150 59361 192.168.20.200 1234
http_proxy=http:///
ftp_proxy=ftp:///
https_proxy=https:///
XDG_SESSION_COOKIE=
15:38:51 up 2 days, 23:46, 2 users, load average: 0.22, 0.16, 0.22

On the remote machine a successful ssh connection appears as:

debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
debug1: temporarily_use_uid: 1002/1002 (e=0/0)
debug1: trying public key file /home/sshovas/.ssh/authorized_keys
debug1: fd 4 clearing O_NONBLOCK
debug1: matching key found: file /home/sshovas/.ssh/authorized_keys, line 1
Found matching RSA key: X:X:X:X:X:X:X:X
debug1: restore_uid: 0/0
Postponed publickey for sshovas from 192.168.100.150 port 59504 ssh2

This is successful however, sladinstaller still gives the same error message on the local machine:

user@local:~$ sudo /usr/bin/sladinstaller

Installation was not successfull. Could not login via SSH. If you don't have a public key installed be sure to set the following options in the sshd_config file:
PermitRootLogin yes
PasswordAuthentication yes

The permissions were set as follows
http://www.noah.org/wiki/SSH_public_keys

chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_rsa
chmod 644 ~/.ssh/id_rsa.pub
chmod 644 ~/.ssh/authorized_keys
chmod 644 ~/.ssh/known_hosts

Changed the sshd_config file:
---------------------------------------------
sshovas@local:~$ sudo nano /etc/ssh/sshd_config
#AuthorizedKeysFile /home/sshovas/.ssh/authorized_keys

PermitRootLogin no
PasswordAuthentication no
-----------------------------------------------
Not sure how to resolve the SLAD installer issue after all this, any ideas?

It appears you are running SSH on port 1234, can the SLAD installer SSH into this port or does it default to port 22? If I am reading your output correctly, it looks like the SSH connection via key authentication is being established.

In answer to your other questions, yes the public key either gets renamed to authorized_keys or gets appended to the authorized keys file (on the remote system). The permissions for these files and directories should be such that only the owner can write to them, which looks ok.

Also, yes the keys should be id_rsa, not id_rsa_something else, unless you have configured your SSH client / server to look for these different files. The configuration would be in your /etc directory, by the way.

If you have gotten SSH via key authentication working, but Ovas is still claiming that it can't login you might want to ping the IRC channel or mailing list to see if anyone has a clue based upon experience with the tool. I sorry to admit that I am really starting to scratch dirt on this one.