LinuxQuestions.org
Welcome to the most active Linux Forum on the web.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Server
User Name
Password
Linux - Server This forum is for the discussion of Linux Software used in a server related context.

Notices



Reply
 
Search this Thread
Old 05-28-2009, 07:58 AM   #1
t0ken407
LQ Newbie
 
Registered: May 2009
Location: Orlando, FL
Distribution: Mandriva, Fedora, CentOS
Posts: 4

Rep: Reputation: 0
Can't use private key for ssh [SOLVED]


I just started working at a NOC and we have a private key for ssh that we use on all our servers. All the techs are able to ssh as root to all the servers using this private key.

I'm the only tech using Mandriva, and I'm also the only tech who is unable to ssh to a machine without being asked for a password.

What I did was:
Code:
ssh-add [path to key file]
When I did that, the message returned was:
Code:
Identity added: [key file]
Now, in theory, I should be able to ssh to any machine without being asked for a password. However, this is what I get when I try to ssh to a machine:
Code:
The authenticity of host '[x.x.x.x]:port ([x.x.x.x]:port)' can't be established.
RSA key fingerprint is xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx.
Are you sure you want to continue connecting (yes/no)?
What am I missing?
Here are the options in my /etc/ssh/ssh_config file:
Code:
Host *
    ForwardX11 yes
    Protocol 2,1

    # If this option is set to yes then remote X11 clients will have full access
    # to the original X11 display. As virtually no X11 client supports the untrusted
    # mode correctly we set this to yes.
    ForwardX11Trusted yes

    # Send locale-related environment variables
    #SendEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
    #SendEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
    #SendEnv LC_IDENTIFICATION LC_ALL
    GSSAPIAuthentication yes

Last edited by t0ken407; 05-29-2009 at 09:49 AM. Reason: solved
 
Old 05-28-2009, 09:17 AM   #2
sutrannu
LQ Newbie
 
Registered: Nov 2007
Location: USA, Midwest
Distribution: ubuntu
Posts: 13

Rep: Reputation: 1
The RSA key fingerprint is the unique identifier for the server you are connecting to. If you answer "yes" to the question you are being asked, the fingerprint will be added to your .ssh/known_hosts file and you will not be asked again.

This action, in effect, is you confirming that the server you are connecting to is valid, and not being spoofed. You will have to confirm every server once, and only once.

In the event that the key for the server is changed (for example; when the OS is reinstalled, or a new key must be made fr security reasons.) everyone would have to re-validate the server key.

If you are already sharing a single root key, you could share the known_hosts file as well. a copy from any of your teammates should validate all the servers. This, of course, has security issues that should be handled responsibly. Use at your own risk.
 
Old 05-28-2009, 09:32 AM   #3
t0ken407
LQ Newbie
 
Registered: May 2009
Location: Orlando, FL
Distribution: Mandriva, Fedora, CentOS
Posts: 4

Original Poster
Rep: Reputation: 0
Quote:
Originally Posted by sutrannu View Post
The RSA key fingerprint is the unique identifier for the server you are connecting to. If you answer "yes" to the question you are being asked, the fingerprint will be added to your .ssh/known_hosts file and you will not be asked again.

This action, in effect, is you confirming that the server you are connecting to is valid, and not being spoofed. You will have to confirm every server once, and only once.

In the event that the key for the server is changed (for example; when the OS is reinstalled, or a new key must be made fr security reasons.) everyone would have to re-validate the server key.

If you are already sharing a single root key, you could share the known_hosts file as well. a copy from any of your teammates should validate all the servers. This, of course, has security issues that should be handled responsibly. Use at your own risk.
Thank you for your response! I thought of copying someones known_hosts file but I just never did it. I'll try that and let you know what happens.

(Just FYI, if I type "yes" to the question, it'll ask me for a password).
 
Old 05-28-2009, 10:28 AM   #4
t0ken407
LQ Newbie
 
Registered: May 2009
Location: Orlando, FL
Distribution: Mandriva, Fedora, CentOS
Posts: 4

Original Poster
Rep: Reputation: 0
Ok, this worked, but only for certain machines. Others are still asking for a password, and I think it correlates to machines that the person visited who's known_hosts file I copied.

This would kinda lead me to believe that my pub key is required on the remote server, but my co-workers say they didn't have to do anything other than run the ssh-add command (others are using Fedora, I'm on Mandriva).
 
Old 05-28-2009, 12:36 PM   #5
anomie
Senior Member
 
Registered: Nov 2004
Location: Texas
Distribution: RHEL, Scientific Linux, Debian, Fedora, Lubuntu, FreeBSD
Posts: 3,930
Blog Entries: 5

Rep: Reputation: Disabled
According the manpages for ssh-add(1) (which I do not use), it adds identities to ssh-agent(1).

So, are you running ssh-agent?
 
Old 05-28-2009, 12:58 PM   #6
chitambira
Member
 
Registered: Oct 2008
Location: Fife
Distribution: RHEL, Centos
Posts: 373
Blog Entries: 1

Rep: Reputation: 49
Quote:
This would kinda lead me to believe that my pub key is required on the remote server, but my co-workers say they didn't have to do anything other than run the ssh-add command (others are using Fedora, I'm on Mandriva).
I understand that when u started work, you were give a privatekey only right? The puplic key is already loaded on all the servers, and its not "yours" so there's no pub key required from you.
What differs here might only be the ssh-agent that you are running, but first make sure the ssh-agent is running (it starts automatically in Fedora)

Look for the following line in /etc/X11/xdm/sys.xsession (or whatever for mandriva)
Quote:
# If ssh is configured and ssh-agent is wanted set "yes"
usessh=yes

Last edited by chitambira; 05-28-2009 at 01:08 PM.
 
Old 05-28-2009, 10:00 PM   #7
chrism01
Guru
 
Registered: Aug 2004
Location: Sydney
Distribution: Centos 6.6, Centos 5.10
Posts: 16,324

Rep: Reputation: 2041Reputation: 2041Reputation: 2041Reputation: 2041Reputation: 2041Reputation: 2041Reputation: 2041Reputation: 2041Reputation: 2041Reputation: 2041Reputation: 2041
The first time a cxn is established between any pair of systems (each direction is separately treated), you will be prompted, once only, to confirm you want the key to be accepted.
iirc, the target has the private key, the src/clients have the public key, hence the name.
 
Old 05-29-2009, 09:48 AM   #8
t0ken407
LQ Newbie
 
Registered: May 2009
Location: Orlando, FL
Distribution: Mandriva, Fedora, CentOS
Posts: 4

Original Poster
Rep: Reputation: 0
Hey guys, I got this working. There appeared to be a mistep or miscommunication with my trainers. Its true that my public key needed to be in the authorized_keys file on the servers. We have public and private keys that are the same on all the servers, so I actually needed to install a public key on my machine, then add the private key via ssh-add. After doing this, I'm able to connect as expected.

I'm wondering, though, whether Mandriva just handles this differently than other systems (namely, Fedora), or my co-workers just plain forgot that they had installed the public key.

Thanks for the help! and thanks for having patience with my ignorance! lol

Last edited by t0ken407; 05-29-2009 at 09:50 AM.
 
Old 05-31-2009, 01:36 PM   #9
sutrannu
LQ Newbie
 
Registered: Nov 2007
Location: USA, Midwest
Distribution: ubuntu
Posts: 13

Rep: Reputation: 1
To the best of my knowledge, ssh is a standard. I've used open-ssh, putty, dropbear, and probably other implementations of ssh. I've found that these functions work the same for all of them.

To make it more clear; The public/private key pair is used to authenticate you. You keep the key (the private key), and the server gets the padlock (the public key stored in the authorized_keys file on the server.) The fingerprint (stored in your known_hosts file) authenticates the server. It ensures that you are authenticating with the same server each time you connect.

In your procedure, I'm not sure if they give you a copy of the key, or give you your own key and add your padlock to the door. The later is more secure, because removing an individual's padlock easily denies access to that single individual.
 
Old 05-31-2009, 03:50 PM   #10
jschiwal
Guru
 
Registered: Aug 2001
Location: Fargo, ND
Distribution: SuSE AMD64
Posts: 15,733

Rep: Reputation: 655Reputation: 655Reputation: 655Reputation: 655Reputation: 655Reputation: 655
Having shared private keys is not a good idea IMHO. In other words, they are not private. The wider you distribute a secret, the more likely it will become lost or stolen. If that happens, and you are lucky that no one breaks into your servers, you will need to change all of the private keys. Something like this happened (in the real world) using real keys at my previous apartment. The janitor lost the pass key They were lazy and used the same pass key for all of their apartment buildings. They had to change the locks for every apartment in all of their buildings. It cost $60K to do this.

The private key belongs to the client. You can use one key pair to connect to any server that has your pubkey in authorized_keys. You distribute the public key to the servers, but the private key belongs to the client.

The ssh-agent allows you to only have to enter the passphrase once in a shell session. Look in your .xsession file. It might be the /etc/X11/xdm/sys.xsession on some distro's. Look for a "usessh=no" line and change it to "usessh=yes".

This is the code from openSUSE in sys.xsession that runs ssh-agent when you log in. I tried using .profile before and found that it would be run twice.
Code:
#
# Run ssh-agent only if ssh service is configured and avaliable.
# Check if there is already a running ssh-agent and if use this.
#
if test "$usessh" = yes -a -d "$HOME/.ssh" && sshagent=$(type -p ssh-agent) ; then
    if test -S "$SSH_AUTH_SOCK" ; then
        if test -n "$SSH_AGENT_PID" && checkproc -p $SSH_AGENT_PID $sshagent ; then
            export SSH_AGENT_PID SSH_AUTH_SOCK
        else
            rm -f "$SSH_AUTH_SOCK"
            case "${SSH_AUTH_SOCK%/*}" in
            /tmp/*) rm -rf "${SSH_AUTH_SOCK%/*}"
            esac
            unset SSH_AUTH_SOCK
        fi
    else
        unset SSH_AUTH_SOCK
    fi

    if test -z "$SSH_AUTH_SOCK" ; then
        set -- $sshagent ${1+"$@"}
    fi

    if test -x /usr/lib/ssh/x11-ssh-askpass ; then
        SSH_ASKPASS=/usr/lib/ssh/x11-ssh-askpass
        export SSH_ASKPASS
    elif test -x /usr/lib64/ssh/x11-ssh-askpass ; then
        SSH_ASKPASS=/usr/lib64/ssh/x11-ssh-askpass
        export SSH_ASKPASS
    fi
fi
You can do this manually later:
eval $(ssh-agent)
ssh-add
<enter passphrase>

This will work just for this terminal however, but you can log in & out now to any server without ssh prompting for your passphrase.
The passphrase is unlocking your private key on the client side. The server has nothing to do with it.

If the private key you are using isn't protected with a pass phrase, you can change the passphrase with ssh-keygen. The protection provided is that your laptop, or private key file is stolen, they will need the passphrase to use it. Otherwise they would have access to the servers.

You also said that the keys were for root logins. That is another bad idea. Sometimes it is necessary for automated cron backups, but otherwise, logins should be done as a regular user before su'ing to root, or using sudo. Imagine that an admin logs in using putty on windows. I don't know if Putty on windows checks the read permissions of the private key, and the permissions of the home and .ssh directory the way it is done in Linux. If someone gains access to there computer and can grab the key, because the user is "root", you won't know who lost their key, and there is no barrier to gaining root access to the server. Hopefully, the user has their key passphrase protected.

As far as I can tell, a weakness in pubkey authentication using ssh is that you can't enforce that users use strong passphrases. Even if you distribute private keys to each user, they can use keygen to remove the passphrases.

Last edited by jschiwal; 05-31-2009 at 03:53 PM.
 
  


Reply

Tags
mandriva, openssh, rsa, ssh


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
ssh randomly not accepting my private key reeseslover531 Linux - Server 6 06-06-2010 07:40 PM
SSH Public/Private Key Fail. Help Please! hawk__0 Linux - Networking 9 11-07-2008 04:36 PM
ssh private key question vonedaddy Linux - Security 4 01-14-2008 11:41 AM
need help with SSH private/public key taduser Linux - Security 2 04-02-2007 08:07 PM
SSH: Help needed adding private key thomsky Linux - Security 3 10-21-2006 06:04 PM


All times are GMT -5. The time now is 02:37 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration