Cocoa libssh2 wrapper

I’ve modified a simple wrapper for the libssh2 library that now has the following functionality:

  • Code moved to separate classes to allow reusability
  • Multiple sessions to different servers can be achieved with a few lines of code
  • A Session can be passed to the operator class allowing operations (commands sent to it), more will be added
At the current time it connects fine to OSX and Linux sshd however I can’t connect to ESXi even with the correct password it reports incorrect, However I think I Can resolve this shortly.
Original wrapper (designed for iOS) can be found from in his Git Repo.
Download here: SSH Wrapper

ESXi v4.1 SFTP access


This is a 32bit binary, which I think needs some pretty old kernel version. Hence it only works on 4.0, I will try and get an updated release for 4,1 (*note) ESXi 5 comes with sftp-server already.


I came across something interesting while fiddling earlier, after spending about 2 hours building a static release of openssh server that was going to replace dropbear. I’d gotten to a point where I could build a i386 release of the binaries with no random library requirements and sshd would start and listen on a port defined in /etc/ssh/sshd_config. unfortunately starting ssh in debug mode allowed me to see numerous glibc errors during connections and explain why I couldn’t connect. At this point I don’t think there is any real way of replacing dropbear with a complete openssh solution even statically linking. Even testing the openssh sftp binary that had been compiled showed that it wasn’t coping with a system call not returning UIDs correctly meaning that it would report a FATAL error and close continually.

Given openssh wasn’t going to be replaced I researched about dropbear and if there was a newer version perhaps with sftp, unfortunately not. Eventually I came across notes on a blog mentioning that dropbear “supports” openssh sftp. After restoring ESXi back to its default filesystem settings (ssh enabled) it appears the attempting to sftp to esxi returns the following error.

ash: /sbin/sftp-server: not found
Connection closed

After compiling a slightly older version of openssh (static) I found a release of sftp-server that will once placed in /sbin on ESXi allows full usage of sftp (including sshfs mounting) binary below.









SSH tunnels

Sometimes getting to various servers especially virtualised systems, can be a nightmare due to various firewall rules restricting the physical machine or just down to the network architecture itself. For this example we’ll use two virtual machines which are located behind nat’d firewalls on two different physical hosts the firewalls permit SSH access out that is it.

[PHYS_A [VM_A:5901]]  <–/–>  [PHYS_B [VM_B]]

VM_A needs to run a VNC Server that will bind to VM_A:5901, however will no access to the firewall etc.. there is no way that there can be any port forwarding to this internal VM. We could use IPtables on the VM_A and then again use IPtables on PHYS_A to bind 5901 from VM_A’s IP to PHYS_A, however we are still behind a firewall.

To accomplish this sharing a server running SSH is required, the location of this server is completely irrelevant as long as it’s accessible with a standard user account. This server will be called SSH and both machines can access it through the firewall.

[PHYS_A [VM_A:5901]]  <—> [SSH] <—>  [PHYS_B [VM_B]]

The next step is to push the port on VM_A to the SSH server using the following command:

[user@VM_A]$ ssh -R5901: -C user@SSH

This will open a session that will create the port 5901 on the server SSH, this can be confirmed by running a netstat -a on the server SSH and seeing that 5901 is now listed as a TCP4 listening port.

[PHYS_A [VM_A:5901]]  <—> [SSH:5901] <—>  [PHYS_B [VM_B]]

The next step is to pull the port on SSH to VM_B where we have the client software (vncviwer). The following command is used to pull the port from an IP address and bind it to a local port in VM_B.

[user@VM_B]$ ssh -L5901: -C user@SSH

There will now be the port created on VM_B that tunnels through SSH to VM_A.

[PHYS_A [VM_A:5901]]  <—> [SSH:5901] <—>  [PHYS_B [VM_B:5901]]

The user on VM_B can now use the service as if it was actually running on the host itself.

[user@VM_B] vncviewer localhost:5901

Notes for SSH flags:

-R   [port to bind to on remote host] : [local host IP] : [localhost port]

-L   [local port to use] : [remote IP] : [remote port]

-C (adds compression)