Difference between revisions of "Category:SSH"

From Noah.org
Jump to: navigation, search
Line 2: Line 2:
  
 
== External OpenSSL Command-line FAQ ==
 
== External OpenSSL Command-line FAQ ==
 +
 
This [http://www.madboa.com/geek/openssl/ OpenSSL HowTo/FAQ] deals with the command-line openssl.
 
This [http://www.madboa.com/geek/openssl/ OpenSSL HowTo/FAQ] deals with the command-line openssl.
  
Line 83: Line 84:
 
<pre>
 
<pre>
 
ssh -f -N -q -L 1143:192.168.1.100:143 username@dmz.example.com
 
ssh -f -N -q -L 1143:192.168.1.100:143 username@dmz.example.com
 +
</pre>
 +
 +
 +
=== reverse port forwarding ===
 +
 +
Sometimes I need to make an internal LAN machine expose a service to the outside WAN.
 +
For example, I have a database server that will only accept connections from a
 +
specific development box. That dev box is inside the firewall. I want to connect to
 +
the database from outside the firewall.
 +
 +
<pre>
 +
ssh -t -L 5432:localhost:1999 my_name@firewall.example.com ssh -t db_server ssh -t -R 1999:127.0.0.1:5432 my_name@firewall
 
</pre>
 
</pre>
  
Line 150: Line 163:
 
* no-port-forwarding: prevent ssh -R ...
 
* no-port-forwarding: prevent ssh -R ...
 
* permitopen="localhost:143": allow only localhost connections to port 143 for `ssh -L` requests
 
* permitopen="localhost:143": allow only localhost connections to port 143 for `ssh -L` requests
 
== reverse port forwarding ==
 
 
Sometimes I need to make an internal LAN machine expose a service to the outside WAN.
 
For example, I have a database server that will only accept connections from a
 
specific development box. That dev box is inside the firewall. I want to connect to
 
the database from outside the firewall.
 
<pre>ssh -t -L 5432:localhost:1999 my_name@firewall.example.com ssh -t db_server ssh -t -R 1999:127.0.0.1:5432 my_name@firewall
 
</pre>
 
 
  
 
== Turn off known_hosts host identity check ssh
 
== Turn off known_hosts host identity check ssh

Revision as of 18:33, 7 July 2008


External OpenSSL Command-line FAQ

This OpenSSL HowTo/FAQ deals with the command-line openssl.

SSH config tweaks

Most default SSH installations need a little tweaking for speed or extra security. There are two config files to worry about. One is on the server you are trying to connect to and the other is on your localhost.

/etc/ssh/sshd_config

These are changes I always make to /etc/ssh/sshd_config. See fail2ban for protecting against bots doing dictionary attacks.

# this speeds up logins.
UseDNS no
# Don't make this 1. Public keys count as 1st try. If that fails the SSHd will not try password.
MaxAuthTries 2
# bots often check these accounts for weak passwords:
DenyUsers root test admin guest nobody
# for even extra security, limit access to only these users:
# Uncomment the line below and add the usernames you want to allow.
#AllowUsers user1 user2 user3

Use the following to support SSH1. I no longer use this.

# this is required if you want to support SSH1
Protocol 2,1
# this is required if you want to support SSH1
PasswordAuthentication yes

/etc/ssh/ssh_config or ~/.ssh/config

Edit the client SSH config if you are getting slow logins. This is sometimes caused by GSSAPI Authentication. I also like to turn on KeepAlive.

Host *
# This sometimes fixes slow logins on Ubuntu.
# Don't use this if you use Kerberos or GSSAPI.
GSSAPIAuthentication no
# This helps prevent timeout disconnects.
TCPKeepAlive yes
ServerAliveInterval 60

simple port forwarding (SSH tunnel)

This example creates a tunnel for HTTP. This will forward port 80 of your localhost to port 80 of www.example.com.

ssh -f -N -q -L 80:localhost:80 username@www.example.com

This example creates a tunnel for IMAP. Here we forward port 1143 on localhost to 143 (IMAP) on imap.example.com.

ssh -f -N -q -L 1143:localhost:143 username@imap.example.com

-f tells ssh to go into the background (daemonize).

-N tells ssh that you don't want to run a remote command. That is, you only want to forward ports.

-q tells ssh to be quiet

-L specifies the port forwarding

port forwarding through an intermediary

You can have the remote machine forward ports to a third machine. This is useful where your have your local machine outside a firewall; a visible machine on the DMZ; and a third machine invisible to the outside.

This creates a tunnel from your localhost port 81 to 192.168.1.69 port 80 through dmz.example.com. This lets you see the web server from outside a LAN.

ssh -f -N -q -L 81:192.168.1.69:80 username@dmz.example.com

This example creates a tunnel for IMAP. Here we forward port 1143 on localhost to 143 (IMAP) on 192.168.1.100 through dmz.example.com.

ssh -f -N -q -L 1143:192.168.1.100:143 username@dmz.example.com


reverse port forwarding

Sometimes I need to make an internal LAN machine expose a service to the outside WAN. For example, I have a database server that will only accept connections from a specific development box. That dev box is inside the firewall. I want to connect to the database from outside the firewall.

ssh -t -L 5432:localhost:1999 my_name@firewall.example.com ssh -t db_server ssh -t -R 1999:127.0.0.1:5432 my_name@firewall

Using scp through a DMZ gateway to a machine behind a firewall using a tunnel

First you setup port forwarding through an intermediary. This forwards your localhost port 2222 to port 22 on 192.168.1.100. Remember, that 192.168.1.100 is not on your local network. The machine at 192.168.1.100 is on the LAN network visible to the machine 208.77.188.166.

ssh -f -N -q -L 2222:192.168.1.100:22 user@208.77.188.166
scp -P 2222 transformers.avi user@localhost:.

A diagram might help. Remember, port 22 is the SSH server port on the 192.168.1.100 machine.

+---------------+        +----------------+        +----------------------+
|     your      |        |  remote DMZ    |        | server on remote LAN |
| local machine |        |    server      |        |    192.168.1.100     |
|               |        | 208.77.188.166 |        |                      |
|         2222:  >-------|                |-------> :22                   |
|               |        |\______________/|        |                      |
|               |        |                |        |                      |
+---------------+        +----------------+        +----------------------+

Using `dd` and `ssh` to copy a file through a DMZ gateway to a machine behind a firewall

You can chain ssh commands. Each ssh can be used to start another ssh command. This doesn't require a tunnel, but requires that keys be setup between the DMZ gateway and the server on the remote LAN.

This example copies a file called pictures.tar.gz:

dd if=pictures.tar.gz | ssh user@208.77.188.166 "ssh user@192.168.1.100 \"dd of=pictures.tar.gz\""

SOCKS5 with Firefox

Simple and secure web browsing. You can setup a tunnel as described above or you can use the following technique. This starts SSH on your localhost acting as a SOCKS proxy. Once you start SSH this way you can point any application that supports a SOCKS5 interface to this port. But these instructions will show what you need to do to get Firefox to proxy through SOCKS. Firefox supports SOCKS with no extra add-ons.

Start ssh an connection to a host that you want to proxy through. Use the -D option to specify a SOCKS5 port on your localhost. The port doesn't really matter. You just need to use the same port in your SOCKS client application. :

ssh -D 9999 username@proxy.example.com

In Firefox select "Edit | Preferences | Advanced Tab | Connection Settings button". Then select "Manual proxy configuration". All you need to fill out is "SOCKS Host: Localhost", "Port: 9999", then select "SOCKS v5". It's easy.

Firefox socks settings.png

This tool can also help in switching the proxy settings on and off: SwitchProxy Tool

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:

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
  • 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 known_hosts host identity check ssh

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:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    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.

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:

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

WARNINGThis totally defeats detection of man-in-the-middle attacks. You shouldn't use this on a regular basis.

SSH for Windows

Putty is the best free SSH client for Windows. You can also use 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.

   mindterm.jar

Put this applet on a web page and point the <applet> "archive" attribute to the URL of the JAR file:

 <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>

<include iframe src="http://www.noah.org/engineering/mindterm/mindterm_iframe.html" width="630" height="460px" />

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.