Page 1 of 4 123 ... LastLast
Results 1 to 10 of 33

Thread: Trying public/private authentication on SSH

  1. #1

    Default Trying public/private authentication on SSH

    This would be actually continuation of discussion started here, but I thought I should put it into the right section.

    Now I'm trying ssh and scp but without need of typing the password each time, which means usage of public/private pair-keys (unless there are more ways...).
    I already started reading about this by looking into several websites, and I seem to have the general idea of how is done. But doubts arouse.

    First, some documents mentioned that, after adding the generated public key to the remote PC, one still needs to add the "identities" in the origin PC, i.e, loading private key to SSH agent with ssh-add. However other sites did not mention it, stating that the public key adding to remote PC was enough.
    I'm confused, is it necessary or not?

    Second, I read that in order for all of this to work sshd needed Protocol 2 and RSA Authentication enabled. In short,
    Code:
    Protocol 2
    RSAAuthentication yes
    AuthorizedKeysFile .ssh/authorized_keys
    Checked my /etc/ssh/sshd_config and the first 2 lines are commented (the file itself says it's strategy is to include many default settings, but left commented, I don't know why). Do I need to uncomment? Or would it work as it is by using dsa when creating the key?

    Thanks in advance.

  2. #2
    Join Date
    Jul 2008
    Location
    Seattle, WA
    Posts
    17,317

    Default Re: Trying public/private authentication on SSH

    On Tue, 26 Nov 2013 05:56:02 +0000, F style wrote:

    > Do I need to uncomment? Or would it work as it is by using dsa when
    > creating the key?


    The commented out parts are default settings, so no, you don't need to
    uncomment it. The only thing I've had to adjust in my config in the past
    is to remove password authentication (so I only use pubkey authentication
    on certain of my systems, especially if it's a system that is reachable
    from the 'net).

    Jim

    --
    Jim Henderson
    openSUSE Forums Administrator
    Forum Use Terms & Conditions at http://tinyurl.com/openSUSE-T-C

  3. #3

    Default Re: Trying public/private authentication on SSH

    On 11/25/2013 10:56 PM, F style wrote:
    >
    > First, some documents mentioned that, after adding the generated public
    > key to the remote PC, one still needs to add the "identities" in the
    > origin PC, i.e, loading private key to SSH agent with ssh-add. However
    > other sites did not mention it, stating that the public key adding to
    > remote PC was enough.
    > I'm confused, is it necessary or not?


    It really depends on the command that you use to transfer the files. The
    easiest way to do SSH/SCP/SFTP is to use the SSH agent, and since you're
    in an openSUSE forum I assume you're using openSUSE. The benefit here is
    that one you load your private key into the agent you'll never need to
    again which is awesome. The ssh-agent command does this, and win Gnome
    and KDE environments it is somehow handled magically so that any
    sub-processes (like shells) to the UI automatically inherit the agent's
    capabilities. The "agent" basically looks for SSH authentication requests
    for the keys and then handles those for you so that you can just enjoy
    file transfers securely and quickly without typing passphrases repeatedly.
    Your existing ssh/scp/sftp commands do not change at all when the agent
    is involved, and you can run scripts that include these commands, which
    may loop over many systems, and have it all work seamlessly as if you were
    accessing or copying to/from your own local system. The agent is great.

    The biggest hangup for most people with the ssh-agent command is how to
    use it initially. On any system (GUI or not) you'd do this, which loads
    ssh-agent and has it wrap /bin/bash (a new subshell from the current one
    from which these commands were typed) so that ssh-agent can watch for SSH
    requests from within this particular instance of /bin/bash (and nowhere else):

    Code:
    --------------------
    ssh-agent /bin/bash
    --------------------

    Now you'll see you're at a shell prompt as always, but this is the new
    /bin/bash subshell, so next we load the ssh key:

    Code:
    --------------------
    ssh-add
    --------------------

    Tada... unless you are not in an agent you should have seen some note
    about adding an identity to your system. From here you can go ahead and
    use keys, at least per the client side. If you have not already copied
    the public (never the private) key to the remote system, you can also use
    the ssh-copy-id command to do just that, and I'd recommend doing this
    because ssh-copy-id is better/safer/faster/more-reliable than copying the
    file manually and appending it to your authorized_keys file:

    Code:
    --------------------
    ssh-copy-id targetuser@remote.host.goes.here
    --------------------

    With that said, you can tell the existing ssh/scp/sftp commands to use a
    specific identity file without using the agent by using the '-i' option
    for each of those commands. For example:

    Code:
    --------------------
    ssh -i ~/.ssh/id_rsa user@remotesystem
    --------------------

    Even if the ~/.ssh/id_rsa key was not loaded into your SSH agent your ssh
    command would still try to use it.

    > Second, I read that in order for all of this to work sshd needed
    > Protocol 2 and RSA Authentication enabled. In short,
    >
    > Code:
    > --------------------
    > Protocol 2
    > RSAAuthentication yes
    > AuthorizedKeysFile .ssh/authorized_keys
    > --------------------
    >
    > Checked my /etc/ssh/sshd_config and the first 2 lines are commented (the
    > file itself says it's strategy is to include many default settings, but
    > left commented, I don't know why). Do I need to uncomment? Or would it
    > work as it is by using dsa when creating the key?


    As Jim stated, and as the sshd_config file itself states:

    Code:
    --------------------
    # The strategy used for options in the default sshd_config shipped with
    # OpenSSH is to specify options with their default value where
    # possible, but leave them commented. Uncommented options override the
    # default value.
    --------------------

    Whenever I modify sshd_config defaults I duplicate the line that is
    already commented (so that I have a note about how the original looked)
    and then modify the new line after uncommenting it. This is not required
    of course, but I like it.

    --
    Good luck.

    If you find this post helpful and are logged into the web interface,
    show your appreciation and click on the star below...

  4. #4

    Default Re: Trying public/private authentication on SSH

    Then I understand the whole public/private key making stuff is basically to enhance security, by skipping the simple user-password scheme and using a double security one, composed by a file (the key) and a password (passphrase). Am I right?
    If I am, then I assume I'd normally both create key and set a passphrase, and use ssh agent precisely to avoid typing passphrase each time. Right?

    But if I were to, for example, create an automated cron task which executed at a fixed hour, I read an option for this case was leaving blank the passphrase (even though it'd skip a level of security, but I don't know...), rendering usage of ssh agent needless.

    Have I understood well? What do you say?

  5. #5

    Default Re: Trying public/private authentication on SSH

    On 11/26/2013 09:56 AM, F style wrote:
    >
    > Then I understand the whole public/private key making stuff is basically
    > to enhance security, by skipping the simple user-password scheme and
    > using a double security one, composed by a file (the key) and a password
    > (passphrase). Am I right?


    Yes, you're basically swapping out "something you know" (password) with
    "something you have" (key file), and then protecting the second something
    with a new something (passphrase) to prevent/slow access by evil types,
    should they steal your key file somehow. Passwords are additionally
    vulnerable because they are guessable and predictable by person (you like
    dogs? Okay, I'll try dog-related passwords instead of the cat ones).
    Keys are basically not vulnerable to brute force attacks.

    Even more, you can limit function based on key, so you can do things like
    set "If somebody logs in with this key they can only run this command, and
    I'm disabling X-forwarding, etc." That gets kinda fun.

    In case it is not obvious, it's trivial to login as another user on a
    remote system using keys which is one of the big uses for keys. Sure you
    can do the same with passwords, but you need to know every target user's
    password. With keys you can just send your key to that user's
    authorized_keys file and you can get in as them directly.

    > If I am, then I assume I'd normally both create key and set a
    > passphrase, and use ssh agent precisely to avoid typing passphrase each
    > time. Right?


    Right. Once you enter the passphrase the first time for ssh-agent to read
    the private key you no longer need to do so until you restart the agent
    (logout/login, reboot, etc.).

    > But if I were to, for example, create an automated cron task which
    > executed at a fixed hour, I read an option for this case was leaving
    > blank the passphrase (even though it'd skip a level of security, but I
    > don't know...), rendering usage of ssh agent needless.


    Exactly on both points. You should always protect your private key file
    as it is was your actual password (because, in function, it is) but if you
    have a passphrase-less private key protect it even more since nothing will
    stop somebody else from taking it and using it if they can copy it from
    you somehow. Should that happen fixing the problem is easy (delete the
    appropriate line from the target system's user's authorized_keys file) but
    you may want to implement additional security on the server side here too.
    I have some scripts where I do this to just keep some SSH tunnels alive
    indefinitely. Since they provide access to my system anybody who runs
    these scripts (some customers) could get into my system. They're non-root
    users, but still, that's one more barrier. As a result I setup my server
    to ONLY allow those keys to be used to run a shell script I created that
    just prints the date every minute or so. If they try anything else, it
    still just runs that script. If they try to enable other functions those
    fail silently. If that key is ever compromised the attacker can connect
    to my system as that non-root user and just see the time presented once
    per minute forever. That's fine with me.

    > Have I understood well? What do you say?


    Yes.

    --
    Good luck.

    If you find this post helpful and are logged into the web interface,
    show your appreciation and click on the star below...

  6. #6

    Default Re: Trying public/private authentication on SSH

    Oh...

    So in the end, what would be your advise for automated cron tasks/scripts? For now I'm just aiming to make backups periodically.

  7. #7

    Default Re: Trying public/private authentication on SSH

    Now that I thought about it, I came with more issues...

    First, regarding ssh-copy-id, if I don't use -i option at all, it will add to remote PC the one or more keys stored in ssh-agent, and if ssh-agent has no stored keys, it will just add the default ~/.ssh/id_rsa.pub. Am I right?

    Second, how are keys working at all?
    Let's imagine I create default ~/.ssh/id_rsa.pub in local PC with my local user (let's call it user1). It's fingerprint, as I have seen, will end with this user name. Then I add this key with ssh-copy-id to remote PC, where user2 is currently logged in. From what I read, I can only guess I've created a key that "links" just both user1 and user2. So if I want to log in remote PC using the key (i.e., without typing password), I must be as user1 on local PC and log in as user2 on remote PC.
    Am I right?
    But then what are both public and private key files for on local PC? What effect does it make by deleting or moving them to another directory?

    I know ssh-keygen generates keys with different fingerprints (.pub file's content) each time, even if they're named the same way. Let's say I first made default ~/.ssh/id_rsa.pub, then I made another one ~/Documents/id_rsa.pub (if I used same save directory it'd be indeed overwritten). Different fingerprints, though they end with the same user name they were created from. What happens if I try to add both to remote PC? How would I log in?

    Guess I'm indeed very confused...

  8. #8
    Join Date
    Jun 2008
    Location
    Podunk
    Posts
    32,339
    Blog Entries
    15

    Default Re: Trying public/private authentication on SSH

    On Wed 27 Nov 2013 04:36:01 AM CST, F style wrote:


    Now that I thought about it, I came with more issues...

    First, regarding ssh-copy-id, if I don't use -i option at all, it will
    add to remote PC the one or more keys stored in ssh-agent, and if
    ssh-agent has no stored keys, it will just add the default
    ~/.ssh/id_rsa.pub. Am I right?

    Second, how are keys working at all?
    Let's imagine I create default ~/.ssh/id_rsa.pub in local PC with my
    local user (let's call it user1). It's fingerprint, as I have seen, will
    end with this user name. Then I add this key with ssh-copy-id to remote
    PC, where user2 is currently logged in. From what I read, I can only
    guess I've created a key that "links" just both user1 and user2. So if I
    want to log in remote PC using the key (i.e., without typing password),
    I must be as user1 on local PC and log in as user2 on remote PC.
    Am I right?
    But then what are both public and private key files for on local PC?
    What effect does it make by deleting or moving them to another
    directory?

    I know ssh-keygen generates keys with different fingerprints (.pub
    file's content) each time, even if they're named the same way. Let's say
    I first made default ~/.ssh/id_rsa.pub, then I made another one
    ~/Documents/id_rsa.pub (if I used same save directory it'd be indeed
    overwritten). Different fingerprints, though they end with the same user
    name they were created from. What happens if I try to add both to remote
    PC? How would I log in?

    Guess I'm indeed very confused...


    Hi
    You think too much..... try it, what happens....?

    All I do on my local network is create a key, ssh onto the remote
    system and add (via copy/paste) to ~/.ssh/authorized_keys file for
    that user, if you had another user on the remote machine, copy the same
    key into that users ~/.ssh/authorized keys file.

    So from the local machine I could then open a terminal;
    Code:
    ssh user1@remotesystem and be in ~/user1
    open another local machine terminal and;
    Code:
    ssh user2@remotesystem and be in ~/user2
    I change my sshd config files to use authorized_keys2 since that's what
    no-machine looks for.

    --
    Cheers Malcolm °¿° SUSE Knowledge Partner (Linux Counter #276890)
    SLED 11 SP3 (x86_64) GNOME 2.28.0 Kernel 3.0.101-0.8-default
    If you find this post helpful and are logged into the web interface,
    please show your appreciation and click on the star below... Thanks!


  9. #9
    Join Date
    Aug 2010
    Location
    Chicago suburbs
    Posts
    15,681
    Blog Entries
    3

    Default Re: Trying public/private authentication on SSH

    Quote Originally Posted by F_style View Post
    But if I were to, for example, create an automated cron task which executed at a fixed hour, I read an option for this case was leaving blank the passphrase (even though it'd skip a level of security, but I don't know...), rendering usage of ssh agent needless.
    Yes, that's about right.

    When I was doing that (while administering a department network of computers), I used host-based authentication. In that case the host key, rather than a personal key, is used. And you would login at the remote site as the same user you are.

    It's probably explained in the same documentation you have been reading.
    openSUSE Leap 15.3; KDE Plasma 5.18.6;

  10. #10

    Default Re: Trying public/private authentication on SSH

    On 11/26/2013 09:36 PM, F style wrote:
    >
    > First, regarding ssh-copy-id, if I don't use -i option at all, it will
    > add to remote PC the one or more keys stored in ssh-agent, and if
    > ssh-agent has no stored keys, it will just add the default
    > ~/.ssh/id_rsa.pub. Am I right?


    Mostly. I am not sure (because it has never worked for me) that
    ssh-copy-id will grab any keys that are not loaded into the agent.
    Perhaps newer versions do, but older versions did not. I only have one
    key, so it has only ever copied one key for me. I know that with openSUSE
    13 (and SUSE Linux Enterprise Server 11 SP3) the SSH versions have been
    moved up to 6.1 which has a smarter ssh-copy-id function so perhaps that's
    an option now.

    > Second, how are keys working at all?
    > Let's imagine I create default ~/.ssh/id_rsa.pub in local PC with my
    > local user (let's call it user1). It's fingerprint, as I have seen, will
    > end with this user name. Then I add this key with ssh-copy-id to remote
    > PC, where user2 is currently logged in. From what I read, I can only
    > guess I've created a key that "links" just both user1 and user2. So if I
    > want to log in remote PC using the key (i.e., without typing password),
    > I must be as user1 on local PC and log in as user2 on remote PC.
    > Am I right?
    > But then what are both public and private key files for on local PC?
    > What effect does it make by deleting or moving them to another
    > directory?


    For the purposes of making this clear think about passwords. In a typical
    *nix system you an /etc/shadow (or maybe /etc/passwd if you're a little
    odd) file that contains something that is linked to your password. That
    "something" is a hash, and is the result of a one-way function like crypt,
    blowfish, md5, sha-something, etc. This matters because when you login
    with a password you do not send the hashed version of your password, but
    instead you type the real password and then the system takes it (and
    probably a salt that the system has stored for your user) and generates a
    hash using the same function, and then compares that hash with the stored
    hash for your user (the user you claimed to be when authenticating). If
    it matches, you're in. If not, you're not. If you have that hash stored
    in other files on the server, it does not matter since /etc/shadow is the
    file checked. If you have the same password for other users it does not
    matter since you specified a specific username for logging in.

    When you use SSH keys the same happens, except that instead of each user
    controlling their own password on the server using the 'passwd' command
    they control access to their account by modifying their own
    ~/.ssh/authorized_keys file (or whatever file sshd is configured to use).
    They do this by copying the public key of anybody else into this file.
    When a client attempts to authenticate that client sends the username (of
    course) and then THAT USER's, and no other's, authorized_keys file is
    checked. If the private key used on the client side matches the public
    key on the server side, they're in. If not, they're not. The username
    bit as the third parameter in the public key file does not, as far as I
    can tell, matter at all and is probably merely so the server side user can
    easily see who has access.

    > I know ssh-keygen generates keys with different fingerprints (.pub
    > file's content) each time, even if they're named the same way. Let's say
    > I first made default ~/.ssh/id_rsa.pub, then I made another one
    > ~/Documents/id_rsa.pub (if I used same save directory it'd be indeed
    > overwritten). Different fingerprints, though they end with the same user
    > name they were created from. What happens if I try to add both to remote
    > PC? How would I log in?


    See above and hopefully that explains everything.

    --
    Good luck.

    If you find this post helpful and are logged into the web interface,
    show your appreciation and click on the star below...

Page 1 of 4 123 ... LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •