[SOLVED] Problems using SSH with foreign server

sea · #1 13th April 2012, 03:37 PM

Heyas

Foreign server in this case means, that its not 'inhouse' and that i have no physical access to it.
However, i had sent the Company my public key file, and they reportet that i should be able to login now.

i'm new to the whole SSH thing, so i have read some threads about it:

After successfully creating the default "id_rsa" file, i've done like suggested:

Code:

cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys

But when i try to connect, i get something like this (masked):

Code:

ssh -v simon@SERVER_URL
OpenSSH_5.8p2, OpenSSL 1.0.0h-fips 12 Mar 2012
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to SERVER_URL [SERVER_IP] port 22.
debug1: Connection established.
debug1: identity file /home/simon/.ssh/id_rsa type 1
debug1: identity file /home/simon/.ssh/id_rsa-cert type -1
debug1: identity file /home/simon/.ssh/id_dsa type -1
debug1: identity file /home/simon/.ssh/id_dsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.4p1 FreeBSD-20100308
debug1: match: OpenSSH_5.4p1 FreeBSD-20100308 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.8
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr 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: Server host key: RSA xx:xx:xx:xx:xx.....
debug1: Host 'SERVER_URL' is known and matches the RSA host key.
debug1: Found key in /home/simon/.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: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/simon/.ssh/id_rsa
debug1: Authentications that can continue: publickey,keyboard-interactive
debug1: Trying private key: /home/simon/.ssh/id_dsa
debug1: Next authentication method: keyboard-interactive
Password:
LDAP Password:
debug1: Authentications that can continue: publickey,keyboard-interactive
debug1: No more authentication methods to try.
Permission denied (publickey,keyboard-interactive).

And just where i 'would' need to enter the password i get stuck.
Regardless if i enter the password or not, it just repeats the question for it...

Any help, on what i'm missing, or where i should read more about is very welcome.

Thank you and have a nice weekend

Greets
sea

In the process of 'learning' ssh, this script was created, just replace sP by printf and sE by echo.
You may use this script and modify, as long you leave the comments untouched (or only add more comments):

Code:

    sshkeygen() { # [PASSWORD] [FILE]
    # Generates a ssh keyfile with the provided PASSWORD, if its empty, no password is set.
    # If you provide a FILE, you MUST provide the PASSWORD too, if no FILE is provided, a filename will be generated from your settings.
    # ssh-keygen handler written April 2012 by Simon A. Erat
        cstrength="768 1024 2048 4096 8192"
        cKind="dsa rsa"
        p=$HOME/.ssh
        sE "Select what kind of encryption you want:"
        select cKind in $cKind;do
            case $cKind in
                dsa)    cBit=1024   
                        break ;;
                rsa)    sE "Select encryption strength:"
                        select cBit in $cstrength;do break;done
                        break ;;
            esac
        done
        
        test "" = "$2" &&       sshFile="id-$cKind-$(whoami)_$cBit" && \
            sE "Using default file name: id-$cKind-$(whoami)_$cBit" && \
            sshFile="$HOME/.ssh/$sshFile" || \
            sshFile="$HOME/.ssh/$2"

        test "" = "$1" && ssh-keygen -t $cKind -b $cBit -f $sshFile ||\
            ssh-keygen -t $cKind -b $cBit -f $sshFile -N "$1"
        cat $sshFile.pub >> $p/authorized_keys
    }

lpshark · #2 13th April 2012, 05:57 PM

is your public key on the "foreign" servers contained within the ~/.ssh/authorized_keys file?

permissions on ~/.ssh/authorized_keys file should be 600.

permissions on the ~/.ssh/ directory should be 700.

pete_1967 · #3 13th April 2012, 06:38 PM

To start with: Never add your private key to anything on your machine or server. authorized_keys are public keys that are allowed to connect on your server, it has nothing what so ever to do with connecting to a remote machine.

Most common error is that permissions for .ssh and files in it are too lax as lpshark points out, that leads to the rejection of your private key. Make sure that they are set to what he says first.

If you still can't connect to that server, then your public key hasn't been installed correctly on the remote server, or it's not correct one. The password and LDAP authentications are fallbacks offered by the server and if the company provided your either, then you need to use those.

What comes to your scrip, just couple notest:
"change the computers name" is nonsensical, the "coputer's name" is added as a default comment to make it easier to ID the keys, but you can add anything you want to.
DSA keys must always be 1024 bits.
You are not offering option to name the keys, thus they always overwrite existing keys, also you may not want to place them in .ssh directory at all if you are generating them for installation to another machine for example.

And last: You are dumping you private key to authorized_keys!!!

sea · #4 14th April 2012, 01:09 AM

Thanks, thats a typo (wrote it after true execution and forgot to add the .pub).

The DSA is set to 1024 bits in the select-case statement.
As written in the comments of the first 3 lines:

Quote:

sshkeygen() { # [PASSWORD] [FILE]
# Generates a ssh keyfile with the provided PASSWORD, if its empty, no password is set.
# If you provide a FILE, you MUST provide the PASSWORD too, if no FILE is provided, a filename will be generated from your settings.

Thanks for the file permission hint, looking into that now.

EDIT:
Not sure if the permissions were properly set before, i've just set them to
chmod 700 $HOME/.ssh
chmod 600 $HOME/.ssh/authorized_keys

However, me idiot used wrong login name

Either way, thank you guys, i have learned something more.

/solved

stevea · #5 14th April 2012, 02:35 AM

Quote:

Originally Posted by pete_1967

To start with: Never add your private key to anything on your machine or server. authorized_keys are public keys that are allowed to connect on your server, it has nothing what so ever to do with connecting to a remote machine.

.....

And last: You are dumping you private key to authorized_keys!!!

No offense, but I know the issue but found that description very confusing in a "who's on first" sense.
"your machine", "server", "your server" and "remote machine" are ill defined.

An "ssh client system" with a (properly placed and permissioned) private key can allow a user to login to an "sshd server machine" with a (properly placed and permissioned) corresponding public key. For example the client machine can have the private key in the ~/.ssh/id_rsa, while the server machine has the corresponding public key in ~/.ssh/authorized_keys.

So assuming the user manages his private key correctly, then it's safe publish the public key. Installing the public key on other system's authorized_keys file just gives you the ability to authenticate on those other systems.

====

The above refers to user keys, there is also the matter of host keys for ssh.