"; */ ?>

ssh

corkscrew / cygwin / ssh / yammer — Comments Off on To Yammer through Corkscrew and Cygwin
1
Dec 10

To Yammer through Corkscrew and Cygwin

The whole thing started when I wanted to use Yammer from behind a corporate firewall. The only laptop I had handy at that moment had Windows on it, so I thought, well.. I’ll

  • install Cygwin ( a Linux-like environment for Windows )
  • download and compile corkscrew ( enables SSH connections over HTTP/HTTPS proxies )
  • set up my proxy server in “$HOME/.ssh/config”:
    • Host *
  ProxyCommand corkscrew myproxy.com 8080 %h %p
  • forward X11 with ssh:
    • export DISPLAY=localhost:0.0
ssh -2 -4 -C -X -v USER@SERVER
  • start firefox, and login to Yammer
  • DONE

But… Cygwin is not Ubuntu :)

First error I got after a fresh cygwin install was

mkdir: cannot create directory `/cygdrive/h': Permission denied

So here I had to make sure that my “H:” drive is unmapped, and I needed to add:

set HOMEDRIVE=
set HOMEPATH=
set HOMESHARE=

to “C:\cygwin\cygwin.bat” before “bash –login -i” line

The next error was slightly different, but also resembled the first one a lot:

mkdir: cannot create directory `/cygdrive/h': No such file or directory

Here I had to just cruelly delete “C:\cygwin\etc\passwd”

Now moving forward, I downloaded the Corkscrew, configured it ( ./configure ), and was about to compile it when I got:

$ make
gcc -DHAVE_CONFIG_H -I. -I. -I. -I.    -g -O2 -c corkscrew.c
In file included from /usr/include/cygwin/in.h:21,
                 from /usr/include/netinet/in.h:14,
                 from /usr/include/arpa/inet.h:14,
                 from corkscrew.c:2:
/usr/include/cygwin/types.h:120: parse error before "int16_t"
/usr/include/cygwin/types.h:124: parse error before "int32_t"
/usr/include/cygwin/types.h:128: parse error before "int64_t"
/usr/include/cygwin/types.h:137: parse error before "uint16_t"
/usr/include/cygwin/types.h:141: parse error before "uint32_t"
/usr/include/cygwin/types.h:145: parse error before "uint64_t"
/usr/include/cygwin/types.h:154: parse error before "u_int16_t"
/usr/include/cygwin/types.h:158: parse error before "u_int32_t"
/usr/include/cygwin/types.h:162: parse error before "u_int64_t"
/usr/include/cygwin/types.h:177: parse error before "register_t"
In file included from /usr/include/netinet/in.h:14,
                 from /usr/include/arpa/inet.h:14,
                 from corkscrew.c:2:
/usr/include/cygwin/in.h:40: parse error before "in_port_t"
/usr/include/cygwin/in.h:81: parse error before "in_addr_t"
In file included from corkscrew.c:2:
/usr/include/arpa/inet.h:22: parse error before "inet_addr"
/usr/include/arpa/inet.h:24: parse error before "inet_lnaof"
/usr/include/arpa/inet.h:26: parse error before "inet_netof"
/usr/include/arpa/inet.h:27: parse error before "inet_network"
make: *** [corkscrew.o] Error 1

The fix is obvious, right? :) Just needed to add “#include <sys/types.h>” to “C:\cygwin\usr\include\cygwin\types.h”:

#ifndef _CYGWIN_TYPES_H
#define _CYGWIN_TYPES_H
 
#include <sys/types.h>			/* <<<<< add this line */
#include <sys/sysmacros.h>

Now when forwarding X11 traffic over SSH, depending on firewall settings, the port 6000 ( XDMCP ) is most likely blocked:

connect localhost port 6000: Connection refused

Once the port is open, a beautiful window with Firefox and unlimited opportunities shows up making you ready to concur the world!

git / gitolite / linux / ssh / ubuntu — 14 Comments
22
Aug 10

Gitolite: Does Not Appear to be a Git Repository

Have a user, whose public key was successfully added under “gitolite-admin/keydir” and whose rights were successfully configured under “gitolite-admin/conf/gitolite.conf”.

When this very user is cloning an existing, correctly configured repository, his/her identity ( public key ) is not being passed correclty => hence notice a password prompt:

$ git clone git@yourgitserver.com:your-project
Cloning into your-project...
git@yourgitserver.com's password: 
fatal: 'your=project' does not appear to be a git repository
fatal: The remote end hung up unexpectedly

Here is the way to help out git / gitolite to understand which identity ( key ) to use:

$ vi ~/.ssh/config
host gitolite
     user git
     hostname yourgitserver.com
     identityfile ~/.ssh/mypubkey

Now changing “git@yourgitserver.com” to “gitolite” does the trick:

$ git clone gitolite:your-project
Cloning into your-project...
remote: Counting objects: 83, done.
remote: Compressing objects: 100% (77/77), done.
remote: Total 83 (delta 3), reused 0 (delta 0)
Receiving objects: 100% (83/83), 156.45 KiB | 49 KiB/s, done.
Resolving deltas: 100% (3/3), done.

Notice, public key was successfully accepted => hence there was no password prompt, and the clone was successful.

git / ssh — Comments Off on Git: Specify SSH Port
16
Aug 10

Git: Specify SSH Port

On the client side add “host” and “port” entries into “~/.ssh/config”, git will obey:

$ cat ~/.ssh/config 
host reposerver.com 
port 123
ssh / ubuntu / video / vlc — Comments Off on Play Video/Audio on Remote X Server over SSH
9
Aug 10

Play Video/Audio on Remote X Server over SSH

export DISPLAY=:0.0
vlc --fullscreen ~/mmedia/video/мультики/снежная-королева.avi
linux / shell / ssh / sysadmin — 22 Comments
10
Mar 09

Run Commands Remotely via SSH with No Password

Run Commands Remotely via SSH with No Password

Extremely useful for system administrators, very useful for application developers when testing with remote services, or how some buzz developers refer to it: Service Oriented Architecture (SOA). Also remote execution is widely used by web masters to sync/backup/create mirrors.

Below 5 simple steps will enable you to run any commands on the remote box/host/server via SSH without a need to provide a password. That is usually useful, if such remote calls need to be automated (work without manual/human intervention).

Step number 6 has an example on how to actually run a command on remote host via SSH.

from the local host

Step 1. Create a public/private keys with “ssh-keygen” (ENTER through everything):

      user@host:~/.ssh$ ssh-keygen -t rsa
 
      Generating public/private rsa key pair.
 
      Enter file in which to save the key (/home/toly/.ssh/id_rsa): 		[ENTER]
      Enter passphrase (empty for no passphrase): 				[ENTER]
      Enter same passphrase again: 							[ENTER]
 
      Your identification has been saved in /home/user/.ssh/id_rsa.
      Your public key has been saved in /home/user/.ssh/id_rsa.pub.
      The key fingerprint is:
      66:fd:11:ca:2d:21:b9:73:c1:b6:fa:1d:b2:2c:71:cd user@host
 
      The key's randomart image is:
      +--[ RSA 2048]----+
      |                         |
      |           .             |
      |          . o           |
      |         o + o         |
      |        E S.o o       |
      |       o. .+.o .       |
      |       . +o o.         |
      |        +. o...        |
      |       ... ..=.         |
      +-----------------+

At this point the public and private keys should be created and saved into “~/.ssh” directory:

      user@host:~/.ssh$ ls -l
      total 20
      -rw------- 1 user group 1675 2009-03-10 14:18 id_rsa
      -rw-r--r-- 1 user group 392 2009-03-10 14:18 id_rsa.pub
      -rw-r--r-- 1 user group 8642 2009-03-10 12:10 known_hosts

Step 2. Add identity to the local ssh authorizer with “ssh-add”.

If you “entered” through the “Enter file in which to save the key (/home/toly/.ssh/id_rsa)” in the previous step, then your identity file should be “id_rsa”:

      user@host:~/.ssh$ ssh-add id_rsa

Otherwise replace “id_rsa” with the file you chose to save your identity in.

In case of a friendly “Could not open a connection to your authentication agent.” error message, start “ssh-agent” as:

eval `ssh-agent`

and re-run “ssh-add”.

Step 3. Copy the public key to the remote host ( server ) under “~/.ssh”:

From the step above “id_rsa.pub” would be the public key that needs to be copied to the remote system you would like to run commands on.

      user@host:~/.ssh$ scp id_rsa.pub remoteuser@remotehost.com:~/.ssh/

from the remote host

Step 4. On remote host add this public key to “authorized_keys”:

      remoteuser@remotehost:~$ cd ~/.ssh
      remoteuser@remotehost:~/.ssh~$ cat id_rsa.pub >> authorized_keys

Step 5. Change “authorized_keys” permissions to allow only you to read/write it:

      remoteuser@remotehost:~/.ssh$ chmod 600 authorized_keys

from the local host

Step 6. Now you can run any command on the remote box from the local box with no password:

Let’s see what that remote box is running at:

       user@host:~$ ssh remoteuser@remotehost.com  uname -a
 
       Linux remotehost 2.6.27-01-generic #1 SMP Thu Mar 21 10:34:21 UTC 2009 i686 GNU/Linux

By runing “ssh remoteuser@remotehost.com uname -a” from the local box, you just ran “uname -a” command on the remote box without a need to enter the password.

Good Luck Remoting!