OpenSSH: SSH2 sshd - Increase key size from 2048 to 8192 bits (Cygwin) - SSH

This is a discussion on OpenSSH: SSH2 sshd - Increase key size from 2048 to 8192 bits (Cygwin) - SSH ; X-No-Archive: Yes In short: How do I change OpenSSH's sshd's host-key-pair size from 2048 bits to 8192 bits? I am only using the SSH2 protocol. I'm using sshd from OpenSSH under Cygwin (XP-Pro). It works great but I need to ...

+ Reply to Thread
Results 1 to 6 of 6

Thread: OpenSSH: SSH2 sshd - Increase key size from 2048 to 8192 bits (Cygwin)

  1. OpenSSH: SSH2 sshd - Increase key size from 2048 to 8192 bits (Cygwin)

    X-No-Archive: Yes

    In short: How do I change OpenSSH's sshd's host-key-pair size from
    2048 bits to 8192 bits? I am only using the SSH2 protocol.

    I'm using sshd from OpenSSH under Cygwin (XP-Pro).
    It works great but I need to increase the size of my (sshd's) keys.
    My client's key-pair (PuTTY/PuTTYgen) is 8192 bits long and
    is implemented perfectly. However, I need the same key length
    to be used by sshd.

    I basically want sshd to use keys that are 8192 bits in length.
    I know that its default host-key-pair size is 2048. I want to change
    this to 8192 bits. I only use the SSH2 protocol so changing the
    the server-key-pair size to 8192 bits isn't an option since SSH2 uses
    Diffie-Hellman key exchange and does not implement a server-key-pair?:

    FROM OPENSSH's MANUAL PAGES:

    "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-md5, hmac-sha1, umac-64
    or
    hmac-ripemd160).

    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."

    When looking up exactly how SSH works I found out that
    the daemon for protocol 1 has two key pairs. The host-key-pair
    and the server-key-pair. The host-key-pair is permanent and is used
    for both encryption and identification (by the client). The
    server-key-pair is generated at a regular interval. The client
    generates the AES-256 key randomly, encrypts it using the
    public host and server keys and sends it to the sshd.
    So this only works under SSH1 and SSH2 uses Diffie-Hellman
    key exchange...

    The sshd_config file allows me to specify the size of the
    server-key pair and as you can see below I've made it 8192
    bits long. BUT it says "Lifetime and size of ephemeral version 1
    server key"
    and the OpenSSH site says ServerKeyBits: "Defines the number of bits
    in the ephemeral protocol version 1 server key. The minimum value is
    512, and the default is 768."
    So does the above only apply to SSH1 which I have disabled through the
    sshd_config file?

    Here's (part of) my 'sshd_config' file:

    Port 51235 [I use one of the dynamic/private ports]
    Protocol 2

    # HostKeys for protocol version 2
    #HostKey /etc/ssh_host_rsa_key
    #HostKey /etc/ssh_host_dsa_key

    # Lifetime and size of ephemeral version 1 server key [THIS IS
    PROTOCOL 1?]
    KeyRegenerationInterval 3600
    ServerKeyBits 8192

    # Authentication:
    #LoginGraceTime 2m
    PermitRootLogin no
    StrictModes no
    #MaxAuthTries 6

    RSAAuthentication yes
    #PubkeyAuthentication yes
    AuthorizedKeysFile .ssh/authorized_keys2

    # To disable tunneled clear text passwords, change to no here!
    PasswordAuthentication no
    #PermitEmptyPasswords no

    # Change to no to disable s/key passwords
    #ChallengeResponseAuthentication yes

    # [ADDED MANUALLY!] Ciphers:
    aes256-cbC

    #AllowTcpForwarding yes
    #GatewayPorts no
    #X11Forwarding no
    #X11DisplayOffset 10
    X11UseLocalhost no
    #PrintMotd yes
    #PrintLastLog yes
    #TCPKeepAlive yes
    #UseLogin no
    #UsePrivilegeSeparation yes
    #PermitUserEnvironment no
    Compression yes
    #ClientAliveInterval 0
    #ClientAliveCountMax 3
    #UseDNS yes
    #PidFile /var/run/sshd.pid
    #MaxStartups 10
    PermitTunnel yes

    # override default of no subsystems
    Subsystem sftp /usr/sbin/sftp-server

    Thanks in advance. Sorry for the mess.


  2. Re: OpenSSH: SSH2 sshd - Increase key size from 2048 to 8192 bits (Cygwin)

    wrote:
    > In short: How do I change OpenSSH's sshd's host-key-pair size from
    > 2048 bits to 8192 bits? I am only using the SSH2 protocol.


    Are you sure that's what you want to do? Why?

    The host key is used by the server to authenticate itself to the
    client. So increasing the size of the host key makes it more
    difficult for an active attacker to pretend to be the server.
    However, it doesn't make it any more difficult for a passive network
    snooper to recover the session keys, because the session keys are
    set up (as you note) through Diffie-Hellman key exchange, which
    doesn't involve the host key at all.

    Your question, interpreted literally, says you just want to change
    the host keys, i.e. to make life (even) harder for active attackers.
    But then you say that in SSH-1 you got what you wanted by increasing
    the server key length - and that's only important to _passive_
    attackers, because the server key performs a similar function to the
    DH key exchange. So it isn't clear whether what you really want is
    what you actually asked for, or not.

    You can change the host keys themselves easily enough: they're
    typically stored in /etc/ssh/ssh_host_rsa_key and
    /etc/ssh/ssh_host_dsa_key. So use ssh-keygen to create new keys and
    put them in place of those, and make them as big as you like. Of
    course you also have to make sure the .pub files alongside them
    match up, and you have to warn your users to expect to have to
    update their copies of the host key in all their SSH clients' host
    key caches.

    I don't know of a way in OpenSSH to configure the group size used in
    Diffie-Hellman exchanges.

    On a more practical note, why do you need 8192 bits anyway? Even at
    2048 bits, it's already likely that the most practical attacks
    against your system are _not_ ones involving cryptanalysis of either
    the host key or the DH key exchange. Making those already-hard
    attacks even harder will therefore have very little effect on your
    real security; so if you have resources to spend, you should be
    spending them on trying to prevent types of attack which go _round_
    the SSH cryptography rather than through it: social engineering,
    theft of user private keys, guessable passwords, buffer overflows in
    server software...
    --
    Simon Tatham "You may call that a cheap shot.
    I prefer to think of it as good value."

  3. Re: OpenSSH: SSH2 sshd - Increase key size from 2048 to 8192 bits (Cygwin)

    Thanks for the reply.
    I know I made it a long and confusing post but in short: does OpenSSH
    inherently allow you to change the host-key-pair size? If so, how? I
    do not want to do this manually.
    On a side note: the server is well protected, even though on XP-
    PRO , and NT security rules and general security protocol can't be
    broken unless someone has a gun to my back.


  4. Re: OpenSSH: SSH2 sshd - Increase key size from 2048 to 8192 bits (Cygwin)

    X-No-Archive: Yes

    Thanks for the reply.
    I know I made it a long and confusing post but in short: does OpenSSH
    inherently allow you to change the host-key-pair size? If so, how? I
    do not want to do this manually.
    On a side note: the server is well protected, even though on XP-
    PRO , and NT security rules and general security protocol can't be
    broken unless someone has a gun to my back.


  5. Re: OpenSSH: SSH2 sshd - Increase key size from 2048 to 8192 bits (Cygwin)

    On 2007-08-15, Simon Tatham wrote:
    > I don't know of a way in OpenSSH to configure the group size used in
    > Diffie-Hellman exchanges.


    You can't directly, but one thing you can do is remove the smaller groups
    from the "moduli" file on the server.

    When the client asks for a DH group, sshd searches the moduli file for
    groups and picks one at random from the set at least as large as what
    the client requested. If there's no small (eg 1k, 1.5k) keys, then sshd
    will always use larger ones.

    The moduli file that ships with current OpenSSH versions has groups up
    to 6k. I generated a couple of 8k ones (which took about a month :-)
    when I last rebuilt the file[1], but it's not in any release.

    That said, I agree with what you said about larger keys/groups being
    mostly irrelevant.

    [1] http://www.zip.com.au/~dtucker/openssh/moduli

    --
    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.

  6. Re: OpenSSH: SSH2 sshd - Increase key size from 2048 to 8192 bits (Cygwin)

    >>>>> "DT" == Darren Tucker writes:

    DT> On 2007-08-15, Simon Tatham wrote:
    >> I don't know of a way in OpenSSH to configure the group size used
    >> in Diffie-Hellman exchanges.


    DT> You can't directly, but one thing you can do is remove the smaller
    DT> groups from the "moduli" file on the server.

    DT> When the client asks for a DH group, sshd searches the moduli file
    DT> for groups and picks one at random from the set at least as large
    DT> as what the client requested. If there's no small (eg 1k, 1.5k)
    DT> keys, then sshd will always use larger ones.

    Small note: this will only work if the connection uses the "group
    exchange" key exchange method; it might use one of the fixed-group
    exchanges intead...

    --
    Richard Silverman
    res@qoxp.net


+ Reply to Thread