Stop / Restart / Start Open SSH Server

Posted by root on Monday Jun 17, 2013 Under Bash, Remote Access, SSH

Ubuntu Linux: Start OpenSSH Server

Type the following command:
$ sudo /etc/init.d/ssh start
OR
$ sudo service ssh start

Ubuntu Linux: Stop OpenSSH server

Type the following command:
$ sudo /etc/init.d/ssh stop
OR
$ sudo service ssh stop

Ubuntu Linux: Restart OpenSSH server

Type the following command:
$ sudo /etc/init.d/ssh restart
OR
$ sudo service ssh restart

Ubuntu Linux: See status of OpenSSH server

Type the following command:
$ sudo /etc/init.d/ssh status
OR
$ sudo service ssh status

Controlling sshd using upstart based commands

Since the script /etc/init.d/ssh has been converted to an Upstart based job, try the following commands to start / stop / restart the OpenSSH server:

Stop/Start/Restart the OpenSSH using the following commands

The syntax is:

 
sudo stop ssh
sudo start ssh
sudo restart ssh
sudo status ssh

Source: http://www.cyberciti.biz/faq/howto-start-stop-ssh-server/
Tags : | add comments

VNC Server on KDE and Lubuntu

Posted by root on Wednesday May 22, 2013 Under Bash, Debian, Linux, Remote Access, Ubuntu

To run a fast desktop manager over slow internet connection use LXDE Desktop Manager or Lubuntu.

The file “~//.vnc/xstartup” must be changed such way:

#!/bin/sh
xrdb $HOME/.Xresources
xsetroot -solid black
lxterminal &
/usr/bin/lxsession -s LXDE &

For Lubuntu:

#!/bin/sh
[ -r HOME/.Xresources ] && xrdb $HOME/.Xresources
xsetroot -solid grey
vncconfig -iconic &
x-terminal-emulator -geometry 80x24+10+10 -ls -title "$VNCDESKTOP Desktop" &

/usr/bin/lxsession -s Lubuntu -e LXDE &
Tags : | add comments

Port Forwarding with IP Tables

Posted by root on Tuesday May 22, 2012 Under Bash, Centos, Linux, Remote Access

In this tutorial we’ll set up a simple port forwarding (NAT) using iptables.

1. Enable ip forward

echo "1" > /proc/sys/net/ipv4/ip_forward

2. Append routing rules to the nat table

iptables -t nat -A PREROUTING -p tcp -s 0/0 -d {local_ip} --dport {local_port} -j DNAT --to {destination_ip}:{destination_port}

iptables -t nat -A POSTROUTING -o eth0 -d {destination_ip} -j SNAT --to-source {local_ip}

{local_ip}: A ip address mapped on the local system
{local_port}: The port you would like to listen on
{destination_ip}: Destination ip address
{destination_port}: Destination port

3. Now you can access http://{local_ip}:{local_port} and would actually be getting response from http://{destination_ip}:{destination_port}

A working example

If the ip address of your system is 32.64.128.200 and you import the following rules, you would be able to connect to http://32.64.128.200:8080 and actually see the Google search engine because 216.239.59.105:80 is one of Google’s web servers.

iptables -t nat -A PREROUTING -p tcp -s 0/0 -d 32.64.128.200 --dport 8080 -j DNAT --to 216.239.59.105:80
iptables -t nat -A POSTROUTING -o eth0 -d 216.239.59.105 -j SNAT --to-source 32.64.128.200
Tags : | add comments

Remove History on SVN

Posted by root on Saturday Jun 4, 2011 Under Bash, Centos, Debian, Remote Access

Version control systems like CVS or Subversion are designed for keeping track of the changes of a project and for having the possibility to revert to old revisions if something goes wrong. In contrast to regular relational databases, these systems are made only for adding new content to a repository, and not for removing data from it. In fact, deleting old content is not a built-in functionality in SVN, and mostly requires removing entire revisions from the repository or even creating a new one.

But what happens if you accidentally commit a password or other sensitive information to a repository? This post explains how to remove this confidential data permanently from the repository by simply overwriting it in old revisions, i.e. without having to remove revisions or create a new repository.

First create a local repo where you’ll download googlecode’s repo to:

<code>svnadmin create /tmp/your_local_repo
</code>

create file /tmp/isd_gc/hooks/pre-revprop-change with contents

<code>#!/bin/bash
exit 0
</code>

make it eXecutable:

<code>chmod +x /tmp/isd_gc/hooks/pre-revprop-change
</code>

if you fail on this section you most likely will see an error: Revprop change blocked by pre-revprop-change hook (exit code 255) with no output.

now you can init the svn sync from code.google.com

<code>svnsync init --username yourname@youremail file:///tmp/your_local_repo https://yourproject.googlecode.com/svn 
</code>

and start downloading all history:

<code>svnsync sync --username  yourname@youremail file:///tmp/your_local_repo
</code>

Committed revision 1.

Copied properties for revision 1.

Transmitting file data …………………..

Copied properties for revision 87.

Now we create a dumpfile which will be fed to svndumpfilter to remove unwanted files.

<code>svnadmin dump . &gt; /tmp/tst_dump_gc.dmp
</code>

use svndumpfilter to remove first unwanted file from it.

<code>svndumpfilter exclude /trunk/unwanted file_1.jsvg &lt; /tmp/tst_dump_gc.dmp &gt; /tmp/tst_dump_clean1.dmp
</code>

Dropped 1 node:

‘/trunk/unwanted file_new.jsvg’

remove second unwanted file:

<code>svndumpfilter exclude /trunk/unwanted file_2.jsvg &lt; /tmp/tst_dump_clean1.dmp &gt; /tmp/tst_dump_clean2.dmp
</code>

recreate “old temp repo”

<code>rm -rf /tmp/your_local_repo

svnadmin create /tmp/your_local_repo
</code>

load filtered dump into repo

<code>[/tmp]$svnadmin load --ignore-uuid your_local_repo &lt; /tmp/tst_dump_clean2.dmp
</code>

Check that everything is ok in a svn client (doing a history check on the trunk only shows 25 first results in my svn client).

<code>svnsync sync --username yourname@youremail https://yourproject.googlecode.com/svn
</code>
Tags : , , , , , | add comments

Mounting a Remote Folder on Linux (Ubuntu) with SSH

Posted by root on Wednesday May 25, 2011 Under Bash, Remote Access, Ubuntu

Overview

SSH is a secure protocol for communicating between machines. SSHFS is a tool that uses SSH to enable mounting of a remote filesystem on a local machine; the network is (mostly) transparent to the user. Because SSHFS authenticates connections, you can be sure that only those who should have access to remote directories can mount them (as long as everything is configured properly).

Because SSH encrypts connections, no one can see your files as they are transferred over the network. And because SSHFS is built using FUSE, even your own root user can only see your files by logging in to your account with su.

Installation and Setup
Simply install the following package:

sudo apt-get install sshfs

then add yourself to the fuse group:

sudo gpasswd -a $USER fuse

Alternatively, GNOME users can go to System -> Administration -> Users and Groups -> (your user) -> Properties -> User Privileges, then tick the following option:

Allow use of fuse filesystems like LTSP Thin Client blockdevices
Adding yourself to the fuse group lets you use the fusermount command, which is needed by the FUSE userland filesystem utility.

Once you have added yourself to the fuse group, you should log out and log back in again for the change to take effect.

Command-line Usage
Now, assuming that you have an SSH server running on a remote machine, simply run the SSHFS command to mount the remote directory. In this example, the remote directory is /projects on remote host far. The local mount point is ~/far_projects.

mkdir ~/far_projects
sshfs -o idmap=user $USER@far:/projects ~/far_projects

To unmount,

fusermount -u ~/far_projects

To add it to your /etc/fstab,

sshfs#$USER@far:/projects /home/$USER/far_projects fuse defaults,idmap=user 0 0

Note that you have to change $USER to your login name when editing fstab, but it is not necessary when typing commands (the shell does it for you in that case).

One thing to be aware of is that your UID (User ID, the unique number of your user on a system) is not necessarily the same on the two hosts. When you ls -l, the user name associated with each file is printed in the third column. However, in the filesystem, only UIDs are stored, and ls simply looks up the UID and finds the user name associated with it. In Unix, UIDs are what matter, not the user names. So if you’re 1000 on the local host and 1003 on the remote host, the sshfs mounted directory would show a different user name for your files. This is not a problem, though, because the ssh server on the remote machine is what is actually reading and writing files. So even though it shows up in ls -l as a different UID, any changes will be done through the ssh server on the remote host, which will use the correct UID for the remote machine. Problems may arise if you attempt to use a program that looks at UIDs of files (e.g. ls prints the wrong user name).

The idmap=user option ensures that files owned by the remote user are owned by the local user. If you don’t use idmap=user, files in the mounted directory might appear to be owned by someone else, because your computer and the remote computer have different ideas about the numeric user ID associated with each user name. idmap=user will not translate UIDs for other users.

Using the GUI

Alternatively you can mount a directory over SSHFS using the Gnome “Connect to Server” tool in the desktop Places menu. In the tool, set the service type to SSH and fill in the boxes as needed. If a password is required when connecting then you will be prompted for it. Unmounting a SSHFS connection is the same as for any other volume. Open the File Browser (Nautilus). In the Places panel on the left click the arrow next to the SSHFS mount you want to disconnect or right-click it and select “Unmount”.

Keep Alive
Your ssh session will automatically log out if it is idle. To keep the connection active (alive) add this to ~/.ssh/config or to /etc/ssh/ssh_config on the client.

ServerAliveInterval 5

This will send a “keep alive” signal to the server every 5 seconds. You can usually increase this interval, and I use 120.

Source: https://help.ubuntu.com/community/SSHFS

Tags : , , , , , | add comments

virt-viewer Remote Access

Posted by root on Friday Apr 22, 2011 Under Debian, MySql, PHP, Remote Access

Virt-viewer has the capability to run locally and connect to a remote server, either directly to the libvirt daemon, or via an SSH tunnel. To do the latter, the following command will work for KVM (qemu) based hypervisors:

 

virt-viewer --connect qemu+ssh://user@host.example.com/system vmnamehere

With the above, you’ll have to enter your SSH password twice – first to establish the connection to the hypervisor and secondly to establish a tunnel to the VM’s VNC/SPICE session – you’ll probably quickly decide to get some SSH keys/certs setup to prevent annoyance.

Tags : , | add comments