Colored Hat Stuff. New post about once a month
November 1, 2008 Leave a comment
It’s easier than you might think.
socks is actually built into openSSH, so its really a trivial matter to setup a local proxy.
$ ssh -D 12345 myuser@remote_ssh_server
will open up the port 12345 on localhost as a socks proxy and all your traffic can be specified to go through the tunnel and out of remote_ssh_server
For firefox 3, go to Edit->Prefrences->Advanced->Network->Settings
and set it to use a Manual Proxy, localhost, port 12345 socksv5
July 21, 2008 Leave a comment
My girlfriend’s company allows her to telecomute, but $AWESOME_COMPUTER_GUY is using XAUTH authentication vpn to rdp to their server, and from there to rdp again to her desktop. Brigette had the good idea to use some sort of version control, but that’s not happening “nobody uses that”. She’s trying to telecomute from her Home box to her hard-to-access work box.
Anyway, here’s my idea to speed up rdp. She may or may not try it, but I thought I’d write it out. It probably will work, and should work no matter what crap is in your way, as long as you have internet egress access you should be able to reverse tunnel out.
Go to the ssh->tunneling tab and enter the remote and Accept Connections from other hosts. Enter your ip information. It should look like the following.
Then click add.
Refer to http://the.earth.li/~sgtatham/putty/0.60/htmldoc/Chapter3.html#using-port-forwarding for more information
You may also want to add compresssion, probably depending on the computer power you have available vs your bandwidth. This is available in the ssh section.
Now connect to your home box. Leave this connection on, as you need it to connect back in. Idiot note: be sure you have rdp enabled properly.
3. From Home, get an rdp client. Now connect to localhost->port you selected above. In our case it was 3389. This is now forwarded to your work box (hopefully).
Now I don’t know if she’ll use this or not, but at least it’s nice to have better (if not great) solutions to try.
November 29, 2007 Leave a comment
<mopey> how do I export a variable in pvm? I add it to my .bashrc or .profile but it ignores it.
<mopey> an environment variable
<mopey> Because I get this error:
<mopey> The value of the $PVM_ROOT environment
<mopey> variable on compute-0-1 is invalid (“”).
<mopey> Use the absolute path to the pvm3/ directory.
<mopey> but if I ssh into compute-0-1, echo $PVM_ROOT it is set correctly
<staynalive_> mopey: I don’t know much about PVM
<staynalive_> but I would check to see if it gets set for non-login sessions
<staynalive_> by doing (in one command) “ssh compute-0-1 printenv”
<staynalive_> Yeah, I just tested it and that’s the issue.
<mopey> good call, it’s not being set for some reason, although it’s “being set” in ~/.bashrc
<mopey> where would I set it, if not bashrc?
<staynalive_> Umm
<mopey> my .profile calls bashrc btw, although that shouldn’t really matter since that’s only on interactive logins, right?
<staynalive_> Yeah
<staynalive_> I think I actully changed a ssh flag to carry the environment variables through to the new machine in a ssh session.
<staynalive_> “PermitUserEnvironment yes”
<mopey> oh. well that’s handy.
<staynalive_> That way if users set something up funky they can carry it to the nodes.
<staynalive_> But the manual warns of some possible security issues…
<mopey> if someone is on my frontend node, it’s only being used on the compute nodes, so it shouldn’t be that big of a deal.
<mopey> since they are basically thin
<mopey> aaah, ssh has env variables all of it’s own…
<mopey> I remember telling you that at one point. I guess I’m losing my marbles
…
<mopey> has anyone ever gotten sshrc to succesfully set ssh environment variables?
<mopey> it *should* be straightforward
<mopey> the sshd man page says: 8. If $HOME/.ssh/rc exists, runs it; else if /etc/ssh/sshrc exists, runs it; otherwise runs xauth. The “rc” files are
<mopey> given the X11 authentication protocol and cookie in standard input.
<mopey> is this not run (when I do ‘ssh compute-0-0 env’) because it is too late in the process?
<mopey> because my $HOME/.ssh/environment _is_ run, and I can set them that way. Except that I want to do it for all users and that seems to be a lame solution.
<mopey> It seems like the command should be executed *after* the rc files are read (it’s step 9)
<mopey> So I wonder why the hell it’s being ignored…
<mopey> staynalive, you said you use “PermitUserEnvironment yes”. So do you just set a $HOME/.ssh/environment for each user?
…
<mopey> haha
<mopey> for those who care, pam overrides my ssh variables for the most part
<mopey> so you can define variables in /etc/security/pam_env.conf
<mopey> god, that took forever to figure out why my /etc/environment variables weren’t getting set over ssh
* Vog-work has quit (“ChatZilla 0.9.79 [Firefox 2.0.0.10/2007111504]”)
<twinprism> thanks for sharing, mopey, I care…
<mopey> weird.
<mopey> :)
<_sera> I don’y
<_sera> sheesh… don’t
<mopey> Normally it probably doesn’t matter I’m sure. Like if you get a bash shell and can actually execute profile/bashrc
<mopey> But if you have a crippled pvm shell or something, it’s way important
<mopey> plus I think pam_env is how PATHs and junk get set on login – at least on ubuntu
<mopey> *gdm/kdm/xdm login
September 2, 2007 Leave a comment
This is the correct way to remove old public keys from your known_hosts file.
There are times when public keys change for legitimate reasons. Like when you get a new operating system installed or something.
In the past, I’ve just edited .ssh/known_hosts and deleted the entries (there is normally at least two, one for the IP and one for the host name). This can be a bit hard because these entries aren’t really labeled clearly.
A better way is to:
ssh -R hostname
ssh -R IP
WebstersProdigy 