ICO wiki - User contributions [en]

Sshutel

2017-05-08T18:54:28Z

Ktrunov: /* Server side Requirements */

=Introduction=
Do you ever wanted to use SSH as a VPN? There is little piece of useful utility called [https://sshuttle.readthedocs.io/en/stable/index.html sshuttle] is available to completely turn your SSH connection as VPN. sshuttle is a transparent proxy server that works as a poor man’s VPN over ssh. You don’t need any admin account on your remote system. It supports DNS tunneling and works with Linux and MacOS platforms.

The program is suitable for the cases when:<ref>[https://sshuttle.readthedocs.io/en/stable/overview.html sshuttle overview]</ref>:

* Your client machine (or router) is Linux, FreeBSD, or MacOS.

* You have access to a remote network via ssh.

* You don’t necessarily have admin access on the remote network.

* You don’t want to create an ssh port forward for every single host/port on the remote network.

* You hate openssh’s port forwarding because it’s randomly slow and/or stupid.

=How it works <ref>[https://sshuttle.readthedocs.io/en/stable/how-it-works.html]</ref>=
sshuttle is not exactly a VPN, and not exactly port forwarding. It’s kind of both, and kind of neither.

It’s like a VPN, since it can forward every port on an entire network, not just ports you specify. Conveniently, it lets you use the “real” IP addresses of each host rather than faking port numbers on localhost.

On the other hand, the way it works is more like ssh port forwarding than a VPN. Normally, a VPN forwards your data one packet at a time, and doesn’t care about individual connections; ie. it’s “stateless” with respect to the traffic. sshuttle is the opposite of stateless; it tracks every single connection.

You could compare sshuttle to something like the old Slirp program, which was a userspace TCP/IP implementation that did something similar. But it operated on a packet-by-packet basis on the client side, reassembling the packets on the server side. That worked okay back in the “real live serial port” days, because serial ports had predictable latency and buffering.

But you can’t safely just forward TCP packets over a TCP session (like ssh), because TCP’s performance depends fundamentally on packet loss; it must experience packet loss in order to know when to slow down! At the same time, the outer TCP session (ssh, in this case) is a reliable transport, which means that what you forward through the tunnel never experiences packet loss. The ssh session itself experiences packet loss, of course, but TCP fixes it up and ssh (and thus you) never know the difference. But neither does your inner TCP session, and extremely screwy performance ensues.

sshuttle assembles the TCP stream locally, multiplexes it statefully over an ssh session, and disassembles it back into packets at the other end. So it never ends up doing TCP-over-TCP. It’s just data-over-TCP, which is safe.

=Requirements=
==Client side Requirements==
* sudo, or root access on your client machine. (The server doesn’t need admin access.)
* Python 2.7 or Python 3.5.<ref>[https://sshuttle.readthedocs.io/en/stable/requirements.html]</ref>

==Server side Requirements==
* Server requirements are more relaxed, however it is recommended that you use Python 2.7 or Python 3.5.

=Installation=
* From PyPI:
<source lang="bash">
pip install sshuttle
</source>

* Clone from git:
<source lang="bash">
git clone https://github.com/sshuttle/sshuttle.git
./setup.py install
</source>

* Installing sshuttle on your Mac:
<source lang="bash">
brew install sshuttle
</source>

=Usage=

Finally we can get down to actually using sshuttle! It’s flexible enough to do fancier things, for forwarding all traffic basic command looks like this:

<source lang="bash">
sshuttle -r username@sshserver 0.0.0.0/0
</source>

* Use the <code>sshuttle -r</code> parameter to specify a remote server.

* By default sshuttle will automatically choose a method to use. Override with the <code>sshuttle --method</code> parameter.

* There is a shortcut for 0.0.0.0/0 for those that value their wrists: <code>sshuttle -r username@sshserver 0/0</code>

If you would also like your DNS queries to be proxied through the DNS server of the server you are connect to:

<source lang="bash">
sshuttle --dns -r username@sshserver 0/0
</source>

That’s it! Now your local machine can access the remote network as if you were right there. And if your “client” machine is a router, everyone on your local network can make connections to your remote network.<ref>[https://sshuttle.readthedocs.io/en/stable/usage.html]</ref>

=Conclusion=
Admittedly, sshuttle takes a bit more work than other solutions to get up and running, but the security it provides gives peace of mind when forced to use insecure Wi-Fi networks.

=Autor=
;Kirill Trunov C11, Estonian IT College, 08-05-2017

=References=
<references />

[[Category:Operatsioonisüsteemide administreerimine ja sidumine]]

OSadmin wiki article

2017-05-08T18:19:54Z

Ktrunov: /* Category */

=Intro=
*Choose a topic from personal experience related with the subject or from topics found on the wiki page
*[[#Chosen_topics|Write the topic here]].
*Lecturer will confirm the topic
*Write your article in wiki environment
*Inform the [[Operating_systems#Lecturer|lecturer]] when the article is finished
*Receive feedback for corrections

=Requirements for the wiki article=
Author: name, group and date when the article is written

==Introduction ==
Covers points what will be discussed in the article, what are the requirements for the article reader; what are the operating system’s requirements.

==Contents==
All commands should be easily separable from the overall text.
Users should be able to copy the commands directly (additional info like prompt and user distinction symbols should be left out from the command description area)
The text should determine what user permissions are needed to perform these tasks.
The reader of your article is your fellow students, so try to avoid irrelevant information and stay on topic (don’t explain the meaning of IP address or how to install Ubuntu, when your topic is actually about htop)
All the content should be referenced.
Do not use slang and try to be grammatically correct.<br>
<span style="color:#FF0000">
Bear in mind that this is an open environment, so everything you write in your wiki article, will be public. </span>

==Referencing==
Best practises of wiki referencing should be used.
Terms are but between square brackets to reference other articles in the system.
All drawing and images have to be referenced below the picture and in the text. (for example “System architecture can be viewed on image x, y and z.”)
Author’s own ideas have to be clearly presentable. Everything used from the sources have to be referenced.

==Fellow student review==
Please find a fellow student who will review your article and give a feedback on the discussion tab of the article using [http://enos.itcollege.ee/~edmund/materials/viki-artikkel/Assessment-model-for-the-wiki-article.html the following assessment model].

==Summary==
Besides a short overview, what was discussed in this article, it should also include the author's own opinion about the topic.

==Category==
Add the following category to the end of the article (last row):<br>
'''<nowiki>[[Category:Operatsioonisüsteemide administreerimine ja sidumine]]</nowiki>'''

[[Link title]]=Chosen topics=
Please write here your topic and name, group:
* '''Fedora OS'''; Anamul Hoque Shihab; CSE-11
* '''Basic Automation with Python'''; Ardi Vaba; CSE-11
* [https://wiki.itcollege.ee/index.php/SSH_Encryption '''SSH Encryption'''], Frank Korving, CSE-11
* '''Translation of OSadmin wiki help page to English [[https://wiki.itcollege.ee/index.php/Osadmin_spikker]]'''; Peep Kuulme; CSE-11
* [https://wiki.itcollege.ee/index.php/Cross-Site_Scripting_(XSS)_attacks '''Cross-Site Scripting''']; Masaki Ihara; CSE-11
*[https://wiki.itcollege.ee/index.php/Auditd '''Auditd - Linux system monitoring with audit daemon'''], Nika Ptskialadze, CSE-11
* '''GNU Privacy Guard (GnuPG)'''; Patricia Bruno Barbosa; CSE-11
*[https://wiki.itcollege.ee/index.php/BackBox_OS '''BackBox OS''']; Ats Tootsi; CSE-11
*[https://wiki.itcollege.ee/index.php/Apparmor_and_its_usage '''Apparmor and its usage'''], Mikus, CSE-11
*[https://wiki.itcollege.ee/index.php/Arch_linux '''Arch Linux'''];Farhan Nayeem Islam;CSE-C11
* ''''VPN (English version)'''', Christian Cataldo, CSE-C11; [https://wiki.itcollege.ee/index.php/VPN_(English_version)]
* ''Translation of DDoS Wiki page[[https://wiki.itcollege.ee/index.php/DDoS_Eng]]'''; Andris Männik; CSE-11
*'''Translation of Ps Wiki page[[https://wiki.itcollege.ee/index.php/Ps]]'''''; Christopher Carr; CSE-11
*'''Translation of Bash_Shell wiki page[[https://wiki.itcollege.ee/index.php/BASH_shell_en]]'''; Steven Rugam; CSE-11
*[[https://wiki.itcollege.ee/index.php/SED_eng ''SED_Stream Editor'']; Gabriel Adoyi; CSE-11
*'''Pass: The Standard Unix Password Manager'''[[https://wiki.itcollege.ee/index.php/Pass]]; Oliver Rahula; CSE-11
*[https://wiki.itcollege.ee/index.php/Rsync_eng ''Rsync'']; Eriks Ocakovskis; C11
* '''Translation of Hotspot[https://wiki.itcollege.ee/index.php/hotspot]'''; [https://wiki.itcollege.ee/index.php/Setting_up_hotspot ''Setting up Hotspot''] Sander Valgo C11
*[https://wiki.itcollege.ee/index.php/Sshutel '''Sshuttle'''], Kirill Trunov, CSE-11

==Ideas==

* UNIX CLI password manager https://www.passwordstore.org and its GUI http://qtpass.org/

=References=
* [https://wiki.itcollege.ee/index.php/Osadmin_referaadi_teemad counterpart article in Estonian]
* http://manpage.io
* https://linuxjourney.com/
* [https://linux.die.net/man/ Linux man-pages]
* [https://linux.die.net Linux docs]
* http://www.tecmint.com/60-commands-of-linux-a-guide-from-newbies-to-system-administrator/
* http://www.tecmint.com/useful-linux-commands-for-system-administrators/
* http://www.cyberciti.biz/tips/top-linux-monitoring-tools.html
* http://www.thegeekstuff.com/2010/12/50-unix-linux-sysadmin-tutorials

[[Category:Operatsioonisüsteemide administreerimine ja sidumine]]

User:Ktrunov

2017-05-08T18:18:32Z

Ktrunov: Ktrunov moved page User:Ktrunov to Sshutel

#REDIRECT [[Sshutel]]

Sshutel

2017-05-08T18:18:32Z

Ktrunov: Ktrunov moved page User:Ktrunov to Sshutel

=Introduction=
Do you ever wanted to use SSH as a VPN? There is little piece of useful utility called [https://sshuttle.readthedocs.io/en/stable/index.html sshuttle] is available to completely turn your SSH connection as VPN. sshuttle is a transparent proxy server that works as a poor man’s VPN over ssh. You don’t need any admin account on your remote system. It supports DNS tunneling and works with Linux and MacOS platforms.

The program is suitable for the cases when:<ref>[https://sshuttle.readthedocs.io/en/stable/overview.html sshuttle overview]</ref>:

* Your client machine (or router) is Linux, FreeBSD, or MacOS.

* You have access to a remote network via ssh.

* You don’t necessarily have admin access on the remote network.

* You don’t want to create an ssh port forward for every single host/port on the remote network.

* You hate openssh’s port forwarding because it’s randomly slow and/or stupid.

=How it works <ref>[https://sshuttle.readthedocs.io/en/stable/how-it-works.html]</ref>=
sshuttle is not exactly a VPN, and not exactly port forwarding. It’s kind of both, and kind of neither.

It’s like a VPN, since it can forward every port on an entire network, not just ports you specify. Conveniently, it lets you use the “real” IP addresses of each host rather than faking port numbers on localhost.

On the other hand, the way it works is more like ssh port forwarding than a VPN. Normally, a VPN forwards your data one packet at a time, and doesn’t care about individual connections; ie. it’s “stateless” with respect to the traffic. sshuttle is the opposite of stateless; it tracks every single connection.

You could compare sshuttle to something like the old Slirp program, which was a userspace TCP/IP implementation that did something similar. But it operated on a packet-by-packet basis on the client side, reassembling the packets on the server side. That worked okay back in the “real live serial port” days, because serial ports had predictable latency and buffering.

But you can’t safely just forward TCP packets over a TCP session (like ssh), because TCP’s performance depends fundamentally on packet loss; it must experience packet loss in order to know when to slow down! At the same time, the outer TCP session (ssh, in this case) is a reliable transport, which means that what you forward through the tunnel never experiences packet loss. The ssh session itself experiences packet loss, of course, but TCP fixes it up and ssh (and thus you) never know the difference. But neither does your inner TCP session, and extremely screwy performance ensues.

sshuttle assembles the TCP stream locally, multiplexes it statefully over an ssh session, and disassembles it back into packets at the other end. So it never ends up doing TCP-over-TCP. It’s just data-over-TCP, which is safe.

=Requirements=
==Client side Requirements==
* sudo, or root access on your client machine. (The server doesn’t need admin access.)
* Python 2.7 or Python 3.5.<ref>[https://sshuttle.readthedocs.io/en/stable/requirements.html]</ref>

==Server side Requirements==
Server requirements are more relaxed, however it is recommended that you use Python 2.7 or Python 3.5.

=Installation=
* From PyPI:
<source lang="bash">
pip install sshuttle
</source>

* Clone from git:
<source lang="bash">
git clone https://github.com/sshuttle/sshuttle.git
./setup.py install
</source>

* Installing sshuttle on your Mac:
<source lang="bash">
brew install sshuttle
</source>

=Usage=

Finally we can get down to actually using sshuttle! It’s flexible enough to do fancier things, for forwarding all traffic basic command looks like this:

<source lang="bash">
sshuttle -r username@sshserver 0.0.0.0/0
</source>

* Use the <code>sshuttle -r</code> parameter to specify a remote server.

* By default sshuttle will automatically choose a method to use. Override with the <code>sshuttle --method</code> parameter.

* There is a shortcut for 0.0.0.0/0 for those that value their wrists: <code>sshuttle -r username@sshserver 0/0</code>

If you would also like your DNS queries to be proxied through the DNS server of the server you are connect to:

<source lang="bash">
sshuttle --dns -r username@sshserver 0/0
</source>

That’s it! Now your local machine can access the remote network as if you were right there. And if your “client” machine is a router, everyone on your local network can make connections to your remote network.<ref>[https://sshuttle.readthedocs.io/en/stable/usage.html]</ref>

=Conclusion=
Admittedly, sshuttle takes a bit more work than other solutions to get up and running, but the security it provides gives peace of mind when forced to use insecure Wi-Fi networks.

=Autor=
;Kirill Trunov C11, Estonian IT College, 08-05-2017

=References=
<references />

[[Category:Operatsioonisüsteemide administreerimine ja sidumine]]

Sshutel

2017-05-08T18:14:35Z

Ktrunov: /* Conclusion */

=Introduction=
Do you ever wanted to use SSH as a VPN? There is little piece of useful utility called [https://sshuttle.readthedocs.io/en/stable/index.html sshuttle] is available to completely turn your SSH connection as VPN. sshuttle is a transparent proxy server that works as a poor man’s VPN over ssh. You don’t need any admin account on your remote system. It supports DNS tunneling and works with Linux and MacOS platforms.

The program is suitable for the cases when:<ref>[https://sshuttle.readthedocs.io/en/stable/overview.html sshuttle overview]</ref>:

* Your client machine (or router) is Linux, FreeBSD, or MacOS.

* You have access to a remote network via ssh.

* You don’t necessarily have admin access on the remote network.

* You don’t want to create an ssh port forward for every single host/port on the remote network.

* You hate openssh’s port forwarding because it’s randomly slow and/or stupid.

=How it works <ref>[https://sshuttle.readthedocs.io/en/stable/how-it-works.html]</ref>=
sshuttle is not exactly a VPN, and not exactly port forwarding. It’s kind of both, and kind of neither.

It’s like a VPN, since it can forward every port on an entire network, not just ports you specify. Conveniently, it lets you use the “real” IP addresses of each host rather than faking port numbers on localhost.

On the other hand, the way it works is more like ssh port forwarding than a VPN. Normally, a VPN forwards your data one packet at a time, and doesn’t care about individual connections; ie. it’s “stateless” with respect to the traffic. sshuttle is the opposite of stateless; it tracks every single connection.

You could compare sshuttle to something like the old Slirp program, which was a userspace TCP/IP implementation that did something similar. But it operated on a packet-by-packet basis on the client side, reassembling the packets on the server side. That worked okay back in the “real live serial port” days, because serial ports had predictable latency and buffering.

But you can’t safely just forward TCP packets over a TCP session (like ssh), because TCP’s performance depends fundamentally on packet loss; it must experience packet loss in order to know when to slow down! At the same time, the outer TCP session (ssh, in this case) is a reliable transport, which means that what you forward through the tunnel never experiences packet loss. The ssh session itself experiences packet loss, of course, but TCP fixes it up and ssh (and thus you) never know the difference. But neither does your inner TCP session, and extremely screwy performance ensues.

sshuttle assembles the TCP stream locally, multiplexes it statefully over an ssh session, and disassembles it back into packets at the other end. So it never ends up doing TCP-over-TCP. It’s just data-over-TCP, which is safe.

=Requirements=
==Client side Requirements==
* sudo, or root access on your client machine. (The server doesn’t need admin access.)
* Python 2.7 or Python 3.5.<ref>[https://sshuttle.readthedocs.io/en/stable/requirements.html]</ref>

==Server side Requirements==
Server requirements are more relaxed, however it is recommended that you use Python 2.7 or Python 3.5.

=Installation=
* From PyPI:
<source lang="bash">
pip install sshuttle
</source>

* Clone from git:
<source lang="bash">
git clone https://github.com/sshuttle/sshuttle.git
./setup.py install
</source>

* Installing sshuttle on your Mac:
<source lang="bash">
brew install sshuttle
</source>

=Usage=

Finally we can get down to actually using sshuttle! It’s flexible enough to do fancier things, for forwarding all traffic basic command looks like this:

<source lang="bash">
sshuttle -r username@sshserver 0.0.0.0/0
</source>

* Use the <code>sshuttle -r</code> parameter to specify a remote server.

* By default sshuttle will automatically choose a method to use. Override with the <code>sshuttle --method</code> parameter.

* There is a shortcut for 0.0.0.0/0 for those that value their wrists: <code>sshuttle -r username@sshserver 0/0</code>

If you would also like your DNS queries to be proxied through the DNS server of the server you are connect to:

<source lang="bash">
sshuttle --dns -r username@sshserver 0/0
</source>

That’s it! Now your local machine can access the remote network as if you were right there. And if your “client” machine is a router, everyone on your local network can make connections to your remote network.<ref>[https://sshuttle.readthedocs.io/en/stable/usage.html]</ref>

=Conclusion=
Admittedly, sshuttle takes a bit more work than other solutions to get up and running, but the security it provides gives peace of mind when forced to use insecure Wi-Fi networks.

=Autor=
;Kirill Trunov C11, Estonian IT College, 08-05-2017

=References=
<references />

[[Category:Operatsioonisüsteemide administreerimine ja sidumine]]

Sshutel

2017-05-08T18:11:07Z

Ktrunov: Created page with "=Introduction= Do you ever wanted to use SSH as a VPN? There is little piece of useful utility called [https://sshuttle.readthedocs.io/en/stable/index.html sshuttle] is availa..."

=Introduction=
Do you ever wanted to use SSH as a VPN? There is little piece of useful utility called [https://sshuttle.readthedocs.io/en/stable/index.html sshuttle] is available to completely turn your SSH connection as VPN. sshuttle is a transparent proxy server that works as a poor man’s VPN over ssh. You don’t need any admin account on your remote system. It supports DNS tunneling and works with Linux and MacOS platforms.

The program is suitable for the cases when:<ref>[https://sshuttle.readthedocs.io/en/stable/overview.html sshuttle overview]</ref>:

* Your client machine (or router) is Linux, FreeBSD, or MacOS.

* You have access to a remote network via ssh.

* You don’t necessarily have admin access on the remote network.

* You don’t want to create an ssh port forward for every single host/port on the remote network.

* You hate openssh’s port forwarding because it’s randomly slow and/or stupid.

=How it works <ref>[https://sshuttle.readthedocs.io/en/stable/how-it-works.html]</ref>=
sshuttle is not exactly a VPN, and not exactly port forwarding. It’s kind of both, and kind of neither.

It’s like a VPN, since it can forward every port on an entire network, not just ports you specify. Conveniently, it lets you use the “real” IP addresses of each host rather than faking port numbers on localhost.

On the other hand, the way it works is more like ssh port forwarding than a VPN. Normally, a VPN forwards your data one packet at a time, and doesn’t care about individual connections; ie. it’s “stateless” with respect to the traffic. sshuttle is the opposite of stateless; it tracks every single connection.

You could compare sshuttle to something like the old Slirp program, which was a userspace TCP/IP implementation that did something similar. But it operated on a packet-by-packet basis on the client side, reassembling the packets on the server side. That worked okay back in the “real live serial port” days, because serial ports had predictable latency and buffering.

But you can’t safely just forward TCP packets over a TCP session (like ssh), because TCP’s performance depends fundamentally on packet loss; it must experience packet loss in order to know when to slow down! At the same time, the outer TCP session (ssh, in this case) is a reliable transport, which means that what you forward through the tunnel never experiences packet loss. The ssh session itself experiences packet loss, of course, but TCP fixes it up and ssh (and thus you) never know the difference. But neither does your inner TCP session, and extremely screwy performance ensues.

sshuttle assembles the TCP stream locally, multiplexes it statefully over an ssh session, and disassembles it back into packets at the other end. So it never ends up doing TCP-over-TCP. It’s just data-over-TCP, which is safe.

=Requirements=
==Client side Requirements==
* sudo, or root access on your client machine. (The server doesn’t need admin access.)
* Python 2.7 or Python 3.5.<ref>[https://sshuttle.readthedocs.io/en/stable/requirements.html]</ref>

==Server side Requirements==
Server requirements are more relaxed, however it is recommended that you use Python 2.7 or Python 3.5.

=Installation=
* From PyPI:
<source lang="bash">
pip install sshuttle
</source>

* Clone from git:
<source lang="bash">
git clone https://github.com/sshuttle/sshuttle.git
./setup.py install
</source>

* Installing sshuttle on your Mac:
<source lang="bash">
brew install sshuttle
</source>

=Usage=

Finally we can get down to actually using sshuttle! It’s flexible enough to do fancier things, for forwarding all traffic basic command looks like this:

<source lang="bash">
sshuttle -r username@sshserver 0.0.0.0/0
</source>

* Use the <code>sshuttle -r</code> parameter to specify a remote server.

* By default sshuttle will automatically choose a method to use. Override with the <code>sshuttle --method</code> parameter.

* There is a shortcut for 0.0.0.0/0 for those that value their wrists: <code>sshuttle -r username@sshserver 0/0</code>

If you would also like your DNS queries to be proxied through the DNS server of the server you are connect to:

<source lang="bash">
sshuttle --dns -r username@sshserver 0/0
</source>

That’s it! Now your local machine can access the remote network as if you were right there. And if your “client” machine is a router, everyone on your local network can make connections to your remote network.<ref>[https://sshuttle.readthedocs.io/en/stable/usage.html]</ref>

==Conclusion==
Admittedly, sshuttle takes a bit more work than other solutions to get up and running, but the security it provides gives peace of mind when forced to use insecure Wi-Fi networks.

=Autor=
;Kirill Trunov C11, Estonian IT College, 08-05-2017

=References=
<references />

[[Category:Operatsioonisüsteemide administreerimine ja sidumine]]