ssh is hard to use - SSH

This is a discussion on ssh is hard to use - SSH ; Hi Folks, I'm using openSSH 4.0p1 (0.9.7f) on Fedora Core 4, and I just had a very frustrating experience the last few days trying to get public key authentication to work. The situation was this: I have two systems on ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: ssh is hard to use

  1. ssh is hard to use

    Hi Folks,

    I'm using openSSH 4.0p1 (0.9.7f) on Fedora Core 4, and I just had a
    very frustrating experience the last few days trying to get public key
    authentication to work.

    The situation was this: I have two systems on a private network here
    at the house behind a firewall. Neither have domain names but rather
    are addressed by numeric IP address, which is dynamically assigned by
    the Linksys router/firewall. My goal was to be able to scp from one
    system to the other from a script without having to manually intervene
    to type passwords.

    My experience was that, no matter what I tried, I could not get a
    passphrase prompt when ssh'ing in (without ssh-agent). Here are some
    of the things I tried and/or questions I asked myself, most of which I
    had seen in one of the numerous FAQs/tutorials on the subject:

    1. Am I using protocol 1 or protocol 2? How do I know if the
    software version [1] supports protocol 2?

    Ans: I still don't know the answer to this one.

    2. How do I know for sure protocol 2 is enabled?

    Ans: via the "Protocol" option in sshd_config.

    3. How do I know protocol 2 is being used and not protocol 1?

    Ans: By specifying "Protocol 2" and not "Protocol 2,1" in sshd_conf.

    4. Should I use rsa or dsa keys (ssh-keygen -t rsa or ssh-keygen -t
    dsa)?

    Ans: Don't know.

    5. Where should I put my private key? src:.~/.ssh, or src:~/.ssh2
    [2]?

    Ans: ~/.ssh. Apparently the old .ssh2 stuff was done away with at
    some point in the protocol 2 development history.

    6. Where should I put my authorized key file, dst:~/.ssh or dst:~/.ssh2?

    Ans: ~/.ssh

    7. What should I name my authorized key file, authorized_keys or
    authorized_keys2?

    Ans: authorized_keys

    8. Do the host keys need to be generated and active (in /etc/...)
    as well as the user keys (i.e., in ~/.ssh/...)?

    Ans: No, only the user key in the user's home directory.

    9. When the src host is attempting to connect to the dst host, how
    does the dst host know which key in the authorized_keys file to mate
    with the src host?

    Ans: Don't know

    10. What exactly is host-based authentication versus public key
    authentication?

    Ans: This is a very unfortunate nomenclature. Both use
    public/private key pairs. The simple answer is that host-based
    authenticatation authenticates using one key (that in /etc/ssh/...)
    no matter which src user account is being used. Public key
    authentication keys are src user-dependent (from the user's ~/.ssh
    directory).

    11. When specifying sshd options, which host should they be
    changed in, src or dst or both?

    Ans: dst. The reason this question lingered in my mind is
    that I had no idea how the ssh and sshd clients and servers
    interact on the src and dst machines, and was thinking it
    might be possible that the src server interacts with the
    dst server.

    12. Exactly what permissions are required in order for
    public key authentication to work? Are they permissions
    on the src, or permissions on the dst, or both?

    Ans: Not sure of this one, but setting StrictModes to
    no makes the question moot.

    13. Does public key authentication require valid reverse DNS
    lookups?

    Ans: No. However, I'm not sure the same is true for host-based
    authentication.

    Note that, after about 4 days of fiddling around with the damn thing,
    it was number 12 that caused my connections to start working.

    This is UNACCEPTABLE, and all of these questions should have
    been *clearly* answered in a user manual/FAQ. They were not.

    If the openSSH community wants this development to thrive, these
    shortcomings in the documention should be repaired.

    --Randy Yates



    [1] Note that I distinguish between protocol version (1 or 2)
    and software version (e.g., the specific openSSH software
    version).

    [2] I use the syntax "src" to refer to the source host (i.e.,
    the host being connected from) and "dst" to designate the
    destination host (i.e., the host being connected to).
    --
    % Randy Yates % "Watching all the days go by...
    %% Fuquay-Varina, NC % Who are you and who am I?"
    %%% 919-577-9882 % 'Mission (A World Record)',
    %%%% % *A New World Record*, ELO
    http://home.earthlink.net/~yatescr

  2. Re: ssh is hard to use

    Randy Yates wrote:
    > Hi Folks,
    >
    > I'm using openSSH 4.0p1 (0.9.7f) on Fedora Core 4, and I just had a
    > very frustrating experience the last few days trying to get public key
    > authentication to work.
    >
    > The situation was this: I have two systems on a private network here
    > at the house behind a firewall. Neither have domain names but rather
    > are addressed by numeric IP address, which is dynamically assigned by
    > the Linksys router/firewall. My goal was to be able to scp from one
    > system to the other from a script without having to manually intervene
    > to type passwords.
    >
    > My experience was that, no matter what I tried, I could not get a
    > passphrase prompt when ssh'ing in (without ssh-agent). Here are some
    > of the things I tried and/or questions I asked myself, most of which I
    > had seen in one of the numerous FAQs/tutorials on the subject:
    >
    > 1. Am I using protocol 1 or protocol 2? How do I know if the
    > software version [1] supports protocol 2?
    >
    > Ans: I still don't know the answer to this one.


    Read the manual page for ssh, sshd, sshd_config, or ssh_config. All of them
    list both protocol 1 and protocol 2. Protocol 2 is used by default. You can
    use "ssh -v -v -v targethost" to tell you way, way, way too much detail
    about the connection being made.

    > 2. How do I know for sure protocol 2 is enabled?
    >
    > Ans: via the "Protocol" option in sshd_config.


    >
    > 3. How do I know protocol 2 is being used and not protocol 1?
    >
    > Ans: By specifying "Protocol 2" and not "Protocol 2,1" in sshd_conf.


    It does protocol 2 and 1 in the listed order.

    > 4. Should I use rsa or dsa keys (ssh-keygen -t rsa or ssh-keygen -t
    > dsa)?
    >
    > Ans: Don't know.


    DSA is for protocol 2. Use that.

    > 5. Where should I put my private key? src:.~/.ssh, or src:~/.ssh2
    > [2]?
    >
    > Ans: ~/.ssh. Apparently the old .ssh2 stuff was done away with at
    > some point in the protocol 2 development history.



    > 6. Where should I put my authorized key file, dst:~/.ssh or
    > dst:~/.ssh2?
    >
    > Ans: ~/.ssh


    ~/.ssh/authorized_keys, not the old authorized_keys2 file. Yeah, the
    historical use of the authorized_keys2 has been gone for a while: it may
    still work for legacy reasons, but it's not the standard practice anymore.

    > 7. What should I name my authorized key file, authorized_keys or
    > authorized_keys2?
    >
    > Ans: authorized_keys
    >
    > 8. Do the host keys need to be generated and active (in /etc/...)
    > as well as the user keys (i.e., in ~/.ssh/...)?
    >
    > Ans: No, only the user key in the user's home directory.
    >
    > 9. When the src host is attempting to connect to the dst host, how
    > does the dst host know which key in the authorized_keys file to mate
    > with the src host?
    >
    > Ans: Don't know


    It goes down the list, based on the keys the client has available, looking
    for the working key. If you have multiple old keys for your client, it will
    eventually say "I've tried too many keys for that client, I'll give up now"
    and go to password based login.

    > 10. What exactly is host-based authentication versus public key
    > authentication?
    >
    > Ans: This is a very unfortunate nomenclature. Both use
    > public/private key pairs. The simple answer is that host-based
    > authenticatation authenticates using one key (that in /etc/ssh/...)
    > no matter which src user account is being used. Public key
    > authentication keys are src user-dependent (from the user's ~/.ssh
    > directory).
    >
    > 11. When specifying sshd options, which host should they be
    > changed in, src or dst or both?
    >
    > Ans: dst. The reason this question lingered in my mind is
    > that I had no idea how the ssh and sshd clients and servers
    > interact on the src and dst machines, and was thinking it
    > might be possible that the src server interacts with the
    > dst server.
    >
    > 12. Exactly what permissions are required in order for
    > public key authentication to work? Are they permissions
    > on the src, or permissions on the dst, or both?
    >
    > Ans: Not sure of this one, but setting StrictModes to
    > no makes the question moot.


    ~/.ssh and especially the private keys and authorized_keys in it should be
    set to not allow any access to other users or groups. It's OK to set your
    public keys to universal read or write: they're not used in the SSH
    transaction, unless they're copied into ~/.ssh/authorized_keys.

    > 13. Does public key authentication require valid reverse DNS
    > lookups?
    >
    > Ans: No. However, I'm not sure the same is true for host-based
    > authentication.


    You can play with this: a stable forward/reverse DNS setup is pretty useful.

    >
    > Note that, after about 4 days of fiddling around with the damn thing,
    > it was number 12 that caused my connections to start working.
    >
    > This is UNACCEPTABLE, and all of these questions should have
    > been *clearly* answered in a user manual/FAQ. They were not.
    >
    > If the openSSH community wants this development to thrive, these
    > shortcomings in the documention should be repaired.
    >
    > --Randy Yates
    >
    >
    >
    > [1] Note that I distinguish between protocol version (1 or 2)
    > and software version (e.g., the specific openSSH software
    > version).
    >
    > [2] I use the syntax "src" to refer to the source host (i.e.,
    > the host being connected from) and "dst" to designate the
    > destination host (i.e., the host being connected to).


    Well, it's explained in much more detail in the SSH book from O'Reilly,
    which was actually written mostly by someone on this list. I see your point.
    The docs could use some updating.



  3. Re: ssh is hard to use

    On 2006-08-20, Randy Yates wrote:
    > Hi Folks,
    >
    > I'm using openSSH 4.0p1 (0.9.7f) on Fedora Core 4, and I just had a
    > very frustrating experience the last few days trying to get public key
    > authentication to work.
    >
    > The situation was this: I have two systems on a private network here
    > at the house behind a firewall. Neither have domain names but rather
    > are addressed by numeric IP address, which is dynamically assigned by
    > the Linksys router/firewall. My goal was to be able to scp from one
    > system to the other from a script without having to manually intervene
    > to type passwords.
    >
    > My experience was that, no matter what I tried, I could not get a
    > passphrase prompt when ssh'ing in (without ssh-agent). Here are some
    > of the things I tried and/or questions I asked myself, most of which I
    > had seen in one of the numerous FAQs/tutorials on the subject:
    >
    > 1. Am I using protocol 1 or protocol 2? How do I know if the
    > software version [1] supports protocol 2?
    >
    > Ans: I still don't know the answer to this one.


    You can determine this from the software's documentation. In the case of
    OpenSSH, any version from the last 4 or 5 years will support both.

    >
    > 2. How do I know for sure protocol 2 is enabled?
    >
    > Ans: via the "Protocol" option in sshd_config.
    > 3. How do I know protocol 2 is being used and not protocol 1?
    >
    > Ans: By specifying "Protocol 2" and not "Protocol 2,1" in sshd_conf.


    Right. Also can be set on the client in ssh_config and ~/.ssh/config,
    or by using the "-1" or "-2" options to ssh.

    > 4. Should I use rsa or dsa keys (ssh-keygen -t rsa or ssh-keygen -t
    > dsa)?
    >
    > Ans: Don't know.


    Use DSA for maximum compatibility with other SSH software and RSA if
    you want to use longer keys. OpenSSH supports both.

    Background: DSA is mandatory in the spec whereas RSA is optional (the
    latter was patented in the USA up until a couple of years ago) but these
    days most SSH implementations support both. You can safely use either.

    > 5. Where should I put my private key? src:.~/.ssh, or src:~/.ssh2
    > [2]?
    >
    > Ans: ~/.ssh. Apparently the old .ssh2 stuff was done away with at
    > some point in the protocol 2 development history.
    >
    > 6. Where should I put my authorized key file, dst:~/.ssh or dst:~/.ssh2?
    >
    > Ans: ~/.ssh


    ~/.ssh2 is used by Tectia's software and is not (and, as far as I can tell
    has never) been used in OpenSSH or mentioned in its documentation.

    >
    > 7. What should I name my authorized key file, authorized_keys or
    > authorized_keys2?
    >
    > Ans: authorized_keys


    Right. authorized_keys2 is deprecated and not mentioned in the
    documentation (but still supported for backward compatibility). Either
    will work.

    > 8. Do the host keys need to be generated and active (in /etc/...)
    > as well as the user keys (i.e., in ~/.ssh/...)?
    >
    > Ans: No, only the user key in the user's home directory.


    Right, you don't need to add keys in /etc/ for user authentication.

    The system needs host keys in /etc/ but these are usually generated
    automatically when sshd is installed and don't usually change.

    > 9. When the src host is attempting to connect to the dst host, how
    > does the dst host know which key in the authorized_keys file to mate
    > with the src host?
    >
    > Ans: Don't know


    Simplifying slightly, the client sends the public keys that it has (eg
    ~/.ssh/id_rsa.pub or ~/.ssh/id_dsa.pub) to the server, and the server
    says whether or not it would accept each one. The client then proves
    that it has the corresponding private key and the server logs you in.

    > 10. What exactly is host-based authentication versus public key
    > authentication?
    >
    > Ans: This is a very unfortunate nomenclature. Both use
    > public/private key pairs. The simple answer is that host-based
    > authenticatation authenticates using one key (that in /etc/ssh/...)
    > no matter which src user account is being used. Public key
    > authentication keys are src user-dependent (from the user's ~/.ssh
    > directory).


    Hostbased is a more secure alternative to traditional .rhosts
    authentication which does not rely purely on the source address of
    the connection. It uses the host keys (not user keys) to prove
    that it's really the source host that it's claiming to be.

    In most cases you would want to use public-key authentication rather
    than hostbased.

    > 11. When specifying sshd options, which host should they be
    > changed in, src or dst or both?
    >
    > Ans: dst. The reason this question lingered in my mind is
    > that I had no idea how the ssh and sshd clients and servers
    > interact on the src and dst machines, and was thinking it
    > might be possible that the src server interacts with the
    > dst server.


    sshd_config must be changed on the server, but there are similar config
    files on the client (ssh_config or ~/.ssh/config) that control it.

    > 12. Exactly what permissions are required in order for
    > public key authentication to work? Are they permissions
    > on the src, or permissions on the dst, or both?
    >
    > Ans: Not sure of this one, but setting StrictModes to
    > no makes the question moot.


    644 on the keys, 755 on the ~/.ssh and home directories on the server.
    It's mentioned in sshd(8) under the the FILES section but not explicitly.

    > 13. Does public key authentication require valid reverse DNS
    > lookups?
    >
    > Ans: No. However, I'm not sure the same is true for host-based
    > authentication.


    Whether or not hostbased needs reverse name resolution (DNS or hosts file)
    depends on the HostbasedUsesNameFromPacketOnly setting in sshd_config
    (which is conspicuous by its absence from sshd_config(5)).

    > Note that, after about 4 days of fiddling around with the damn thing,
    > it was number 12 that caused my connections to start working.
    >
    > This is UNACCEPTABLE, and all of these questions should have
    > been *clearly* answered in a user manual/FAQ. They were not.
    >
    > If the openSSH community wants this development to thrive, these
    > shortcomings in the documention should be repaired.


    There has been work in recent times to improve the manual pages (the
    version of the software you are using, and thus its man pages, are around
    a year and a half old). The latest versions of the manuals are always
    here: http://www.openssh.com/manual.html

    The following is a quote from the current version of the sshd(8) man page,
    which answers some of the questions you asked here.


    AUTHENTICATION
    The OpenSSH SSH daemon supports SSH protocols 1 and 2. Both protocols
    are supported by default, though this can be changed via the Protocol op-
    tion in sshd_config(5). Protocol 2 supports both RSA and DSA keys; pro-
    tocol 1 only supports RSA keys. For both protocols, each host has a
    host-specific key, normally 2048 bits, used to identify the host.

    Forward security for protocol 1 is provided through an additional server
    key, normally 768 bits, generated when the server starts. This key is
    normally regenerated every hour if it has been used, and is never stored
    on disk. Whenever a client connects, the daemon responds with its public
    host and server keys. The client compares the RSA host key against its
    own database to verify that it has not changed. The client then gener-
    ates a 256-bit random number. It encrypts this random number using both
    the host key and the server key, and sends the encrypted number to the
    server. Both sides then use this random number as a session key which is
    used to encrypt all further communications in the session. The rest of
    the session is encrypted using a conventional cipher, currently Blowfish
    or 3DES, with 3DES being used by default. The client selects the encryp-
    tion algorithm to use from those offered by the server.

    For protocol 2, forward security is provided through a Diffie-Hellman key
    agreement. This key agreement results in a shared session key. The rest
    of the session is encrypted using a symmetric cipher, currently 128-bit
    AES, Blowfish, 3DES, CAST128, Arcfour, 192-bit AES, or 256-bit AES. The
    client selects the encryption algorithm to use from those offered by the
    server. Additionally, session integrity is provided through a crypto-
    graphic message authentication code (hmac-sha1 or hmac-md5).

    Finally, the server and the client enter an authentication dialog. The
    client tries to authenticate itself using host-based authentication, pub-
    lic key authentication, challenge-response authentication, or password
    authentication.

    If the client successfully authenticates itself, a dialog for preparing
    the session is entered. At this time the client may request things like
    allocating a pseudo-tty, forwarding X11 connections, forwarding TCP con-
    nections, or forwarding the authentication agent connection over the se-
    cure channel.

    After this, the client either requests a shell or execution of a command.
    The sides then enter session mode. In this mode, either side may send
    data at any time, and such data is forwarded to/from the shell or command
    on the server side, and the user terminal in the client side.

    When the user program terminates and all forwarded X11 and other connec-
    tions have been closed, the server sends command exit status to the
    client, and both sides exit.
    --
    Darren Tucker (dtucker at zip.com.au)
    GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69
    Good judgement comes with experience. Unfortunately, the experience
    usually comes from bad judgement.

  4. Re: ssh is hard to use

    On 2006-08-20, Nico Kadel-Garcia wrote:
    > Randy Yates wrote:

    [...]
    >> 3. How do I know protocol 2 is being used and not protocol 1?
    >>
    >> Ans: By specifying "Protocol 2" and not "Protocol 2,1" in sshd_conf.

    >
    > It does protocol 2 and 1 in the listed order.


    The order only applies to the client side (ie ssh_config). The server can
    choose where or not to offer each protocol but the client decides which
    it will use.

    >> 4. Should I use rsa or dsa keys (ssh-keygen -t rsa or ssh-keygen -t
    >> dsa)?
    >>
    >> Ans: Don't know.

    >
    > DSA is for protocol 2. Use that.


    In ssh-keygen(1) terms, both "rsa" and "dsa" are supported for Protocol 2.
    "rsa1" is the format for Protocol 1 keys.

    See my previous response for more detail.

    [...]
    > Well, it's explained in much more detail in the SSH book from O'Reilly,
    > which was actually written mostly by someone on this list. I see your point.
    > The docs could use some updating.


    Diffs are welcome (but check the current versions first).

    --
    Darren Tucker (dtucker at zip.com.au)
    GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69
    Good judgement comes with experience. Unfortunately, the experience
    usually comes from bad judgement.

+ Reply to Thread