A Problem
To get natty technical questions answered, sometimes you hafta go to the source and drop a line to the mavens on IRC (Internet Relay Chat). But IRC uses a specific port (6667) denied by the average corporate firewall. Unfortunately, I could not get irssi functioning through my http proxy at work. What to do? Well..secure SSH tunneling and port forwarding to the rescue!
ssh -p 443 -L 1234:irc.freenode.net:6667 user@homemachine
But what the heck is all that stuff? I will explain.
The Solution
Like most companies, my company allows port 443 traffic through their firewall. I decided to use this open access to create a secure tunnel from my workstation in the office to a machine in my home network that has a running SSH server. I then use a very nice feature of SSH to forward traffic through the tunnel to my machine at home and onto a specific server out in the internet. This *should* be as easy as 1 - 2 - 3 (shown below), though to me, it's a bit mindbending. Read on..
1 - Configure the Home Router/Firewall
In order to get the above solution working, I needed to configure my home firewall to forward requests for port 443 to the SSH server (port 22) at home. Most home routers/firewalls have the ability to setup this hardware-based port forwarding.
2 - SSH Tunnel and Forward
After making sure that the port forwarding described in Step 1 is setup, I then use SSH on my machine at work to:
1) create a secure tunnel to my home machine over port 443 (ssh -p 443 user@homemachine)
2) create a listener on my local machine on port 1234 (-L 1234:)
3) forward requests to a specific IRC server on a specific port via that secure tunnel. In this case, port 6667 on irc.freenode.net , like so (:irc.freenode.net:6667)
The whole shebang is efficiently handled with that one ssh command string:
ssh -p 443 -L 1234:irc.freenode.net:6667 user@homemachine
On the host at work
After making sure Step 1 was completed, I received a "Password:" prompt after hitting "enter" on the above SSH command line:
$ ssh -p 443 -L 1234:irc.freenode.net:6667 user@homemachine
Password:
Last login: Wed Aug 25 11:20:09 2010 from 26.176.213.71
Now that I'm properly authenticated, I checked to see that the local machine is listening on port 1234. I did this by opening a second command prompt on the machine at work and looking at the output of "netstat -na":
$ netstat -na grep LISTEN
..
TCP 127.0.0.1:1234 0.0.0.0:0 LISTENING
TCP 127.0.0.1:5152 0.0.0.0:0 LISTENING
TCP 127.0.0.1:8198 0.0.0.0:0 LISTENING
SSH has opened that local port and will forward traffic bound for it to the remote SSH server. But I'm not done yet. IRSSI needs to point to that local port in order to use my home machine to connect to the IRC server. Much like a frog uses one lily pad to hop to another.
3 - IRSSI config change
To point IRSSI to utilize that SSH tunnel, I made two minor tweaks to IRSSI's configuration: proxy_address and proxy_port via the /SET command:
[(status)] /set proxy_address 127.0.0.1
[(status)] /set proxy_port 1234
[(status)] /set use_proxy ON
[(status)] /set
15:33 [proxy]
15:33 proxy_address = 127.0.0.1
15:33 [proxy]
15:33 proxy_port = 1234
15:33 [proxy]
15:33 use_proxy = ON
Note the localhost IP address in "proxy_address" and, of course, the appropriate port that I've opened.
With these tweaks in place and the secure tunnel created, I can then startup IRSSI and successfully connect to the IRC node via the local port, 1234:
11:35 -!- Irssi: Looking up irc.freenode.net
11:35 -!- Irssi: Connecting to irc.freenode.net [127.0.0.1] port 6667
11:35 -!- Irssi: Connection to irc.freenode.net established
11:35 !gibson.freenode.net *** Looking up your hostname...
11:35 !gibson.freenode.net *** Checking Ident
11:35 !gibson.freenode.net *** Found your hostname
11:35 !gibson.freenode.net *** No Ident response
11:35 -!- You have not registered
11:35 -!- Welcome to the freenode Internet Relay Chat Network user
11:35 -!- Your host is gibson.freenode.net[213.179.58.83/6667], running version ircd-seven-1.0.0
11:35 -!- This server was created Sat Jan 30 2010 at 01:13:47 CET
11:35 -!- Highest connection count: 6923 (6922 clients) (3140303 connections received)
11:35 -!- - gibson.freenode.net Message of the Day -
11:35 -!- - Welcome to gibson.freenode.net in Norway, EU! Thanks to
11:35 -!- - SSC Networks (www.ssc.no) for sponsoring this server!
Yahoo!
Conclusion
In the fashion of port forwarding, SSH works its magic to create a listener on the local machine, forward the packets destined for it through an SSH tunnel to my home server and onto somewhere else. In my case, I use my machine at home to forward my IRC requests onto irc.freenode.net. Very cool! Don't forget this same port forwarding feature of SSH can be applied to other TCP applications, such as VLC running on that same remote machine:
ssh -p 443 -L 1234:localhost:5900 user@homemachine
Have a good one,
TAG
Reference
http://www.techanswerguy.com/2006/09/irssi-chat-client.html
http://blag.andrewyates.net/2008/06/17/dynamic-port-forwarding-with-ssh-ssh-d/
Showing posts with label ssh. Show all posts
Showing posts with label ssh. Show all posts
Wednesday, August 25, 2010
Monday, August 02, 2010
drobo fs install, review
If all computer technology was like the Drobo, there would be less people complaining that their tech is difficult to use or doesn't work. I've had my Drobo FS for three days, but man, I love the thing. It is such a pleasure to not have to worry about RAID arcana just to have your systems safely backed up.
Got It!
I bought the Drobo FS from Amazon (about $694 with free shipping) and set it up between yesterday and today. I installed the Drobo Dashboard, the utility program for the Drobo, on my MacBook Pro, rebooted the Mac, popped a combination of five 250GB and 500GB drives in, hooked up the power and the ethernet cables and fired it up. Drobo Dashboard saw the unit as it sat attached to my router.
The Basics
Dashboard asked me if I wanted to upgrade the firmware..so I did. There was a small hiccup with Dashboard not seeing the Drobo after doing the firmware, so I had to hard power it down. But second time around, the firmware update worked. Dashboard then asked me if I wanted to upgrade the Dashboard software, which I did. I restarted the Mac. I then went into Advanced Settings -> Tools and configured email alerts to send me an email if Drobo becomes too full or has problems.
Create Shares
Back in Dashboard, I created a couple of shares, one as backup for my main Linux video editing workstation and the other for my MacBook and TimeMachine. I setup my MacBook to use 500GB of storage as a TimeMachine backup. The TimeMachine hook up worked like a charm and started backing up.
Stress Test Drobo!
I decided to test it hard out of the box and ran that TimeMachine backup from the mac (connected wirelessly) coincident with a big copy from my Linux video editing box. On my Linux box, I mounted the Drobo via SMB/CIFS and copied over my 460GB archive. The backup of the Linux archive took about 3.5 hours at about 25MiB/s over wired ethernet. Not bad for over gigE and with contention from the Time Machine backup.
The next morning, I got tired of waiting for the wireless TM backup of 130GB to finish, so I stopped the TM backup and then hooked up the Mac to a hard wired ethernet connection. Still took about five hours to copy over the remaining 80GB.
Update
I recently created a 760GB archive of my video workstation using fsarchiver. Copying the one file from my workstation to the Drobo took about 10 hours (8pm to 6am). That was with contention from a 40GB Time Machine backup that was running at the same time.
***end update***
Drobo Apps
Today I installed a few Drobo Apps (apache/droboutils/dropbear). DroboUtils is an easier way to manage Drobo Apps and as a prerequisite, it requires Apache to be installed. I used Apache for another function, setup of my personal website. I haven't cutover to using the apache web server as my main webserver yet because I need to tweak the apache config to hide some of the directory structures.
There is no telnet client for DroboApps, but DropBear is the SSH server for the Drobo. After installing, it was pretty cool to be able to logon to the device.
Summary
All-in-all, the process was super smooth and the device is everything I hoped for. With the ability to expand drive space at will, I shouldn't outgrow the FS very soon. I'm also looking forward to using more Drobo Apps and letting that be my server, instead of my XP VM on my Mac!
Long live Drobo!
Some Pics of the Process
drobo formatting my stack of drives
updating the firmware on the drobo
drobo temporarily loses its mind during firmware update
don't touch drobo while firmware is being updated!
drobo starting up after successful firmware update
drobo successfully updates its firmware
drobo dashboard download for update
time machine backup using drobo!
25MiBps (Mebibytes per second) network copy speed (with two backups to Drobo running..Time Machine and a backup of a 438GB archive)
Got It!
I bought the Drobo FS from Amazon (about $694 with free shipping) and set it up between yesterday and today. I installed the Drobo Dashboard, the utility program for the Drobo, on my MacBook Pro, rebooted the Mac, popped a combination of five 250GB and 500GB drives in, hooked up the power and the ethernet cables and fired it up. Drobo Dashboard saw the unit as it sat attached to my router.
The Basics
Dashboard asked me if I wanted to upgrade the firmware..so I did. There was a small hiccup with Dashboard not seeing the Drobo after doing the firmware, so I had to hard power it down. But second time around, the firmware update worked. Dashboard then asked me if I wanted to upgrade the Dashboard software, which I did. I restarted the Mac. I then went into Advanced Settings -> Tools and configured email alerts to send me an email if Drobo becomes too full or has problems.
Create Shares
Back in Dashboard, I created a couple of shares, one as backup for my main Linux video editing workstation and the other for my MacBook and TimeMachine. I setup my MacBook to use 500GB of storage as a TimeMachine backup. The TimeMachine hook up worked like a charm and started backing up.
Stress Test Drobo!
I decided to test it hard out of the box and ran that TimeMachine backup from the mac (connected wirelessly) coincident with a big copy from my Linux video editing box. On my Linux box, I mounted the Drobo via SMB/CIFS and copied over my 460GB archive. The backup of the Linux archive took about 3.5 hours at about 25MiB/s over wired ethernet. Not bad for over gigE and with contention from the Time Machine backup.
The next morning, I got tired of waiting for the wireless TM backup of 130GB to finish, so I stopped the TM backup and then hooked up the Mac to a hard wired ethernet connection. Still took about five hours to copy over the remaining 80GB.
Update
I recently created a 760GB archive of my video workstation using fsarchiver. Copying the one file from my workstation to the Drobo took about 10 hours (8pm to 6am). That was with contention from a 40GB Time Machine backup that was running at the same time.
***end update***
Drobo Apps
Today I installed a few Drobo Apps (apache/droboutils/dropbear). DroboUtils is an easier way to manage Drobo Apps and as a prerequisite, it requires Apache to be installed. I used Apache for another function, setup of my personal website. I haven't cutover to using the apache web server as my main webserver yet because I need to tweak the apache config to hide some of the directory structures.
There is no telnet client for DroboApps, but DropBear is the SSH server for the Drobo. After installing, it was pretty cool to be able to logon to the device.
syslog entries
Sep 13 17:40:23 MAC sudo[57338]: root : TTY=unknown ; PWD=/ ; USER=newuser ; COMMAND=/sbin/mount_afp afp://user:pass@192.168.1.87/DroboApps /Volumes/DroboFS/0db102670141/1/DroboApps
Sep 13 17:40:24 MAC kernel[0]: AFP_VFS afpfs_mount: /Volumes/DroboFS/0db112312341/1/DroboApps, pid 57338
Sep 13 17:44:09 MAC /System/Library/CoreServices/backupd[57359]: Backup requested by user
Sep 13 17:44:09 MAC /System/Library/CoreServices/backupd[57359]: Starting standard backup
Sep 13 17:44:24 MAC kernel[0]: AFP_VFS afpfs_mount: /Volumes/MacTimeMachine, pid 57360
Sep 13 17:44:24 MAC /System/Library/CoreServices/backupd[57359]: Mounted network destination using URL: afp://user@Drobo.local/MacTimeMachine
Sep 13 17:44:24 MAC /System/Library/CoreServices/backupd[57359]: Backup destination mounted at path: /Volumes/MacTimeMachine
Sep 13 17:44:30 MAC /System/Library/CoreServices/backupd[57359]: Disk image /Volumes/MacTimeMachine/MAC_0017f2ca5f8b.sparsebundle mounted at: /Volumes/Backup of MAC
Sep 13 17:44:30 MAC /System/Library/CoreServices/backupd[57359]: Backing up to: /Volumes/Backup of MAC/Backups.backupdb
Summary
All-in-all, the process was super smooth and the device is everything I hoped for. With the ability to expand drive space at will, I shouldn't outgrow the FS very soon. I'm also looking forward to using more Drobo Apps and letting that be my server, instead of my XP VM on my Mac!
Long live Drobo!
Some Pics of the Process
drobo formatting my stack of drives
updating the firmware on the drobo
drobo temporarily loses its mind during firmware update
don't touch drobo while firmware is being updated!
drobo starting up after successful firmware update
drobo successfully updates its firmware
drobo dashboard download for update
time machine backup using drobo!
25MiBps (Mebibytes per second) network copy speed (with two backups to Drobo running..Time Machine and a backup of a 438GB archive)
Update 2010/08/14
Drobo shell commands
Found some good links on cross-compiling packages for the Drobo:
Ethtool specific links
Drobo Forums
Thursday, July 01, 2010
X server in cygwin
Start an X server locally
Install Cygwin
http://x.cygwin.com/docs/ug/setup.html
Identify X Displays
Start by identifying your X displays. Xrandr is good for this:
$ xrandr
Screen 0: minimum 2560 x 1024, current 2560 x 1024, maximum 2560 x 1024
default connected 2560x1024+0+0 0mm x 0mm
2560x1024 50.0*
For cygwin, start X:
$ startxwin &
[1] 3528
Make sure you have a DISPLAY environment variable set locally:
$ export DISPLAY=:0.0
To verify, echo it out:
$ echo $DISPLAY
:0.0
This is important because a properly working X server will export the DISPLAY environment variable to the remote server.
You can discover the process id of the X server by looking at the lock file:
$ ll /tmp/.X0-lock
-r--r--r-- 1 root root 11 Sep 13 11:26 /tmp/.X0-lock
$ cat /tmp/.X0-lock
5647
$ ps -ef | grep 5647
root 5647 5645 5 Sep13 tty7 1-00:16:30 /usr/bin/Xorg :0 -br -verbose -auth /var/run/gdm/auth-for-gdm-SWEiqo/database -nolisten tcp
X servers will listen on port 6000 by default:
$ netstat -na | grep LISTENING
TCP 0.0.0.0:6000 0.0.0.0:0 LISTENING
The first digit of the port will change based on the display number (0, 1, 2 etc). So the default port of 6000 may change to 6001 if you've started an X server on display 1:
$ startxwin -- :1
$ netstat -na | grep LISTENING
TCP 0.0.0.0:6001 0.0.0.0:0 LISTENING
Test by opening an xterm locally:
$ /usr/X11R6/bin xterm -display 127.0.0.1:0.0 -ls
Running remote X commands
Once I've verified that my X server is running properly, I will test running an X program remotely. In this example, I needed to kick off a script on my Mac that depends on X. My Macbook Pro (downstairs) is remote to my main Linux box which is upstairs. I needed to startup an X session on the remote Mac.
From my local Linux box, I start a secure X session on my remote Mac:
$ ssh -Y sodo@192.168.110.177
Password:
Warning: No xauth data; using fake authentication data for X11 forwarding.
Last login: Fri Sep 30 14:23:09 2011 from computer
Have a lot of fun...
sodo@remote:~>
This sets up a secure X windows communication, the DISPLAY environment variable, the X authentication and starts up the local X terminal application logged on to the remote server.
I verify that the Mac's X server has a DISPLAY environment variable set. This variable was properly forwarded by my Linux box and translated by the Mac:
sodo@remote:~> echo $DISPLAY
localhost:10.0
Once these settings were confirmed, I started an xterm
sodo@remote:~> xterm
Note that the above steps could have been accomplished with a one liner:
$ ssh -Y sodo@192.168.110.177 xterm
Cool.
Troubleshooting
1) I first got this error:
Warning: No xauth data; using fake authentication data for x11 forwarding
From this thread:
http://www.cygwin.com/ml/cygwin-xfree/2004-10/msg00236.html
I choose to ignore!
2) This is very important. The remote server's SSH daemon must be configured to forward X11 requests. From http://x.cygwin.com/docs/ug/using-remote-apps.html#using-remote-apps-ssh:
Note: By default, the OpenSSH server does not allow forwarded X connections. This must be configured on the remote host by adding X11Forwarding yes to the sshd_config configuration file. The OpenSSH server must be restarted or SIGHUP'ed to re-read the configuration file after it is changed.
Note: The OpenSSH server requires the xauth command to be available to forward X connections. Consequently, it must be installed on the remote host.
3) .Xauthority does not exist
$ ssh -X liveuser@192.168.x.x
liveuser@192.168.x.x's password:
Last login: Thu Oct 4 16:59:48 2012 from 192.168.x.y
/usr/bin/xauth: file /home/liveuser/.Xauthority does not exist
Well..create it then, fah Gawd's sake!
[liveuser@localhost ~]$ touch .Xauthority
[liveuser@localhost ~]$ chmod 755 .Xauthority
[liveuser@localhost ~]$ exit
logout
Connection to 192.168.x.x closed.
$ ssh -X liveuser@192.168.x.x
liveuser@192.168.x.x's password:
Last login: Thu Oct 4 17:02:13 2012 from 192.168.x.y
[liveuser@localhost ~]$ cat .Xauthority
localhost.localdomain10MIT-MAGIC-COOKIE-165??
About .Xauthority
http://en.wikipedia.org/wiki/X_Window_authorization#Cookie-based_access
ReferenceUsing Cygwin/X
Cygwin X FAQ
Using Cygwin/XUsing Cygwin/X
http://www.int.gu.edu.au/~anthony/info/X/Display.needs
Install Cygwin
http://x.cygwin.com/docs/ug/setup.html
Identify X Displays
Start by identifying your X displays. Xrandr is good for this:
$ xrandr
Screen 0: minimum 2560 x 1024, current 2560 x 1024, maximum 2560 x 1024
default connected 2560x1024+0+0 0mm x 0mm
2560x1024 50.0*
$ startxwin &
[1] 3528
Make sure you have a DISPLAY environment variable set locally:
$ export DISPLAY=:0.0
To verify, echo it out:
$ echo $DISPLAY
:0.0
This is important because a properly working X server will export the DISPLAY environment variable to the remote server.
$ ll /tmp/.X0-lock
-r--r--r-- 1 root root 11 Sep 13 11:26 /tmp/.X0-lock
$ cat /tmp/.X0-lock
5647
$ ps -ef | grep 5647
root 5647 5645 5 Sep13 tty7 1-00:16:30 /usr/bin/Xorg :0 -br -verbose -auth /var/run/gdm/auth-for-gdm-SWEiqo/database -nolisten tcp
X servers will listen on port 6000 by default:
$ netstat -na | grep LISTENING
TCP 0.0.0.0:6000 0.0.0.0:0 LISTENING
The first digit of the port will change based on the display number (0, 1, 2 etc). So the default port of 6000 may change to 6001 if you've started an X server on display 1:
$ startxwin -- :1
$ netstat -na | grep LISTENING
TCP 0.0.0.0:6001 0.0.0.0:0 LISTENING
Test by opening an xterm locally:
$ /usr/X11R6/bin xterm -display 127.0.0.1:0.0 -ls
Running remote X commands
Once I've verified that my X server is running properly, I will test running an X program remotely. In this example, I needed to kick off a script on my Mac that depends on X. My Macbook Pro (downstairs) is remote to my main Linux box which is upstairs. I needed to startup an X session on the remote Mac.
From my local Linux box, I start a secure X session on my remote Mac:
$ ssh -Y sodo@192.168.110.177
Password:
Warning: No xauth data; using fake authentication data for X11 forwarding.
Last login: Fri Sep 30 14:23:09 2011 from computer
Have a lot of fun...
sodo@remote:~>
This sets up a secure X windows communication, the DISPLAY environment variable, the X authentication and starts up the local X terminal application logged on to the remote server.
I verify that the Mac's X server has a DISPLAY environment variable set. This variable was properly forwarded by my Linux box and translated by the Mac:
sodo@remote:~> echo $DISPLAY
localhost:10.0
Once these settings were confirmed, I started an xterm
sodo@remote:~> xterm
Note that the above steps could have been accomplished with a one liner:
$ ssh -Y sodo@192.168.110.177 xterm
Cool.
Troubleshooting
1) I first got this error:
Warning: No xauth data; using fake authentication data for x11 forwarding
http://www.cygwin.com/ml/cygwin-xfree/2004-10/msg00236.html
I choose to ignore!
2) This is very important. The remote server's SSH daemon must be configured to forward X11 requests. From http://x.cygwin.com/docs/ug/using-remote-apps.html#using-remote-apps-ssh:
Note: By default, the OpenSSH server does not allow forwarded X connections. This must be configured on the remote host by adding X11Forwarding yes to the sshd_config configuration file. The OpenSSH server must be restarted or SIGHUP'ed to re-read the configuration file after it is changed.
Note: The OpenSSH server requires the xauth command to be available to forward X connections. Consequently, it must be installed on the remote host.
3) .Xauthority does not exist
$ ssh -X liveuser@192.168.x.x
liveuser@192.168.x.x's password:
Last login: Thu Oct 4 16:59:48 2012 from 192.168.x.y
/usr/bin/xauth: file /home/liveuser/.Xauthority does not exist
Well..create it then, fah Gawd's sake!
[liveuser@localhost ~]$ touch .Xauthority
[liveuser@localhost ~]$ chmod 755 .Xauthority
[liveuser@localhost ~]$ exit
logout
Connection to 192.168.x.x closed.
$ ssh -X liveuser@192.168.x.x
liveuser@192.168.x.x's password:
Last login: Thu Oct 4 17:02:13 2012 from 192.168.x.y
[liveuser@localhost ~]$ cat .Xauthority
localhost.localdomain10MIT-MAGIC-COOKIE-165??
About .Xauthority
http://en.wikipedia.org/wiki/X_Window_authorization#Cookie-based_access
ReferenceUsing Cygwin/X
Cygwin X FAQ
Using Cygwin/XUsing Cygwin/X
http://www.int.gu.edu.au/~anthony/info/X/Display.needs
Tuesday, December 16, 2008
tunneling ssh through proxy server
I needed to create a secure SSH connection to my Fedora box at home. However, I am behind a proxy server at work and SSH doesn't have switches that allow it to get through a proxy. So in combination with ntlmaps and the corkscrew program, Open Source helped me do this in a quick and easy way.
Here's a sample .ssh/config file that works for corkscrew:
sodo@linux-z6tw:~> cat .ssh/config
ProxyCommand /usr/local/bin/corkscrew 0.0.0.0 5865 %h %p
Note the 0.0.0.0. This is because ntlmaps is listening on all ports:
sodo@linux-z6tw:~> NTLM authorization Proxy Server v0.9.9.0.1
Copyright (C) 2001-2004 by Dmitry Rozmanov and others.
Now listening at linux-z6tw on port 5865
sodo@linux-z6tw:~> netstat -na | grep "LISTEN "
tcp 0 0 0.0.0.0:5865 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.1:631 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN
Here is the corkscrew home page:
http://www.agroman.net/corkscrew/
Here is a great instruction set for corkscrew:
http://www.mtu.net/~engstrom/ssh-proxy.php
and here is a second link, just in case:
http://lindesk.com/2007/04/using-ssh-over-a-proxy
Now I am able to securely connect and grab files from my home PC. Yeah!
TAG
Here's a sample .ssh/config file that works for corkscrew:
sodo@linux-z6tw:~> cat .ssh/config
ProxyCommand /usr/local/bin/corkscrew 0.0.0.0 5865 %h %p
Note the 0.0.0.0. This is because ntlmaps is listening on all ports:
sodo@linux-z6tw:~> NTLM authorization Proxy Server v0.9.9.0.1
Copyright (C) 2001-2004 by Dmitry Rozmanov and others.
Now listening at linux-z6tw on port 5865
sodo@linux-z6tw:~> netstat -na | grep "LISTEN "
tcp 0 0 0.0.0.0:5865 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.1:631 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN
Here is the corkscrew home page:
http://www.agroman.net/corkscrew/
Here is a great instruction set for corkscrew:
http://www.mtu.net/~engstrom/ssh-proxy.php
and here is a second link, just in case:
http://lindesk.com/2007/04/using-ssh-over-a-proxy
Now I am able to securely connect and grab files from my home PC. Yeah!
TAG
Wednesday, January 30, 2008
couldn't set file permissions in Cygwin
Here's a little tidbit that might help someone. I was configuring my public and private keys to allow secure SSH communications between my workstation and a server (see /2007/08/eliminating-need-to-enter-your-password.html for more details). The workstation is an XP box running Cygwin and the server is a Linux variant. When I went to test ssh, I got the following error in Cygwin from the XP box that denied access to the private key:
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
WARNING: UNPROTECTED PRIVATE KEY FILE! @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0644 for '/cygdrive/h/.ssh/id_rsa' are too open.
It is recommended that your private key files are NOT accessible by others.
This private key will be ignored.
bad permissions: ignore key: /cygdrive/h/.ssh/id_rsa
Password:
Woops. I guess that's my fault. Looking at the file permissions, I see that id_rsa perms are too loose:
bash-2.02$ ls -l id_rsa
-rw-r--r-- 1 28235 everyone 1675 Jan 30 15:33 id_rsa
I issued the following chmod command:
bash-2.02$ chmod 600 id_rsa
bash-2.02$ ls -l id_rsa
-rw-r--r-- 1 28235 everyone 1675 Jan 30 15:33 id_rsa
But the permissions stayed the same. What gives? Why aren't the permissions changing?
Apparently, Cygwin has two ways to deal with file permissions. Here's the explanation:
http://www.iu.hio.no/cfengine/docs/cfengine-NT/node24.html
The short answer, though, is that I was able to solve my problem by setting this environment variable in /Cygnus/cygwin-b20/cygnus.bat:
set CYGWIN=ntea
Once I set that environment variable in the batch script and restarted a new Cygwin shell, I was able to set the permissions correctly:
bash-2.02$ chmod 600 id_rsa
bash-2.02$ ls -l id_rsa
-rw------- 1 28235 everyone 1675 Jan 30 15:33 id_rsa
Update 2/8/2008
I also got bollucksed with id_rsa permissions if my user's NT permissions on the file were not Full Control. So watch out for that as well.
Live and learn!
sodo
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
WARNING: UNPROTECTED PRIVATE KEY FILE! @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0644 for '/cygdrive/h/.ssh/id_rsa' are too open.
It is recommended that your private key files are NOT accessible by others.
This private key will be ignored.
bad permissions: ignore key: /cygdrive/h/.ssh/id_rsa
Password:
Woops. I guess that's my fault. Looking at the file permissions, I see that id_rsa perms are too loose:
bash-2.02$ ls -l id_rsa
-rw-r--r-- 1 28235 everyone 1675 Jan 30 15:33 id_rsa
I issued the following chmod command:
bash-2.02$ chmod 600 id_rsa
bash-2.02$ ls -l id_rsa
-rw-r--r-- 1 28235 everyone 1675 Jan 30 15:33 id_rsa
But the permissions stayed the same. What gives? Why aren't the permissions changing?
Apparently, Cygwin has two ways to deal with file permissions. Here's the explanation:
http://www.iu.hio.no/cfengine/docs/cfengine-NT/node24.html
The short answer, though, is that I was able to solve my problem by setting this environment variable in /Cygnus/cygwin-b20/cygnus.bat:
set CYGWIN=ntea
Once I set that environment variable in the batch script and restarted a new Cygwin shell, I was able to set the permissions correctly:
bash-2.02$ chmod 600 id_rsa
bash-2.02$ ls -l id_rsa
-rw------- 1 28235 everyone 1675 Jan 30 15:33 id_rsa
Update 2/8/2008
I also got bollucksed with id_rsa permissions if my user's NT permissions on the file were not Full Control. So watch out for that as well.
Live and learn!
sodo
Tuesday, August 14, 2007
eliminating the need to enter your password via SSH or SCP
Everybody and their mother who is a Unix or Windows admin writes shell scripts to perform mundane but necessary work. This work is usually accomplished via SSH, as it is a secure method to transfer information between servers. This is especially true on Unix system, where ssh and scp (Secure Copy) are the hammer and screwdriver of a Unix admins' toolset.
SSH and SCP are great, but one of the pains of using these programs is the constant need to type in a password to logon to different servers. Wouldn't it be nice to not have to enter a password everytime you logged onto a server or had a script run? As well, wouldn't it be even better to have those processes still be secure? Of course! So in order to free your life of passwords, I will now show you pubkey authentication.
In the interest of full disclosure, I got a good bit of the information for this post from Security Focus, but I felt that the way they organized the details was a bit confusing. Hence, I've reworked their original example to something a more understandable. Here is the link to that original article:
http://www.securityfocus.com/infocus/1810
Added 3/1/2008
For a more general understanding of how SSH works with public key encryption, read the following article:
http://www.securityfocus.com/infocus/1806
In order for pubkey authentication to work, you will need to create a public key on your source machine and setup an authorized_keys file on the destination server. The source machine will be the server where you are logging in FROM. The destination server is where you are logging in TO. For instance, I like to run a script on my Fedora desktop that gathers network information FROM my RHEL3 server. So my source is the Fedora desktop and the destination is my RHEL3 server.
Here's the picture:
There are four steps to setting up pubkey authentication:
1. On the source, create an Identity (a public key)
2. Copy the public key from the source to the destination
3. On the destination, login and create a .ssh directory (if necessary)
4. On the destination, add the public key to authorized_keys file
So let's begin.
1. On the source machine, create an Identity (a public key)
a. Type ssh-keygen -t rsa as below. You can choose to enter a passphrase or not:
FedoraDesktop$ ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/cacasodo/.ssh/id_rsa):
Enter passphrase (empty for no passphrase): (enter passphrase)
Enter same passphrase again: (enter passphrase)
Your identification has been saved in /home/cacasodo/.ssh/id_rsa.
Your public key has been saved in /home/cacasodo/.ssh/id_rsa.pub.
The key fingerprint is:
74:9b:69:24:4a:44:3f:a4:be:46:23:47:19:f7:dc cacasodo@FedoraDesktop
b. Verify that one public (*.pub) and one private file exists by changing to your users's .ssh directory and listing out the files:
FedoraDesktop$ cd $HOME/.ssh
FedoraDesktop$ ls -l
-rw------- 1 cacasodo cacasodo 883 Jan 21 11:52 id_rsa
-rw-r--r-- 1 cacasodo cacasodo 223 Jan 21 11:52 id_rsa.pub
c. Finally, check the contents of both files:
FedoraDesktop$ cat id_rsa
-----BEGIN RSA PRIVATE KEY----- jK2TIwbHtE7GoP/Za3NTZJm2Ozviz8+PHPIEyyt9/kzT0+yo3KmgsstlqwIBIwKB XdBh42izEWsWpXf9t4So0upV1DEcjq8CQQDEKGAzNdgzOoIozE3Z3thIjrmkimXM J/Y3xQJBAMEqZ6syYX/+uRt+any1LADRebCq6UA076Sv1dmQ5HMfPbPuU9d3yOqV j0Fn2H68bX8KkGBzGhhuLmbrgRqr3+SPM/frUj3UyYxns5rnGspRkGB3AkALCbzH 9EAV8Uxn+Jhe5cgAC/hTPPdiwTJD7MpkNCpPuKRwrohytmNAmtIpKipAf0LS61np MIICWgIBAAKBgQCc+1oixZ/g84gpZH0NeI+CvVoY5O0FOCSpFCbhUGJigQ6VeKI5 gpOlDztpJ1Rc+KmfZ2qMaftwwnLmefhk1wPcvfZvvLjfdmHY5/LFgDujLuL2Pv+F 7tBjlyX9e9JfXZau2o8uhBkMbb3ZqYlbUuuoCAnUtL5uZUiiHM0BAtnGAd6epAYE gBHw1xnqsy+mzbuWdLEVF7crlUSsctwGapb6/SEQgEXFm0RITQ3jCY808NjRS3hW Z+uCCO8GGUsn2bZpcGXa5vZzACvZL8epJoMgQ4D0T50rAkEA0AvK4PsMF02Rzi4E mXgzd1yCa030LYR/AkApG1KT//9gju6QCXlWL6ckZg/QoyglW5myHmfPR8tbz+54
/lj06BtBA9iag5+x+caV7qKth1NPBbbUF8Sbs/WI5NYweNoG8dNY2e0JRzLamAUk
59ssjBG/a4ZXNn32n78DO0i6zVV5vwf8rv2sf
-----END RSA PRIVATE KEY-----
FedoraDesktop$ cat id_rsa.pub
ssh-rsa aIsWf4POIKWR9DXiPgr1aGOTtBTgkqRQm4VBiYoEOlXiiOYKTpQ87aSd
B3NzaC1yc2EAAAABIwAAAcMJy5nn4ZNcD3L32b7y433Zh2IEAnPtAAAAUXPipn
2dqjGn7OfyxYA7oy7i9j7/hYytkyMGx7ROxqD/2WtzU2SZtjs74s/PjxzyBMsr ff5M09PsqNypoLLLZas= cacasodo@FedoraDesktop
2. Copy the public key from the source to the destination
a. This one is fairly easy. We'll go ahead and scp the public key file from the source to the destination as below:
FedoraDesktop$ cd $HOME/.ssh
FedoraDesktop$ scp id_rsa.pub rhel3server:id_rsa_FedoraDesktop.pub
cacasodo@rhel3server's password: (enter password)
The scp command above copies the public key to the destination server with a new filename, id_rsa_FedoraDesktop.pub
3. On the destination, login and create a .ssh directory (if necessary)
a. Login via ssh
FedoraDesktop$ ssh rhel3server
cacasodo@rhel3server's password: (enter password)
b. If it does not exist, follow the commands below to make a .ssh directory. Oh, don't forget the "." in front of the ssh!
rhel3server$ mkdir .ssh
rhel3server$ chmod 700 .ssh
rhel3server$ cd .ssh
4. On the destination, add the public key to authorized_keys file
a. We will use the concatenate (>>) redirector to add our source machine's public key to the authorized_keys file on the destination server.
rhel3server$ cat ../id_rsa_FedoraDesktop.pub >> authorized_keys
b. Let's verify the file:
rhel3server$ cat authorized_keys
ssh-rsa n7OfyxYA7oy7i9j7/hYytkyMGx7ROxqD/2WtzU2SZtjs74s/PjxzyBMsr 3NzaC1yc2EAAAABIwAAAcMJy5nn4ZNcD3L32b7y433Zh2IEAnPt f4POIKWR9DXiPgr1aGOTtBTgkqRQm4VBiYoEOlXiiOYKTpQ87aSdUXPipn
M09PsqNypoLLLZas= cacasodo@FedoraDesktop
c. And make sure to lock down the file with tighter permissions:
rhel3server$ chmod 600 authorized_keys
d. OK! So now, the big test is to try and login from your source server to the destination server. You should no longer need to enter a password!
FedoraDesktop$ ssh rhel3server
rhel3server$
SSH and SCP are great, but one of the pains of using these programs is the constant need to type in a password to logon to different servers. Wouldn't it be nice to not have to enter a password everytime you logged onto a server or had a script run? As well, wouldn't it be even better to have those processes still be secure? Of course! So in order to free your life of passwords, I will now show you pubkey authentication.
In the interest of full disclosure, I got a good bit of the information for this post from Security Focus, but I felt that the way they organized the details was a bit confusing. Hence, I've reworked their original example to something a more understandable. Here is the link to that original article:
http://www.securityfocus.com/infocus/1810
Added 3/1/2008
For a more general understanding of how SSH works with public key encryption, read the following article:
http://www.securityfocus.com/infocus/1806
In order for pubkey authentication to work, you will need to create a public key on your source machine and setup an authorized_keys file on the destination server. The source machine will be the server where you are logging in FROM. The destination server is where you are logging in TO. For instance, I like to run a script on my Fedora desktop that gathers network information FROM my RHEL3 server. So my source is the Fedora desktop and the destination is my RHEL3 server.
Here's the picture:
There are four steps to setting up pubkey authentication:
1. On the source, create an Identity (a public key)
2. Copy the public key from the source to the destination
3. On the destination, login and create a .ssh directory (if necessary)
4. On the destination, add the public key to authorized_keys file
So let's begin.
1. On the source machine, create an Identity (a public key)
a. Type ssh-keygen -t rsa as below. You can choose to enter a passphrase or not:
FedoraDesktop$ ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/cacasodo/.ssh/id_rsa):
Enter passphrase (empty for no passphrase): (enter passphrase)
Enter same passphrase again: (enter passphrase)
Your identification has been saved in /home/cacasodo/.ssh/id_rsa.
Your public key has been saved in /home/cacasodo/.ssh/id_rsa.pub.
The key fingerprint is:
74:9b:69:24:4a:44:3f:a4:be:46:23:47:19:f7:dc cacasodo@FedoraDesktop
b. Verify that one public (*.pub) and one private file exists by changing to your users's .ssh directory and listing out the files:
FedoraDesktop$ cd $HOME/.ssh
FedoraDesktop$ ls -l
-rw------- 1 cacasodo cacasodo 883 Jan 21 11:52 id_rsa
-rw-r--r-- 1 cacasodo cacasodo 223 Jan 21 11:52 id_rsa.pub
c. Finally, check the contents of both files:
FedoraDesktop$ cat id_rsa
-----BEGIN RSA PRIVATE KEY----- jK2TIwbHtE7GoP/Za3NTZJm2Ozviz8+PHPIEyyt9/kzT0+yo3KmgsstlqwIBIwKB XdBh42izEWsWpXf9t4So0upV1DEcjq8CQQDEKGAzNdgzOoIozE3Z3thIjrmkimXM J/Y3xQJBAMEqZ6syYX/+uRt+any1LADRebCq6UA076Sv1dmQ5HMfPbPuU9d3yOqV j0Fn2H68bX8KkGBzGhhuLmbrgRqr3+SPM/frUj3UyYxns5rnGspRkGB3AkALCbzH 9EAV8Uxn+Jhe5cgAC/hTPPdiwTJD7MpkNCpPuKRwrohytmNAmtIpKipAf0LS61np MIICWgIBAAKBgQCc+1oixZ/g84gpZH0NeI+CvVoY5O0FOCSpFCbhUGJigQ6VeKI5 gpOlDztpJ1Rc+KmfZ2qMaftwwnLmefhk1wPcvfZvvLjfdmHY5/LFgDujLuL2Pv+F 7tBjlyX9e9JfXZau2o8uhBkMbb3ZqYlbUuuoCAnUtL5uZUiiHM0BAtnGAd6epAYE gBHw1xnqsy+mzbuWdLEVF7crlUSsctwGapb6/SEQgEXFm0RITQ3jCY808NjRS3hW Z+uCCO8GGUsn2bZpcGXa5vZzACvZL8epJoMgQ4D0T50rAkEA0AvK4PsMF02Rzi4E mXgzd1yCa030LYR/AkApG1KT//9gju6QCXlWL6ckZg/QoyglW5myHmfPR8tbz+54
/lj06BtBA9iag5+x+caV7qKth1NPBbbUF8Sbs/WI5NYweNoG8dNY2e0JRzLamAUk
59ssjBG/a4ZXNn32n78DO0i6zVV5vwf8rv2sf
-----END RSA PRIVATE KEY-----
FedoraDesktop$ cat id_rsa.pub
ssh-rsa aIsWf4POIKWR9DXiPgr1aGOTtBTgkqRQm4VBiYoEOlXiiOYKTpQ87aSd
B3NzaC1yc2EAAAABIwAAAcMJy5nn4ZNcD3L32b7y433Zh2IEAnPtAAAAUXPipn
2dqjGn7OfyxYA7oy7i9j7/hYytkyMGx7ROxqD/2WtzU2SZtjs74s/PjxzyBMsr ff5M09PsqNypoLLLZas= cacasodo@FedoraDesktop
2. Copy the public key from the source to the destination
a. This one is fairly easy. We'll go ahead and scp the public key file from the source to the destination as below:
FedoraDesktop$ cd $HOME/.ssh
FedoraDesktop$ scp id_rsa.pub rhel3server:id_rsa_FedoraDesktop.pub
cacasodo@rhel3server's password: (enter password)
The scp command above copies the public key to the destination server with a new filename, id_rsa_FedoraDesktop.pub
3. On the destination, login and create a .ssh directory (if necessary)
a. Login via ssh
FedoraDesktop$ ssh rhel3server
cacasodo@rhel3server's password: (enter password)
b. If it does not exist, follow the commands below to make a .ssh directory. Oh, don't forget the "." in front of the ssh!
rhel3server$ mkdir .ssh
rhel3server$ chmod 700 .ssh
rhel3server$ cd .ssh
4. On the destination, add the public key to authorized_keys file
a. We will use the concatenate (>>) redirector to add our source machine's public key to the authorized_keys file on the destination server.
rhel3server$ cat ../id_rsa_FedoraDesktop.pub >> authorized_keys
b. Let's verify the file:
rhel3server$ cat authorized_keys
ssh-rsa n7OfyxYA7oy7i9j7/hYytkyMGx7ROxqD/2WtzU2SZtjs74s/PjxzyBMsr 3NzaC1yc2EAAAABIwAAAcMJy5nn4ZNcD3L32b7y433Zh2IEAnPt f4POIKWR9DXiPgr1aGOTtBTgkqRQm4VBiYoEOlXiiOYKTpQ87aSdUXPipn
M09PsqNypoLLLZas= cacasodo@FedoraDesktop
c. And make sure to lock down the file with tighter permissions:
rhel3server$ chmod 600 authorized_keys
d. OK! So now, the big test is to try and login from your source server to the destination server. You should no longer need to enter a password!
FedoraDesktop$ ssh rhel3server
rhel3server$
We're in! Now you don't have to enter your ssh password at the prompt any longer! Hoo-ah!
Wednesday, July 25, 2007
using NetQoS to diagnose network congestion
We use a backend connection from our corporate offices to our hosting provider. On Monday towards the end of the day, I noticed a big slowdown in our RDP (Remote Desktop) connectivity to our Windows servers at the hosting provider. Monday is normally a very busy day for network traffic in the office as well as our main website. So I wondered where the traffic was coming from. Luckily, our network engineers had recently purchased a suite of network management tools from NetQoS (http://www.netqos.com/).
The engineers setup NetQoS monitors on the backend pipe to allow us to see the traffic going through our T1 speed, Frame Relay connection. The nice thing about NetQoS is the ability to break down the traffic going back and forth through the pipe by protocol and port. In the below graph labeled "Stacked Protocol Trend In" for this past Monday, you'll see a green blob after 15:00.
"Trend In" is data inbound to the monitored router. In our case, inbound is into our corporate network. "Trend Out" is data going outbound from the monitored router. In like fashion, outbound is out to our managed hosting provider.
As indicated by the key on the right side of the diagram, this is a spike in SSH (port 22) traffic:
Interesting! The funny thing is that a similar network performance degradation happened the previous week. I changed the date range for the NetQoS reports and saw an even larger, longer lasting spike in SSH traffic:
OK. So it seems we have a problem, but what is the cause?
We typically use SSH to monitor various Unix servers in the environment. One of the administrators has a bunch of X sessions that display performance statistics from a number of servers at the hosting facility. This X session traffic is done over SSH port. He told me that while the high SSH traffic issue was happening, one of his X session graphs was not refreshing properly. I suspected that since he was the main administrator of the servers and that he had about twelve X sessions open, that there is a bug in the X session software that was making one or more of his monitoring sessions create this spike in traffic.
At this point, he still has his X sessions open, but we will wait until the next spike in SSH traffic to try to determine if it is this admins' X sessions that are the culprit. At that time, we will probably shut down his sessions to see if that fixes the problem. I will update the blog next week to let you know how it goes.
Anyway, I'm glad that NetQoS helped us troubleshoot the problem. It gives us some good insight into network traffic by TCP/IP application.
UPDATE: another great tool to diagnose your local computer's network traffic is IPTraf (http://iptraf.seul.org/). I will review this software which runs under Linux and give a basic description of how to use it in an upcoming post.
cheers!
The engineers setup NetQoS monitors on the backend pipe to allow us to see the traffic going through our T1 speed, Frame Relay connection. The nice thing about NetQoS is the ability to break down the traffic going back and forth through the pipe by protocol and port. In the below graph labeled "Stacked Protocol Trend In" for this past Monday, you'll see a green blob after 15:00.
"Trend In" is data inbound to the monitored router. In our case, inbound is into our corporate network. "Trend Out" is data going outbound from the monitored router. In like fashion, outbound is out to our managed hosting provider.
As indicated by the key on the right side of the diagram, this is a spike in SSH (port 22) traffic:
Interesting! The funny thing is that a similar network performance degradation happened the previous week. I changed the date range for the NetQoS reports and saw an even larger, longer lasting spike in SSH traffic:
OK. So it seems we have a problem, but what is the cause?
We typically use SSH to monitor various Unix servers in the environment. One of the administrators has a bunch of X sessions that display performance statistics from a number of servers at the hosting facility. This X session traffic is done over SSH port. He told me that while the high SSH traffic issue was happening, one of his X session graphs was not refreshing properly. I suspected that since he was the main administrator of the servers and that he had about twelve X sessions open, that there is a bug in the X session software that was making one or more of his monitoring sessions create this spike in traffic.
At this point, he still has his X sessions open, but we will wait until the next spike in SSH traffic to try to determine if it is this admins' X sessions that are the culprit. At that time, we will probably shut down his sessions to see if that fixes the problem. I will update the blog next week to let you know how it goes.
Anyway, I'm glad that NetQoS helped us troubleshoot the problem. It gives us some good insight into network traffic by TCP/IP application.
UPDATE: another great tool to diagnose your local computer's network traffic is IPTraf (http://iptraf.seul.org/). I will review this software which runs under Linux and give a basic description of how to use it in an upcoming post.
cheers!
Subscribe to:
Posts (Atom)