[buug] Secure Shell Success?

[Rick Moen]

begin  Zeke Krahlin quotation:

> Well, I finally *can connect to weak.org, via Secure-Shell in Linux (I
> had been using a simple secure-shell utility in Windoze). This is
> after installing the necessary "openssl"/"openssh" libraries. However,
> I can only do this as super-user, not as regular user. Is this how
> it's supposed to work?

Nope.  Your system is partially broken.  In particular:

> But when I perform the same command as a plain old user, I get the
> following retort:
> 
>      You don't exist, go away!

If memory serves, this is the error you tend to get when a process
double-checks to see if you're in the authentication database (e.g., 
/etc/shadow or wherever the user passwords are kept) and unexpectedly 
finds that you're not a valid user.  This might happen if, for example,
the process can't get to the authentication database at all because its 
effective user ID (under whose authority the user operates) lacks
permission to read it.

(The above rests on my slightly shaky recollection of what the quoted
error means in this context, but I _believe_ that's right.)

Unfortunately, I'm not sure where the breakage has occurred.  You might
have altered something in the PAM (Pluggable Authenication Modules)
layer stuff, or it could be one of those SUID-bit removals or other
permission changes that Chris Stoddard's article recommended to you.
Or you might have made some error in compiling OpenSSH or OpenSSL.

You might try removing your current OpenSSH/OpenSSL installation.  (You
_did_ install it to the /usr/local/ tree, right?)  Then, install via
RPM the (international-version) OpenSSH and OpenSSL pacakges from
Linux-Mandrake's off-shore cryptographic archives, discussed earlier.
Then try remote login, again.  If it still fails, then your system is
still damaged from the foray into Chris Stoddard's recommendations.

By the way, I'm making current versions of OpenSSH and OpenSSL available
at http://linuxmafia.com/pub/linux/security/openssh/ , including a patch
to fix an old, long-known problem of occasional deadlocking that you
sometimes got on large files when using rsync over SSH transport.

A long-time free-software hacker, Ton Hospel, actually found and fixed 
the cause of that deadlock in Tatu Ylönen's reference SSH
implementation, years ago, but declined to contribute his patch because
he was annoyed at Ylönen's company (SSH Communications Security, Ltd.) 
having taken his prior contributions proprietary.  So, Hospel created
a GPLed C-code wrapper program for the reference SSH.  People who run 
that implementation (and who use rsync) should consider getting the 
wrapper.  It's at
http://linuxmafia.com/pub/linux/security/ylonen-ssh/ssh-rsync-wrapper

> Since "ssh" is "secure", is logging on as root as safe as user?

I can answer that question, but it's not the question you really mean
to ask.  You really should ask "Is this behaviour a problem?"  Yes, it
is.  Your system appears to have a fundamental problem that you need to
fix.  It may also have other problems of which is the tip of the
iceberg.

To address your question, there is a minor disadvantage to even
_allowing_ the root user to SSH in:  If you configure sshd to disallow
such access, and thereby require that users SSH in as a regular user
first, and then use "su" or "sudo" to wield root authority, the system
retains records in its logs as to _which_ remote user wielded root
authority at a given time, which can be valuable information.

(Often, when I mention this recommendation to people, they immediately
object that you cannot identify a system cracker from "su" or "sudo" 
logs, because he can alter those upon cracking root.  True, but
irrelevant to my point:  I _didn't say_ you could use this information 
to chase down crackers.  I said it helps in routine administration,
under _non_-attack conditions, in tracing back which remote user did
what, and when, using root authority.)

> As super-user, I access weak.org like so:
> 
>      ssh weak.org -l ezekielk

By the way, a better syntax also works:

       ssh ezekialk at weak.org

This also works in scp'ing (secure cp'ing) between machines where you
need to specify some non-default username.  Let's suppose I'm "rick" on
the machine I'm typing on, but "rmoen" on a different machine, inigo:

       scp  /tmp/*  rmoen at inigo.linuxmafia.com:/tmp

This copies all files from the local /tmp directory over an SSH tunnel
to the /tmp directory on the remote machine, inigo, logging into inigo
as "rmoen" rather than using my local username (rick) by default.

Notice the colon at the end of the remote machine's name, which is how
scp knows that the destination isn't just a local filespec.  (Believe
me, you'll forget that colon a few times, resulting in a few bizarrely
named local files.)

> If I must run ssh as user, I'll have to "reverse engineer" my secured
> gateway, to find out which switch is denying me ssh-access.

You got that right.

> Perhaps I need to recreate "hosts.allow" and add "weak.org" to it?

Nope, that's not it.  If it were a TCP Wrappers (tcpd, or libwrap)
problem, you'd not be allowed to connect to that service from the source
machine, for any user.  TCP Wrappers doesn't even know anything about 
which user is connecting, only about IP addresses and socket numbers.

-- 
Cheers,                              "Open your present...."
Rick Moen                            "No, you open your present...."
rick (at) linuxmafia.com             Kaczinski Christmas.
               --  Unabomber Haiku Contest, CyberLaw mailing list