OpenSSH Assistance - New Admin - Networking

This is a discussion on OpenSSH Assistance - New Admin - Networking ; I am a windows admin and was told 2 weeks ago to take over the linux servers because I had some linux desktop experience and no one else did. The first thing I was told was to upgrade our SSH ...

+ Reply to Thread
Results 1 to 10 of 10

Thread: OpenSSH Assistance - New Admin

  1. OpenSSH Assistance - New Admin

    I am a windows admin and was told 2 weeks ago to take over the linux
    servers because I had some linux desktop experience and no one else
    did.

    The first thing I was told was to upgrade our SSH server. Since the
    upgrade on friday no one can log into it. Not even as root on
    localhost. Here is the -vv

    User need to be able to log in with username from the shell and
    password or RSA.

    Thanks

    OpenSSH_4.3p2 Debian-9etch3, OpenSSL 0.9.8c 05 Sep 2006
    debug1: Reading configuration data /etc/ssh/ssh_config
    debug1: Applying options for *
    debug2: ssh_connect: needpriv 0
    debug1: Connecting to localhost [127.0.0.1] port 22.
    debug1: Connection established.
    debug1: permanently_set_uid: 0/0
    debug1: identity file /root/.ssh/identity type -1
    debug1: identity file /root/.ssh/id_rsa type -1
    debug1: identity file /root/.ssh/id_dsa type -1
    ssh_exchange_identification: Connection closed by remote host

    Here is the config file

    # Package generated configuration file
    # See the sshd(8) manpage for details

    # What ports, IPs and protocols we listen for
    Port 22
    # Use these options to restrict which interfaces/protocols sshd will
    bind to
    #ListenAddress ::
    #ListenAddress 0.0.0.0
    Protocol 2
    # HostKeys for protocol version 2
    HostKey /etc/ssh/ssh_host_rsa_key
    HostKey /etc/ssh/ssh_host_dsa_key
    #Privilege Separation is turned on for security
    UsePrivilegeSeparation yes

    # Lifetime and size of ephemeral version 1 server key
    KeyRegenerationInterval 3600
    ServerKeyBits 768

    # Logging
    SyslogFacility AUTH
    LogLevel INFO

    # Authentication:
    LoginGraceTime 600
    PermitRootLogin yes
    StrictModes yes

    RSAAuthentication yes
    PubkeyAuthentication yes
    #AuthorizedKeysFile %h/.ssh/authorized_keys

    # Don't read the user's ~/.rhosts and ~/.shosts files
    IgnoreRhosts yes
    # For this to work you will also need host keys in /etc/
    ssh_known_hosts
    RhostsRSAAuthentication no
    # similar for protocol version 2
    HostbasedAuthentication no
    # Uncomment if you don't trust ~/.ssh/known_hosts for
    RhostsRSAAuthentication
    #IgnoreUserKnownHosts yes

    # To enable empty passwords, change to yes (NOT RECOMMENDED)
    PermitEmptyPasswords no

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

    # Change to yes to enable tunnelled clear text passwords
    PasswordAuthentication yes


    # To change Kerberos options
    #KerberosAuthentication no
    #KerberosOrLocalPasswd yes
    #AFSTokenPassing no
    #KerberosTicketCleanup no

    # Kerberos TGT Passing does only work with the AFS kaserver
    #KerberosTgtPassing yes

    X11Forwarding yes
    X11DisplayOffset 10
    PrintMotd no
    PrintLastLog yes
    KeepAlive yes
    UseLogin yes

    #MaxStartups 10:30:60
    Banner /etc/issue.net

    Subsystem sftp /usr/lib/openssh/sftp-server

    UsePAM yes
    ChallengeResponseAuthentication no

  2. Re: OpenSSH Assistance - New Admin

    Sealg writes:

    > I am a windows admin and was told 2 weeks ago to take over the linux
    > servers because I had some linux desktop experience and no one else
    > did.
    >
    > The first thing I was told was to upgrade our SSH server. Since the
    > upgrade on friday no one can log into it. Not even as root on
    > localhost. Here is the -vv



    > debug1: identity file /root/.ssh/identity type -1
    > debug1: identity file /root/.ssh/id_rsa type -1
    > debug1: identity file /root/.ssh/id_dsa type -1



    Do any of these files exist?

  3. Re: OpenSSH Assistance - New Admin

    Sealg wrote:
    > I am a windows admin and was told 2 weeks ago to take over the linux
    > servers because I had some linux desktop experience and no one else
    > did.
    >
    > The first thing I was told was to upgrade our SSH server. Since the
    > upgrade on friday no one can log into it. Not even as root on
    > localhost. Here is the -vv
    >
    > User need to be able to log in with username from the shell and
    > password or RSA.
    >
    > Thanks
    >

    [snip]

    first off, I recommend WebMin to help you out.

    For this in particular, migh be an issue with the client settings.
    They may not be using the security method the server is set to use. So
    you may need to change the server configuration to match the clients.

  4. Re: OpenSSH Assistance - New Admin

    Sealg writes:

    > The first thing I was told was to upgrade our SSH server. Since the
    > upgrade on friday no one can log into it. Not even as root on
    > localhost. Here is the -vv


    Just to make sure it's not something trivial...

    Debian the distribution with the huge security flaw in SSh?
    The upgrade should have deleted the original certificates.

    If a user tries to connect to the upgraded service, they should get a
    warning that the certificates have changed.

  5. Re: OpenSSH Assistance - New Admin

    Maxwell wrote:

    > Sealg writes:
    >
    >> The first thing I was told was to upgrade our SSH server. Since the
    >> upgrade on friday no one can log into it. Not even as root on
    >> localhost. Here is the -vv


    > If a user tries to connect to the upgraded service, they should get a
    > warning that the certificates have changed.


    He or she won't get a warning. The connection will simply break like the
    one the OP posted. He might check if he changed the keys in /etc/ssh
    during the upgrade. If so, the entries for the server in the
    ssh_known_hosts files on the clients have to be deleted prior to a new
    login. Because of the security problem with OpenSSL on Debian [1] it
    might be risky to restore the old keys from backup.

    {1] http://lists.debian.org/debian-secur.../msg00152.html

    G√ľnther

  6. Re: OpenSSH Assistance - New Admin

    GŁnther Schwarz writes:
    >
    > He or she won't get a warning. The connection will simply break like the
    > one the OP posted. He might check if he changed the keys in /etc/ssh
    > during the upgrade. If so, the entries for the server in the
    > ssh_known_hosts files on the clients have to be deleted prior to a new
    > login. Because of the security problem with OpenSSL on Debian [1] it
    > might be risky to restore the old keys from backup.


    Yes, you get a warning about a possible man-in-the-middle attack
    because the key changed.


  7. Re: OpenSSH Assistance - New Admin

    Joe Pfeiffer wrote:

    > GŁnther Schwarz writes:
    >>
    >> He or she won't get a warning. The connection will simply break like
    >> the one the OP posted. He might check if he changed the keys in
    >> /etc/ssh during the upgrade.


    > Yes, you get a warning about a possible man-in-the-middle attack
    > because the key changed.


    Sorry, I messed that up. You're right. But as the connection is closed
    after the warning the user has no chance to correct the error without
    verifying the new key settings with the server admin. This is a nasty
    situation in a environment where lots of people log in with ssh. Email
    is not trustworthy and snail mail is expensive. Recording the MD5 sum
    of the new public key on an answering machine might do the trick.

    GŁnther

  8. Re: OpenSSH Assistance - New Admin

    GŁnther Schwarz writes:

    > Joe Pfeiffer wrote:
    >
    >> Yes, you get a warning about a possible man-in-the-middle attack
    >> because the key changed.

    >
    > Sorry, I messed that up. You're right. But as the connection is closed
    > after the warning the user has no chance to correct the error without
    > verifying the new key settings with the server admin. This is a nasty
    > situation in a environment where lots of people log in with ssh. Email
    > is not trustworthy and snail mail is expensive. Recording the MD5 sum
    > of the new public key on an answering machine might do the trick.


    This is configurable with the StrictHostKeyChecking setting (and
    actually, I'd forgotten that if it's set to "yes", you'll get the
    behavior you described. So we were actually both right).

  9. Re: OpenSSH Assistance - New Admin

    On Sep 30, 10:39*am, Joe Pfeiffer wrote:
    > GŁnther Schwarz writes:
    > > Joe Pfeiffer wrote:

    >
    > >> Yes, you get a warning about a possible man-in-the-middle attack
    > >> because the key changed.

    >
    > > Sorry, I messed that up. You're right. But as the connection is closed
    > > after the warning the user has no chance to correct the error without
    > > verifying the new key settings with the server admin. This is a nasty
    > > situation in a environment where lots of people log in with ssh. Email
    > > is not trustworthy and snail mail is expensive. Recording the MD5 sum
    > > of the new public key on an answering machine might do the trick.

    >
    > This is configurable with the StrictHostKeyChecking setting (and
    > actually, I'd forgotten that if it's set to "yes", you'll get the
    > behavior you described. *So we were actually both right).


    It was the keys. I got it straighted out.

    Thanks folks

  10. Re: OpenSSH Assistance - New Admin

    Joe Pfeiffer wrote:

    > GŁnther Schwarz writes:
    >
    >> Joe Pfeiffer wrote:
    >>
    >>> Yes, you get a warning about a possible man-in-the-middle attack
    >>> because the key changed.

    >>
    >> Sorry, I messed that up. You're right. But as the connection is
    >> closed after the warning the user has no chance to correct the error
    >> without verifying the new key settings with the server admin.

    >
    > This is configurable with the StrictHostKeyChecking setting (and
    > actually, I'd forgotten that if it's set to "yes", you'll get the
    > behavior you described. So we were actually both right).


    That's fine. I was not aware of this variable. Setting it to "no" might
    not be a good step towards security though.

    GŁnther

+ Reply to Thread