Showing posts with label ssh. Show all posts
Showing posts with label ssh. Show all posts

15 July 2013

476: Rehash: using a browser proxy via tunnel, through a router and with reverse ssh

I may have covered this at some point, but if so, I can't find the post.

Here's the situation:
You have a linux computer at work, which is behind a corporate firewall.
You have a router at home which runs an ssh server (e.g. running tomato).
You have a computer at home, which sits behind the router above.
You want to browse from home using the corporate network

In my case it's a little bit different -- I want to make a change to the router my office network (I have my own office) sits behind, and the easiest way to do that is by logging onto that router via http (it's a stock netgear router).

How to:
First, at work, connect to your home router using reverse ssh, so that all traffic on port 19999 on the router gets sent to port 22 on your work computer:
ssh -R 19999:localhost:22 root@myhomerouter

Later, at home, forward all traffic to port 8989 on your home computer to localhost:19999 on your router (which then gets sent to port 22 on your work computer):
ssh -L 8989:localhost:19999 root@192.168.2.1

We've assumed that the router sits on 192.168.2.1 from inside the LAN. Localhost here refers to your home computer, while localhost in the command before that refers to the router.

Then, in a different terminal, open a proxy through port 8989:
 ssh -D 8888 me@localhost -p 8989

Finally, you can now edit your browser/network settings to use a SOCKS proxy on port 8888 like you would with any other proxy.

11 April 2013

385. OTPW -- connecting from an insecure computer using one-time passwords

I got inspired to look into this by this post: http://www.linuxjournal.com/content/configuring-one-time-password-authentication-otpw

The idea of one time passwords  is fairly simple -- even if someone manages to keylog your password (or see you type it in) it will be useless to them, as it can only be used once.

The implementation is also fairly simple: if you divide a password in half, and only let one half be static (the prefix) and the other half come from a pre-agreed list (the suffix), you can have a secure way of changing your password in a practical way.

Let's say that I decide that the static, prefix part should be 'ice' and that we make a pre-agreed list of suffices that we can use to make passwords:
001. box
002. flower
003. icle
004. skating
005. fishing

You should print this list and keep it reasonably safe. Without the prefix it is not useful. Likewise, any keylogger on a compromised computer will find out the prefix, but it will be useless without the suffix list. So keep that it in mind -- make sure that no-one gets hold of both.

You then try to log in via ssh from a remote client, and you get prompted for password 004 -- this means that the password you need to use is iceskating.

In real-world applications the suffixes are random, and not at all related to the prefix. Also, once the list has been generated it is not stored (so you better print it) -- only the hashes or the complete passwords are.

Note that the choice isn't really between OTPW and regular static password -- you can use both, just like you can use SSH with both key and password.



Set up
http://www.linuxjournal.com/content/configuring-one-time-password-authentication-otpw?page=0,2 deals with a number of different use scenarios. I'm only interested in enabling OTPW for remote SSH at this stage i.e. local login is using static passwords by default.

(if you're travelling with a laptop you may consider using OTPW for everything)

You need libpam-otpw. In addition, otpw-bin is useful for generating the suffix/hash list.
sudo apt-get install libpam-otpw otpw-bin

Generate a list of hashes and suffices:
otpw-gen|tee otpw.list

Print the list and delete it afterwards.

You now have a ~/.otpw file filled with hashes.

Create /etc/pam.d/ssh-otpw.
auth sufficient pam_otpw.so session optional pam_otpw.so

and edit /etc/pam.d/sshd -- include the ssh-otpw file immediately before common-auth to set the order of log in methods.
auth required pam_env.so # [1] auth required pam_env.so envfile=/etc/default/locale @include ssh-otpw @include common-auth account required pam_nologin.so @include common-account @include common-session session optional pam_motd.so motd=/run/motd.dynamic noupdate session optional pam_motd.so # [1] session optional pam_mail.so standard noenv # [1] session required pam_limits.so @include common-password
This way, if there's a ~/.otpw file you'll first be prompted for a one-time password. Otherwise that option will be skipped, so users with and without OTPW can co-exist happily.
In /etc/ssh/sshd_config, set
ChallengeResponseAuthentication yes
and make sure that UsePrivilegeSeparation and UsePAM are also set to yes (should be on Debian Wheezy).
sudo service ssh restart

and that's it!

Testing
To test, use a different computer and try to log in. I've got all my local computers set up to use keys to log in, so I had to to
ssh -o PubKeyAuthentication=no me@beryllium
Password 267:
In my list, 267 was given as
dfuF XE+L
so (pretending that my prefix was ice) my password was icedfuFXE+L.
If you answer that challenge wrong, you'll be asked for your static password instead. If you want to keep that secret, then interrupt the connection and retry.

Easy!

Once you start running out of password, run otpw-gen again for a new list.

01 February 2013

329. ECCE, xterm and X forwarding: fixing broken "tail -f on output" in ECCE/'untrusted X11 forwarding' error


The problem
In ECCE when you highlight a running job on a remote server which you've set up with the frontendMachine option (here and here and here) which is a ROCKS 5.4.3/CentOS server and e.g. hit Alt+L or "Run Mgmt"/"Tail -f on Output file" and nothing happens, and when you set ECCE to provide verbose output (add "ECCE_RCOM_LOGMODE true" to ecce/apps/siteconfig/site_runtime) you see the following errors:

X11 connection rejected because of wrong authentication. X connection to localhost:43.0 broken (explicit kill or server shutdown).
and
OpenSSH_4.3p2, OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008 Warning: untrusted X11 forwarding setup failed: xauth key data not generated Warning: No xauth data; using fake authentication data for X11 forwarding.
Obviously there are non-ECCE related situation where you may see these errors too. Doesn't matter -- same solution.


The diagnostics
cat /etc/ssh/sshd_config |grep X11
X11Forwarding yes X11DisplayOffset 10
cat /etc/ssh/ssh_config |grep X11|grep -v ^#
ForwardX11 yes
sudo cat /etc/ssh/sshd_config |grep X11|grep -v ^#
X11Forwarding yes X11DisplayOffset 10

So, why localhost:43? And why isn't it working? From my workstation to the cluster which is connected to the net via the front node, and then from the cluster front to the cluster front's local name.

ssh -X server.external.dns
echo $DISPLAY
localhost:42.0
ssh -X server.local.dns
Warning: untrusted X11 forwarding setup failed: xauth key data not generated Warning: No xauth data; using fake authentication data for X11 forwarding.
echo $DISPLAY
localhost:44.0
yet
ssh -Y server.local.dns

works fine.

The solution:
Simpler than I thought:
I edited ~/.ssh/config on the server, and did
Host server.local.dns Hostname server.local.dns User me ForwardX11 yes ForwardX11Trusted yes

And now it works!

Presumably I could've just edited /etc/ssh_config instead, but it's a multi-user cluster and I'm happier to change things on a user-by-user basis.

16 September 2012

237. Briefly: Packet corrupt during ssh sessions

Whenever I'm using two subnets for my cluster I seems to be having problems with:
Corrupted MAC on input.
Disconnecting: Packet corrupt
It particularly happens when there's a lot of information being passed to the screen. It's a right killer when you're compiling on a remote system. However, while I've been able to get around that by running a GNU Screen session on the remote box it was time to solve it.\


I googled and found:
https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.17/+bug/60764


The subnet I'm having issues with is operation across a switch. One of the computers on the network is defined as the gateway and I tend to have problems when connecting from it to the other computers on the network.
The gateway server has two interfaces, eth0 which is connected to a router which is connected to the outside world, and eth1 which is connected to the local subnet I'm having problems with.

The fix has been as as simple as
sudo apt-get install ethtool
sudo ethtool -K eth1 rx off tx off

I only had to run this on the gateway box and so far I've had no issues. Depending on how you're managing your network interfaces (i.e. wicd, network-manager, /etc/networking/*) you may want to add it to the post-up section of your /etc/network/interfaces:
post-up ethtool -K eth1 rx off tx off

Links to this post:
http://winscp.net/forum/viewtopic.php?t=12469

30 April 2012

126. linux ssh examples: rsync across portforwarded ssh and helping remotely via ssh behind firewalls

Even bog-standard ssh is pretty neat, since there's little that can't be done in the terminal. However, firewalls can be annoying and if you set somebody up with linux you will have to be prepared to support them for years to come -- at least with debian wheezy the odd breakage happen, and people tend to be less forgiving with linux problems than with windows problems.

Anyway.

1. rsync across a server 
A can connect to B, B can connect to C. A can't connect directly to C. B and C can't connect directly to A. B and C can connect to each other either direction. An example is when B is your home router and C sits on your local network, while A has a public IP but sits behind a corporate firewall.

You want to rsync from A to C

On A, do
ssh user_at_B@B_ip_address -L 5555:C_ip_address:22
then in another terminal
rsync -avz  --progress --stats -e "ssh -p 5555" /home/user_a/work user_c@localhost:/home/user_c/Documents

2. Helping someone in the terminal across a server
A and C can't connect to each-other. A and C can both connect to B. B can't connect to A or C. A wants to connect to C to start e.g a screen session to help out. An example is when both users A and C can connect to a lab router from their respective home, but their ISPs are preventing direct ssh access between them.

Setting up reverse ssh, on C, do
autossh -R 19998:localhost:22 user_B@B_ip_address

Connecting from A to C, do
ssh user_B@B_ip_address -L 19999:localhost:19998
then in another terminal
ssh user_C@localhost -p 19999

You can then set up a screen session to both help and teach.
http://verahill.blogspot.com.au/2012/02/debian-testing-wheezy-64-attach-to.html
http://verahill.blogspot.com.au/2012/03/fun-with-gnu-screen-setting-up-screenrc.html

20 April 2012

121. Connection to remote server via an intermediary server

We have three computers: A, B and C

A is our desktop. C is a remote computer we want to connect to. B is a server in the middle.

For various reasons we want to first connect from A to B, then from B to C. A scenario is where C is behind a firewall bridged by B.

A specific scenario is this:
I have a linksys router, e.g. Terbium.internet.com, which manages the network in a lab. There are several computers on the network in the lab behind Terbium: Sulfur, Phosphorous, Oxygen (192.168.1.106) etc.
My home computer is Niobium.

Terbium is a linksys router (W54G) running tomato and you have to log in as root using a keyfile.
Oxygen is a debian box where I have a personal account as user verahill.

The ugly method:
In the same terminal on computer Niobium do
ssh root@terbium.internet.com
ssh verahill@192.168.1.106

This works fine for working remotely on oxygen (192.168.1.106). However, file transfer is a pain

The pretty method:
In one terminal on Niobium, do

ssh root@terbium.internet.com -L 9999:192.168.1.106:22

In another terminal on Niobium, do
ssh verahill@localhost -p 9999

Basically, all traffic to port 9999 on niobium is forwarded to port 22 on Oxygen -- not terbium.

The cool thing? File transfer is a breeze (via sftp using e.g. filezilla)!

It really is that simple

Web tunnel
to browse the internet via a tunnel it's still easier to do
ssh -C -D 9889 root@terbium.internet.com
and set your browser to use a SOCKS proxy -- point it to localhost, port 9889.