Difference between revisions of "Category:SSH"

From Noah.org
Jump to navigationJump to search
 
(2 intermediate revisions by the same user not shown)
Line 1: Line 1:
 
[[Category:Engineering]]
 
[[Category:Engineering]]
 
+
[[Category:SSL]]
== External OpenSSL Command-line FAQ ==
 
 
 
This [http://www.madboa.com/geek/openssl/ OpenSSL HowTo/FAQ] deals with the command-line openssl.
 
 
 
== Encrypt output of a command to log file ==
 
 
 
It is pretty trivial to send output from a command to an encrypted log file. This is useful if running a server in debug mode where log output might contain sensitive information such as personal information or passwords.
 
 
 
<pre>
 
some_command | openssl bf -e -salt -out log.bf
 
</pre>
 
 
 
You can decrypt the log file while the command is still running.
 
 
 
<pre>
 
cat log.bf | openssl bf -d -salt
 
</pre>
 
 
 
== Chaining SSH logins through a gateway ==
 
 
 
Sometimes you want to login from one machine to another through an intermediate gateway. You can do it all in one line if you specify the -t option. This connects to 192.168.1.100 visible only from example.com. The 192.168.1.100 address is not your LAN but the LAN visible to example.com.
 
 
 
<pre>
 
ssh -t noah@example.com "ssh noah@192.168.1.100"
 
</pre>
 
 
 
== Remote Server Security Enhancement with SSH Keys ==
 
 
 
You can make port forwarding even more secure by limiting what a privileged account can do. When you add a key to authorized_key you may pass parameters to fine tune the connection. This can be used to restrict what the client is allowed to do. On the remote server, add the following to ~username/.ssh/authorized_keys:
 
 
 
<pre>
 
from="192.168.1.69",command="/bin/false",no-pty,no-X11-forwarding,no-agent-forwarding,no-port-forwarding,permitopen="localhost:143"
 
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEA8XIr8LEXdvc4VZEvNenWkJrerTzNhqTT7QvCD+Y2EjCUPQwfBcSnvhY3oasNigNonghQFqm7/HqWBLpcN+4mqDUrXrEdj6HQmHvCV6WozNUVb5jjiyQ/JF4hqcQd6oelCkVw8wD32I2jlYqydpqOGY4xqakWDAfm3SOx5il3Kl49mKCg5B3GQPexhTujaTT3y/Q1eeT3zGpHE9Mp7k20X8rMxSjp5ncLAmdf42fRh05HY5f1GrupQIEdi0/TDcPNWL1ml89zttrDOLgDnwny7P0x2jmcX41cSxL/8svER7BAk2sroyQe6L21pJ7o2MYz1IwnsQgji/GjJoaA7hTNCQ== username@client.example.com
 
</pre>
 
 
 
* from="192.168.1.69": accept connection only from the given IP address
 
* command="/bin/false": forces this command to be run no matter what is passed via ssh from the client
 
* no-pty: never allocate a PTY for interactivity
 
* no-X11-forwarding: No X11
 
* no-agent-forwarding: we don't want or need ssh-agent
 
* no-port-forwarding: prevent ssh -R ...
 
* permitopen="localhost:143": allow only localhost connections to port 143 for `ssh -L` requests
 
 
 
== Turn off remote host identity check in known_hosts ==
 
 
Sometimes you want to connect to a remote host where you do not care about the host identification. Or you might be connecting to a single host IP address that is serving multiple SSH servers on different ports. Unfortunately, ssh stores only the remote host's IP address in your ~/.ssh/known_hosts file, so it will complain about different keys even though they came from different ports on the same IP address.
 
 
 
You get an error message like this:
 
 
 
<pre>
 
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
 
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!    @
 
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
 
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
 
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
 
It is also possible that the RSA host key has just been changed.
 
</pre>
 
 
 
The trick is to tell ssh not to ask you if you want to store the remote hosts identity key and you must tell ssh to look for a dummy known_hosts file.
 
 
 
The following example shows connecting to different ports of the same IP address while ignoring the remote host identification:
 
 
 
<pre>
 
ssh -o "StrictHostKeyChecking no" -o "UserKnownHostsFile /dev/null" noah@192.168.1.100
 
ssh -p 2268 -o "StrictHostKeyChecking no" -o "UserKnownHostsFile /dev/null" noah@192.168.1.100
 
ssh -p 2269 -o "StrictHostKeyChecking no" -o "UserKnownHostsFile /dev/null" noah@192.168.1.100
 
</pre>
 
 
 
<em>WARNING!</em> This totally defeats detection of man-in-the-middle attacks. You should not use this on a regular basis.
 
 
 
== SSH for Windows ==
 
 
 
[http://www.chiark.greenend.org.uk/~sgtatham/putty/ Putty] is the best free SSH client for Windows. You can also use [http://www.cygwin.com Cygwin], but the ANSI terminal emulation isn't as good unless you start the X11 server and run xterm.
 
 
 
== MindTerm SSH client Java Applet ==
 
 
 
MindTerm_2.1 (non-commercial). This was the last free version of MindTerm.
 
 
 
    [http://www.noah.org/engineering/mindterm/mindterm.jar mindterm.jar]
 
 
 
Put this applet on a web page and point the <applet> "archive" attribute to the URL of the JAR file:
 
<small><pre>
 
<applet archive="mindterm.jar" code="com.mindbright.application.MindTerm.class" width="580" height="400">
 
    <param name="te" value="xterm-color"> <!-- "vt102" -->
 
    <param name="fs" value="18">
 
    <param name="gm" value="80x32+0+0">
 
    <param name="port" value="22">
 
    <param name="cipher" value="blowfish"> <!-- "des" -->
 
    <param name="usrname" value="">
 
    <param name="sepframe" value="false">
 
    <param name="quiet" value="false">
 
    <param name="cmdsh" value="false">
 
    <param name="verbose" value="true">
 
    <pa ram name="autoprops" value="none">
 
    <param name="idhost" value="false">
 
    <param name="alive" value="10">
 
    <param name="appletbg" value="white">
 
</applet>
 
</pre></small>
 
 
 
<include iframe src="http://www.noah.org/engineering/mindterm/mindterm_iframe.html" width="630" height="460px" />
 

Latest revision as of 01:14, 22 October 2008

Subcategories

This category has only the following subcategory.

S

Pages in category "SSH"

The following 7 pages are in this category, out of 7 total.