<div dir="ltr">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.<div><br></div><div>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.</div><div><br></div><div>* 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.</div><div><br></div><div>* Some people use easily guessable passwords, or password with 8 or fewer characters.  8 characters doesn't cut it any more.</div><div><br></div><div>* 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.</div><div><br></div><div>* 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.</div><div><br></div><div>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.</div><div><br></div><div><br></div><div>BROWSER SECURITY</div><div><br></div><div>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:</div><div><br></div><div>(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.</div><div><br></div><div>(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.</div><div><br></div><div>(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"'</div><div><br></div><div>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.</div><div><br></div><div>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').</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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).</div><div><br></div><div>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).</div><div><br></div><div><div><div>-Matt</div></div></div></div>