git: Remove most local modifications from OpenSSH.

[Matthew Dillon]

I think there was a little mix-up.  My intention was to never allow
clear-text passwords to be enabled by default and the repo has been fixed
to again set the default to no.

There are several reasons for allowing over-the-internet passwords being a
bad-idea, and I highly recommend that people ensure that they are disabled
for remote access regardless of what operating system you use.

* Psychologically, many people use similar passwords across multiple
services which means that a breech of one service can potentially make the
entire constellation of services used by the person vulnerable.

* Some people use easily guessable passwords, or password with 8 or fewer
characters.  8 characters doesn't cut it any more.

* There many be multiple accounts on a machine, some with passwords and
some not, making the securing of the machine difficult.  When remote-access
passwords are allowed, the more accounts there are, the more vulnerable the
machine is.

* Finally, most of us like to secure our personal machines and accounts for
friends (or developers) with passwords... for example, in order to login to
an account under X via xdm and to implement a simple screen lock.  Being
assured that those (typically relatively simple) passwords are not exposed
by default to remote login attempts is important.

I strongly recommend that only ssh public/private key-pairs be used, that
the private key be protected by a local password, and that it exist on only
one machine (aka your main workstation), and that your main workstation not
run any services at all (possibly not even sshd, or run sshd only for
localhost connections).  Then use agent forwarding as needed.


BROWSER SECURITY

Another thing I recommend is that if you run a browser on your main
workstation... and most of do, at least segregate it into a dummy account.
Even several dummy accounts (one for trusted sites, one for general
browsing, and perhaps a third for untrusted sites).  You can set the dummy
accounts up in several ways:

(1) For low security but high-performance browser access give the dummy
account access to the 'video' group in /etc/groups and ship your
.Xauthority file to the dummy account when you login to your main account.
Start the browser from your main account like this:  'ssh localhost -l
dummyacct1 "setenv DISPLAY :0.0; chrome".   I usually write a little script
called 'go' which does the ssh-add and scp's .Xauthority to the dummy
accounts that I run when I start X.

(2) For medium security browser access don't give the account access to the
'video' group.  This means that videos will be software-rendered and not be
able to directly use video acceleration, but the browser can still talk
directly to the X server.

(3) For totally untrusted browser access DO NOT SHIP your .Xauthority file
to the account.  Start the browser from your main account like this: 'ssh
-X localhost -l dummyacctN "chrome"'

Option(3) Might require a bit of work.  The X server is not currently being
compiled with the security extension (not sure why), and it isn't a dports
option either.  If you don't want to go through all the trouble you can use
-Y instead of -X, but using -Y puts the link in 'trusted' mode which means
that X client can monitor things like the keyboard.  -Y isn't really much
better than the direct-access methods that (1) and (2) use by setting
DISPLAY.

If you do want to get -X working, for now it means going into
/usr/dports/x11-servers/xorg-server and modifying the Makefile to add
--enable-xcsecurity to CONFIGURE_ARGS.  Then build the dport manually and
'make reinstall'.  Then completely kill and restart X (or reboot the
machine).  Exiting your window manager won't do it, you have to kill the
'X' process and the 'xdm' process (assuming you start X up using 'xdm').

You may also have to modify your /etc/ssh/sshd_config to enable X11
forwarding (not sure what the default is) and restart /usr/sbin/sshd.

Option 3 is going to be slow... obviously.  All of X operations are running
through a TCP link so stuff like video will probably be skipping a lot of
frames.  Plus the ssh is encrypted.  But for the security-minded, it's the
safest way to run an application under X when you don't want to trust the
application too much.

One last thing on creating dummy accounts.  They can be normal shell
accounts, the password should be "*", setup only so your primary account
can ssh into them.  And most importantly you should su into each dummy
account and make sure that it doesn't have acccess to anything sensitive or
personal from your main account (or on your machine in general).

In anycase, this is what I do now.  I have multiple browser buttons on my
desktop to access each mode and e.g. only put my trusted web site bookmarks
in the (1) setup, nominal stuff in (2), and I use (3) when I might be
accessing random or dangerous URLs (or I use another machine entirely for
dangerous URLs).

-Matt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dragonflybsd.org/pipermail/users/attachments/20160815/17f6d390/attachment-0002.html>