Re: ssh protocol 2,1

The reason is is because aix version 4.3 stock out of the box is ssh
version 1. That means both client and server are both ssh 1. old
versions of aix
are not the only culprits. Default installations try to be as
"friendly" as possible so others on what ever network you install on
will work. Being friendly
sometimes means not being entirely secure. For example, the default
port for ssh is also 22. Well guess what, every linxu box I have that
has access
to the outside world via ssh does not use the default port, mainly
because I don't need to see the endless spam on my security reports.
Again, is this
right? or friendly? I guess in the end, if you really are a sys-admin
being paid to worry about security, then you should know there does
exist ssh 1/2
and to make sure your systems are listening and using protocols your
enterprise deem appropriate.

That's my 2 cents worth.

Wayner


bjt@xxxxxxxxxxxxxxxx 06/20/06 10:26 am >>>
Mike Burger wrote:
On Tue, 20 Jun 2006, Bill Tangren wrote:

I have a question regarding ssh on RHEL ES4. The man pages indicates

that Protocol 2,1 is enabled by default. Could someone explain the
logic of this to me? I thought Protocol 1 had a security flaw.


That would cause SSHD to require protocol 2, first, then fall back to

protocol 1 if the client isn't protocol 2 capable.

If you want to restrict sshd to just protocol 2, remove the ",1".
--
Mike Burger
http://www.bubbanfriends.org


From the man page for sshd_config:
**********
Protocol
Specifies the protocol versions ssh supports. The possible values are
"1" and
"2". Multiple versions must be comma-separated. The default is
"2,1". Note
that the order of the protocol list does not indicate preference,
because the
client selects among multiple protocol versions offered by the server.

Specifying "2,1" is identical to "1,2".
**********

This doesn't actually answer my question. If someone *wanted* to
exploit the
Protocol 1 vulnerability, wouldn't that be easy? [It is a simple
protocol choice
in Putty, for example.]

There must be a reason for allowing this vulnerability by default. I'd
like to
know what that reason is.

Thanks for answering, though.

Bill


--
redhat-list mailing list
unsubscribe mailto:redhat-list-request@xxxxxxxxxx?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/redhat-list

--
redhat-list mailing list
unsubscribe mailto:redhat-list-request@xxxxxxxxxx?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/redhat-list

Relevant Pages

  • Re: Is it possible to tunnel X-Window data across many servers?
    ... SSH Version 1.2.30, protocol version 1.5. ... Waiting for server public key. ... QA_servB.com: Remote: X11 forwarding disabled in server configuration file. ...
    (comp.security.ssh)
  • Re: Remote access from Internet
    ... An initial proposal was to implement the entire user interface as a Java applet and use a simple back-end protocol to move data. ... The user who desires access connects to relay server with a browser and logs in. ... then you probably need to block all ports *except* for one that you actively manage - ideally by something strong like SSH. ... As a side note on ssh security, there is no need to put ssh on port 22. ...
    (comp.arch.embedded)
  • Re: No username prompt SSHD
    ... No it is the server side because when you just to do a " ssh server". ... # HostKey for protocol version 1 ... # Kerberos options ...
    (SSH)
  • [NEWS] SSH Protocol Weakness Vulnerability (MITM)
    ... A weakness in the backward compatibility of the SSH Protocol has been ... SSH version 1.0) is unlikely to have the host key for the other protocol ... The SSH daemons advertise one of two major versions, ...
    (Securiteam)
  • SUMMARY: SSH 2.5.2p2 on Tru64 4.0g
    ... SSH is very particular about the permissions on the $HOME/.ssh ... Always pay particular attention the the ssh SERVERs protocol usage. ... when only using the identity.pub or rsa key. ... file on the remote host to reflect the host name without domain that was ...
    (Tru64-UNIX-Managers)