Okay, so it is a personal preference, but root shouldn't be able to login via unsecured terminals. ssh is a unsecured terminal until you have authenticated. I turn off AllowRootLogin so that you must login as a normal user and then su to root.
I admit that when I use -X for root that I do not use 'su -' but just su to change to root. That keeps my DISPLAY variable happy. Then there is just an occasional cookie issue, but that is fixed by 'cp ~critch/.Xauthority ~/' and then root has access to the cookie without using xhost to bypass security. ----- "Alex Smith (K4RNT)" <[EMAIL PROTECTED]> wrote: > I like using ssh -X [EMAIL PROTECTED] with a passphrase-protected key > when I'm > remotely connected to a machine as a non-privileged user (with NX > remote > access software). Gets around all the DISPLAY variables and xhost > permissions... :) > > On Mon, Nov 10, 2008 at 11:41 AM, Steven S. Critchfield > <[EMAIL PROTECTED]>wrote: > > > > > Since we haven't had a command of the day lately, and > > the people who didn't know the ssh trick I showed with > > tar a while back, I thought I would throw out a few > > more ssh tricks to help get some creative juices flowing. > > > > It is possible to route local ports on your computer > > threw ssh to a remote machine. This is helpful for all > > those nice embedded devices that come with web gui front > > ends but don't support ssl encryption. Put the appliance > > behind a firewall with a machine running sshd(yes this > > could even be a windows box with cygwin and a sshd running) > > The machine behind the firewall needs to have ssh passed > > through to it. Then you use ssh to connect to that sshd > > and port forward a local port to the remote IP behind the > > firewall at the port it needs. > > > > For instance, at one of our colo facilities, we have a APC > > PDU. As best I can tell, it is not doing ssl over http, but > > supports ssh. Anyways, since this one interface can power > > off our machines that are critical for business, we hide it > > on a private network. In this case, it is on a point to > > point with another machine. > > > > ssh [EMAIL PROTECTED] -L8080:192.168.0.22:80 > > > > That lets me log into remote.machine and I will get a nice > > prompt. Then once the ssh session is established, I can > > point a browser to http://localhost:8080 and I will get > > redirected to the remote machine's route to IP 192.168.0.22 > > and port 80 on it. This lets me use my local webbrowser to > > use the web gui on the other side. > > > > Similarly, you can use -X with ssh to do X11 forwarding. > > Using -X also sets the remote sides DISPLAY environment > > variable so that you can run the X apps on the remote server > > and have them show up locally. This is helpful for running > > some gui admin apps that can't be port forwarded. And for > > many of the web developers around here, you can also use it > > to validate your website using an outside of your current > > network connection. I am sure many of us run linux boxes at > > home. We can ssh -X to our home machine and use the web > > browser there. And that points out that you can hide your > > web browsing habits from work that way as well. > > > > Using the remote browser is nice, but you might find that > > the performance sucks a little due to sending the rendered > > images across the connection instead of the image itself or > > html. In this case, why not fire up the -D option and configure > > your local browser to use the socks proxy in ssh to redirect > > your browsing out the remote machine. > > ssh -D 23456 [EMAIL PROTECTED] > > will produce a proxy at localhost:23456 that will send your > > requests out the remote.machine such that you appear to be from > > remote machine. Also think of that with all the other apps that > > let you use socks proxies as well. I think some IM apps will > > let you do the same. yep, looks like pigeon will connect using > > socks to bypass your local network managers. > > > > While doing all this redirection and such. It is likely that > > you are on a low upstream bandwidth connection if you are > > hitting your home machines. Using -C turns on zlib compression > > and will buy you a little overhead on some of your connections. > > If you are moving files and stuff locally across your lan with > > ssh, try changing the cipher with -c to something less compute > > intense. I seem to find better throughput with -c blowfish than > > the normal ciphers. > > > > I can't think of a good reason for using the -R option right > > now but I assume there was a good one for doing it. -R is the > > reverse of -L. You open a port on the remote machine being sent > > back to your machine. > > > > > > Okay, I think that is enough for this email. > > > > -- > > Steven Critchfield [EMAIL PROTECTED] > > > > > > > > > > -- > " ' With the first link, the chain is forged. The first speech > censured, the > first thought forbidden, the first freedom denied, chains us all > irrevocably.' Those words were uttered by Judge Aaron Satie as wisdom > and > warning... The first time any man's freedom is trodden on we're all > damaged." - Picard, quoting Judge Aaron Satie > - Alex Smith (K4RNT) > - Nashville, Tennessee USA > > -- Steven Critchfield [EMAIL PROTECTED] --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "NLUG" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/nlug-talk?hl=en -~----------~----~----~----~------~----~------~--~---
