Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
scott@slp53.sl.home (Scott Lurndal) writes:boltar@caprica.universe writes:[...][...]Oh FFS, the hacker server would use whatever keys the hacker wanted it to>
use. Do try and keep up.
You don't seem to have an understanding of the session
establishment protocol used by ssh, or the context of the
thread you've butted into (context: the ability for a
non-privileged process to bind to ports below 1024).
>
In that particular scenario, the non-privleged process
cannot read the host key. Yes, it can present a different
host key, which David pointed out may cause the client to
complain that the host key has been changed - a clear warning
to the user that the host he is attempting to log into may
have been compromised.
>
If I understand correctly, a non-root user can set up a server on a
"privileged" port, but not if that port is already in use. If root
is already has sshd listening on port 22, a non-root user won't
be able to set up another server on the same port. (And an ssh
server on a port other than 22 isn't going to be visible unless
someone goes looking for it.)
>
Which means, unless I'm missing something, that the warning about
a changed host key is not likely to show up. (Unless the system
doesn't have an ssh server -- but then how does the user get
into it?)
The SSH protocol is conceptually layered into two parts: the
"SSH transport protocol", described in RFC4253, is the lower
layer protocol, and authenticates _hosts_ (see section 1 of the
RFC). A side-effect of the host authentication exchange is
the generation of a random ephemeral encryption key suitable for
use with a symmetric cipher.
This type of authentication is based on public key cryptography.
When SSH server software is installed onto a computer, part of
the initial configuration process is generating a public/private
key pair (the "host key") that is used in the host
authentication protocol; the public key is distributed widely,
while the private key is (as the name implies) private to the
server itself. One of the most basic mechanisms for securing
the host private key is ensuring that only the administrator can
read it.
User authentication is described in RFC4252 ("the Secure Shell
Authentication Protocol"). It is intended to be used over a
connection already host-authenticated and encrypted by the SSH
transport protocol.
You are correct that if an SSH server is already running and
bound to the well-known SSH server port (e.g., TCP port 22),
then some other programm cannot bind to that port (even if
running as root).
But suppose the SSH daemon is not running, and some random user
sets up an imposter server listening on that port. Since
unprivileged users can bind any port (including 22), they can do
so. But, since they presumably cannot read the file containing
the host private key, they lack the cryptographic key material
required to authenticate as the real server using the RFC4253
host authentication protocol. Clients will notice that and
fail to establish an SSH transport protocol connection, well
before user authentication is attempted, let alone a shell or
anything similar is executed.
And even if there's no existing ssh server, a non-root sshd would
only provide access to the user's account.
Not even. The client wouldn't be able to authenticate the
identity of the server _at all_, regardless of what user it was
running at.
More plausibly, a non-root user could set up an ftp server.
Potentially they could, though most Unix-y systems store the
user's password hashed using some one-way algorithm that is not
easily invertible, and on top of that, only allow privileged
access to the hashed passwords. So they could set up an
imposter FTP service (who uses the insecure FTP protocol in this
day and age?!) and collect passwords the user enters, but they
could not necessarily validate that those passwords are actually
the user's real password.
- Dan C.
Les messages affichés proviennent d'usenet.