mirror of https://github.com/macssh/macssh.git
1353 lines
55 KiB
HTML
Executable File
1353 lines
55 KiB
HTML
Executable File
<html lang="en"><head>
|
||
<title>lsh</title>
|
||
<meta http-equiv="Content-Type" content="text/html">
|
||
<meta name=description content="lsh">
|
||
<meta name=generator content="makeinfo 4.0">
|
||
<link href="http://texinfo.org/" rel=generator-home>
|
||
</head><body>
|
||
|
||
<p><hr>
|
||
Node:<a name="Top">Top</a>,
|
||
Next:<a rel=next href="#Introduction">Introduction</a>,
|
||
Previous:<a rel=previous href="#(dir)">(dir)</a>,
|
||
Up:<a rel=up href="#(dir)">(dir)</a>
|
||
<br>
|
||
|
||
<h1></h1>
|
||
|
||
<p>This document describes <code>lsh</code> and related programs. The <code>lsh</code> suite
|
||
of programs is intended as a free replacement for the <code>ssh</code> suite of
|
||
programs. In turn, <code>ssh</code> was intended as a secure replacement for
|
||
the <code>rsh</code> and <code>rlogin</code> programs for remote login over the
|
||
Internet.
|
||
|
||
<p><code>lsh</code> is a component of the <small>GNU</small> system.
|
||
|
||
<p>This manual explains how to use and hack <code>lsh</code>; it corresponds to
|
||
<code>lsh</code> version 1.1.6.
|
||
|
||
<ul>
|
||
<li><a href="#Introduction">Introduction</a>:
|
||
<li><a href="#Installation">Installation</a>:
|
||
<li><a href="#Getting%20started">Getting started</a>:
|
||
<li><a href="#Invoking%20lsh">Invoking lsh</a>:
|
||
<li><a href="#Invoking%20lshd">Invoking lshd</a>:
|
||
<li><a href="#Terminology">Terminology</a>:
|
||
<li><a href="#Concept%20Index">Concept Index</a>:
|
||
|
||
<p>--- The Detailed Node Listing ---
|
||
|
||
<p>Introduction
|
||
|
||
</p><li><a href="#Threats">Threats</a>:
|
||
<li><a href="#Features">Features</a>:
|
||
<li><a href="#Related%20techniques">Related techniques</a>:
|
||
|
||
<p>Related programs and techniques
|
||
|
||
</p><li><a href="#ssh1">ssh1</a>: SSH version 1
|
||
<li><a href="#ssh2">ssh2</a>: SSH version 2
|
||
<li><a href="#Kerberos">Kerberos</a>: Kerberos
|
||
<li><a href="#ipsec">ipsec</a>: IP Sec
|
||
|
||
<p>Getting started
|
||
|
||
</p><li><a href="#lsh%20basics">lsh basics</a>: Connection with lsh
|
||
<li><a href="#tcpip%20forwarding">tcpip forwarding</a>: Forwarding <small>TCP/IP</small> ports
|
||
<li><a href="#lshd%20basics">lshd basics</a>: Starting the lshd deamon
|
||
<li><a href="#public-key">public-key</a>: Using public-keys
|
||
<li><a href="#srp">srp</a>: Using SRP authentication
|
||
<li><a href="#sexp">sexp</a>: Examining keys and other S-exp files.
|
||
<li><a href="#Converting%20keys">Converting keys</a>:
|
||
|
||
<p>Invoking <code>lsh</code>
|
||
|
||
</p><li><a href="#Algorithm%20options">Algorithms</a>: Selecting algorithms.
|
||
<li><a href="#Hostauth%20options">Hostauth options</a>:
|
||
<li><a href="#Userauth%20options">Userauth options</a>:
|
||
<li><a href="#Action%20options">Actions</a>: What to do after login.
|
||
<li><a href="#Verbosity%20options">Messages</a>: Tuning the amount of messages.
|
||
|
||
</ul>
|
||
|
||
<p><hr>
|
||
Node:<a name="Introduction">Introduction</a>,
|
||
Next:<a rel=next href="#Installation">Installation</a>,
|
||
Previous:<a rel=previous href="#Top">Top</a>,
|
||
Up:<a rel=up href="#Top">Top</a>
|
||
<br>
|
||
|
||
<h1>Introduction</h1>
|
||
|
||
<p>What is this thing called computer security anyway? Why would you want
|
||
to use a program like <code>lsh</code>?
|
||
|
||
<p>This chapter explains the threats <code>lsh</code> tries to protect you from,
|
||
and some of the threats that remain. It also describes some of the
|
||
technologies used in <code>lsh</code>.
|
||
|
||
<p>From time to time in this manual, I will speak about the <dfn>enemy</dfn>.
|
||
This means anybody who is trying to eavesdrop or disturb your private
|
||
communication. This usage is technical, and it does not imply that the
|
||
enemy is somehow morally inferior to you: The enemy may be some awful
|
||
criminals trying to eavesdrop on you, or it may be the police trying to
|
||
eavesdrop on the same criminals.
|
||
|
||
<p>The enemy can be a criminal, or a competitor, or your boss who's trying
|
||
to find out how much you tell collegues at competing firms. It may be
|
||
your own or somebody else's national security officials. Or your
|
||
ex-boyfriend who happens to be too curious.
|
||
|
||
<p>So what can the enemy do to your communications and your privacy?
|
||
Remember that just because you're paranoid that doesn't mean that nobody
|
||
is trying to get you<small>...</small>
|
||
|
||
<ul>
|
||
<li><a href="#Threats">Threats</a>:
|
||
<li><a href="#Features">Features</a>:
|
||
<li><a href="#Related%20techniques">Related techniques</a>:
|
||
</ul>
|
||
|
||
<p><hr>
|
||
Node:<a name="Threats">Threats</a>,
|
||
Next:<a rel=next href="#Features">Features</a>,
|
||
Previous:<a rel=previous href="#Introduction">Introduction</a>,
|
||
Up:<a rel=up href="#Introduction">Introduction</a>
|
||
<br>
|
||
|
||
<h2>Threats</h2>
|
||
|
||
<p>When logging in to some other machine via the Internet, either in the
|
||
same building or a few continents away, there are several things that
|
||
may be under enemy attack.
|
||
|
||
<dl>
|
||
<dt><dfn>Local attacks</dfn>
|
||
<dd>The enemy controls your local environment. He or she may be looking over
|
||
your shoulder. Your local machine might be cracked. Or there may be some
|
||
device planted inside your keyboard transmitting everything you type to
|
||
the attacker. About the same problems occur if the attacker has taken
|
||
control over your target machine, i.e. the remote machine you have
|
||
logged in to.
|
||
|
||
<br><dt><dfn>Denial-of-service attacks</dfn>
|
||
<dd>The enemy has cut your network cable, effectively stopping your
|
||
communication. Even without doing physical damage, the enemy may be able
|
||
to flood and overload computers or network equipment. Or disrupt network
|
||
traffic by sending fake packets to hangup your <small>TCP/IP</small>
|
||
connections.
|
||
|
||
<br><dt><dfn>Passive eavesdropping</dfn>
|
||
<dd>The enemy may be able to listen to your communication somewhere along
|
||
its path. With the global Internet, it's difficult to predict who might
|
||
be able to listen. Internet traffic between buildings just a few hundred
|
||
meters apart have been observed temporarily being routed through half a
|
||
dozen countries, perhaps a few thousand kilometers.
|
||
|
||
<p>And even without routing anomalies, it is possible that the enemy has
|
||
been able to take control of some nearby machine, and can listen in from
|
||
there. Of course, passive eavesdropping is most dangerous if you
|
||
transmit cleartext passwords. This is the main reason not to use vanilla
|
||
telnet to login to remote systems. Use a telnet with support for
|
||
<small>SSL</small> or Kerberos, or use a program like <code>lsh</code> or
|
||
<code>ssh</code>.
|
||
|
||
<p>A passive eavesdropper is assumed not to do anything nasty with your
|
||
packets beyond listening to them.
|
||
|
||
<br><dt><dfn>Name resolution attacks</dfn>
|
||
<dd>The translation from symbolic <small>DNS</small> names to numeric
|
||
ip-addresses may be controlled by the attacker. In this case, you may
|
||
think that you are connecting to a friendly machine, when in fact you
|
||
are connecting somewhere else.
|
||
|
||
<br><dt><dfn>Fake packets</dfn>
|
||
<dd>It is fairly easy to fake the source address of an <small>IP</small>-packet,
|
||
although it is more difficult to get hold on the replies to the faked
|
||
packets. But even without any replies, this can cause serious
|
||
problems.
|
||
|
||
<br><dt><dfn>Man-in-the-middle attack</dfn>
|
||
<dd>In this attack, the enemy sits between you and the target. When
|
||
communicating with you, he pretends to be the target. When communicating
|
||
with the target, he pretends to be you. He also passes all information
|
||
on more or less unmodified, so that he is invisible to you and the
|
||
target. To mount this attack, the enemy either needs physical access to
|
||
some network equipment on the path between you and the target, or he has
|
||
been able to fool you to connect to him rather than to the target, for
|
||
example by manipulating the <small>DNS</small>-system.
|
||
|
||
</dl>
|
||
|
||
<p><code>lsh</code> makes no attempt to protect you from local attacks. You have
|
||
to trust the endpoint machines. It seems really difficult to uphold any
|
||
security if the local machine is compromised. This is important to keep
|
||
in mind in the "visitor"-scenario, where you visit a friend or perhaps an
|
||
Internet caf<61> and want to connect to some of the machines at home or at
|
||
work. If the enemy has been able to compromize your friend's or the
|
||
caf<EFBFBD>'s equipment, you may well be in trouble.
|
||
|
||
<p>Protection from denial-of-service attacks is also a very difficult
|
||
problem, and <code>lsh</code> makes no attempt to protect you from that.
|
||
|
||
<p>Instead, the aim of <code>lsh</code>, and most serious tools for cryptographic
|
||
protection of communications across the net, is to isolate the
|
||
vulnerabilities to the communication endpoints. If you know that the
|
||
endpoints are safe, the enemy should not be able to compromize your
|
||
privacy or communications. Except for denial-of-service attacks (which
|
||
at least can't be performed without you noticing it).
|
||
|
||
<p>First of all, <code>lsh</code> provides protection against passive
|
||
eavesdropping. In addition, if you take the appropriate steps to make
|
||
sure that hostkeys are properly authenticated, <code>lsh</code> also protects
|
||
against man-in-the-middle attacks and in particular against attacks on
|
||
the name resolution. In short, you need only trust the security at the
|
||
end points: Even if the enemy controls all other network equipment, name
|
||
resolution and routing infrastructure, etc, he can't do anything beyond
|
||
the denial-of-service attack.
|
||
|
||
<p>And at last, remember that there is no such thing as absolute security.
|
||
You have to estimate the value of that which you are protecting, and
|
||
adjust the security measures so that your enemies will not find it worth
|
||
the effort to break them.
|
||
|
||
<p><hr>
|
||
Node:<a name="Features">Features</a>,
|
||
Next:<a rel=next href="#Related%20techniques">Related techniques</a>,
|
||
Previous:<a rel=previous href="#Threats">Threats</a>,
|
||
Up:<a rel=up href="#Introduction">Introduction</a>
|
||
<br>
|
||
|
||
<h2>Features</h2>
|
||
|
||
<p><code>lsh</code> does not only provide more secure replacements for
|
||
<code>telnet</code>, <code>rsh</code> and <code>rlogin</code>, it also provides some other
|
||
features to make it convenient to communicate securely. But <code>lsh</code> is
|
||
still in an early stage of development, so this section is expected to
|
||
grow with time. One goal for <code>lsh</code> is to make it reasonable easy to
|
||
extend it, without messing with the core security functionality.
|
||
|
||
<p><code>lsh</code> can be configured to allow login based on a personal key-pair
|
||
consisting of a private and a public key, so that you can execute remote
|
||
commands without typing your password every time. You can also use
|
||
Thomas Wu's Secure Remote Password Protocol (<small>SRP</small>). Kerberos support is
|
||
on the wish list but not yet supported (see <a href="#Kerberos">Kerberos</a>).
|
||
|
||
<p>The public-key authentication methods should also be extended to support
|
||
Simple Public Key Infrastructure (<small>SPKI</small>) certificates, including some
|
||
mechanism to delegate restricted logins.
|
||
|
||
<p>Forwarding of arbitrary <small>TCP/IP</small> connections is provided. This
|
||
is useful for tunneling otherwise insecure protocols, like telnet and
|
||
pop, through an encrypted <code>lsh</code> connection.
|
||
|
||
<p>Convenient tunneling of <small>X</small> is one of the most impressive features of the
|
||
original <code>ssh</code> programs. <code>lsh</code> doesn't do this yet. Other kind
|
||
of tunneling that may turn out to be useful include authentication (i.e.
|
||
<code>ssh-agent</code>), general forwarding of <small>UDP</small>, and why not also
|
||
general <small>IP</small>-tunneling.
|
||
|
||
<p><hr>
|
||
Node:<a name="Related%20techniques">Related techniques</a>,
|
||
Previous:<a rel=previous href="#Features">Features</a>,
|
||
Up:<a rel=up href="#Introduction">Introduction</a>
|
||
<br>
|
||
|
||
<h2>Related programs and techniques</h2>
|
||
|
||
<p>This sections describes some other programs and techniques related to
|
||
<code>lsh</code>. The ssh family of programs use mostly the same kind of
|
||
security as <code>lsh</code>. Kerberos and <small>IPSEC</small> operate quite
|
||
differently, in particular when it comes to protection against
|
||
man-in-the-middle attacks.
|
||
|
||
<ul>
|
||
<li><a href="#ssh1">ssh1</a>: SSH version 1
|
||
<li><a href="#ssh2">ssh2</a>: SSH version 2
|
||
<li><a href="#Kerberos">Kerberos</a>: Kerberos
|
||
<li><a href="#ipsec">ipsec</a>: IP Sec
|
||
</ul>
|
||
|
||
<p><hr>
|
||
Node:<a name="ssh1">ssh1</a>,
|
||
Next:<a rel=next href="#ssh2">ssh2</a>,
|
||
Previous:<a rel=previous href="#Related%20techniques">Related techniques</a>,
|
||
Up:<a rel=up href="#Related%20techniques">Related techniques</a>
|
||
<br>
|
||
|
||
<h3><code>ssh-1.x</code></h3>
|
||
|
||
<p>The first of the Secure shell programs was Tatu Yl<59>nen's <code>ssh</code>.
|
||
The latest of the version 1 series is <code>ssh-1.27</code> which speaks
|
||
version 1.5 of the protocol. The "free" version of <code>ssh-1.27</code>
|
||
does not allow commercial use without additional licensing, which makes
|
||
<code>ssh-1.27</code> non-free software according to Debian's Free Software
|
||
Guidelines and the Open Source Definition.
|
||
|
||
<p>The version 1 protocol has some minor weaknesses, in particular, all
|
||
support for using stream ciphers was disabled by default a few versions
|
||
back, for security reasons.
|
||
|
||
<p>There also exists free implementations of <code>ssh-1</code>, for both Unix
|
||
and Windows. <code>ossh</code> and later OpenSSH are derived from earlier
|
||
version av Tatu Yl<59>nen's <code>ssh</code>, and are free software.
|
||
|
||
<p>Until <code>lsh</code> becomes stable and well tested, I would recommend using
|
||
some implementation of the <code>ssh-1</code> protocol.
|
||
|
||
<p><hr>
|
||
Node:<a name="ssh2">ssh2</a>,
|
||
Next:<a rel=next href="#Kerberos">Kerberos</a>,
|
||
Previous:<a rel=previous href="#ssh1">ssh1</a>,
|
||
Up:<a rel=up href="#Related%20techniques">Related techniques</a>
|
||
<br>
|
||
|
||
<h3><code>ssh-2.x</code></h3>
|
||
|
||
<p><code>ssh2</code> implements the next generation of the Secure Shell
|
||
protocol, the development of which is supervised by the <small>IETF</small>
|
||
secsh Working Group. <code>lsh</code> implements the required subset of
|
||
this protocol. It is intended to be compatible with the <code>ssh2</code>
|
||
series of programs distributed by F-Secure Corporation.
|
||
|
||
<p>However, the existing versions of <code>ssh2</code> gets some details of the
|
||
protocol wrong (probably because it predates the protocol
|
||
specification), so there is some amount of bug-compatibility required.
|
||
|
||
<p>Interoperability between independently developed implementations is one
|
||
necessary condition for the <code>ssh-2</code> protocol to become a Proposed
|
||
Standard.
|
||
|
||
<p>The license for F-Secure's <code>ssh2</code> programs is similar to that
|
||
for recent versions of <code>ssh1</code>, but with a narrower definition of
|
||
"non-commercial use".
|
||
|
||
<p>Besides <code>lsh</code> there are few free implementations of the
|
||
<code>ssh-2</code> protocols, but since May 2000 it is supported also by
|
||
OpenSSH.
|
||
|
||
<p><hr>
|
||
Node:<a name="Kerberos">Kerberos</a>,
|
||
Next:<a rel=next href="#ipsec">ipsec</a>,
|
||
Previous:<a rel=previous href="#ssh2">ssh2</a>,
|
||
Up:<a rel=up href="#Related%20techniques">Related techniques</a>
|
||
<br>
|
||
|
||
<h3>Kerberos</h3>
|
||
|
||
<p>Kerberos is a key distribution system originally developed in the late
|
||
1980:s as a part of Project Athena at <small>MIT</small>. Recent development
|
||
have been done at The Royal Institute of Technology, Stockholm
|
||
(<small>KTH</small>).
|
||
|
||
<p>Kerberos uses a central trusted ticket-granting server, and requires
|
||
less trust on the local machines in the system. It does not use
|
||
public-key technology.
|
||
|
||
<p>Usually, Kerberos support is compiled into applications such as telnet,
|
||
ftp and X-clients. The ssh family of programs, on the other hand, tries
|
||
to do all needed magic, for instance to forward <small>X</small> securely, and then
|
||
provides general <small>TCP/IP</small> forwarding as a kitchen sink.
|
||
|
||
<p>I believe Kerberos' and lsh's protection against passive eavesdropping
|
||
are mostly equivalent. The difference is in the set of machines and
|
||
assumptions you have to trust in order to be safe from a
|
||
man-in-the-middle attack.
|
||
|
||
<p>I think the main advantage of <code>lsh</code> over Kerberos is that it is
|
||
easier to install and use for on ordinary mortal user. In order to set
|
||
up key exchange between two different Kerberos systems (or <dfn>Kerberos
|
||
realms</dfn>), the respective system operators need to exchange keys. In the
|
||
case of two random users at two random sites, setting up <code>lsh</code> or
|
||
some other program in the ssh family is likely easier than to get the
|
||
operators to spend time and attention. So <code>lsh</code> should be easier to
|
||
use in an anarchistic grass-roots environment.
|
||
|
||
<p>Another perspective is to combine ssh features like <small>X</small> and
|
||
<small>TCP/IP</small> forwarding with authentication based on Kerberos. Such
|
||
an arrangement may provide the best of two worlds for those who happen
|
||
to have an account at a suitable ticket-granting server.
|
||
|
||
<p><hr>
|
||
Node:<a name="ipsec">ipsec</a>,
|
||
Previous:<a rel=previous href="#Kerberos">Kerberos</a>,
|
||
Up:<a rel=up href="#Related%20techniques">Related techniques</a>
|
||
<br>
|
||
|
||
<h3><small>IPSEC</small></h3>
|
||
|
||
<p><small>IPSEC</small> is a set of protocols for protecting general
|
||
<small>IP</small> traffic. It is developed by another <small>IETF</small> working
|
||
group, and is also a required part of <small>IP</small> version 6.
|
||
|
||
<p>Again, the main difference between <small>IPSEC</small> and Kerberos and ssh
|
||
is the set of machines that have to be secure and the keys that have to
|
||
be exchanged in order to avoid man-in-the-middle attacks.
|
||
|
||
<p>Current protocols and implementations of <small>IPSEC</small> only provide
|
||
authentication of machines; there's nothing analogous to the user
|
||
authentication in ssh or Kerberos.
|
||
|
||
<p>On the other hand, <small>IPSEC</small> provides one distinct advantage over
|
||
application level encryption. Because <small>IP</small> and <small>TCP</small>
|
||
headers are authenticated, it provides protection against some
|
||
denial-of-service attacks. In particular, it makes attacks that cause
|
||
hangup of a <small>TCP</small> connection considerably more difficult.
|
||
|
||
<p>So it makes sense to use both <small>IPSEC</small> and some application
|
||
level cryptographic protocol.
|
||
|
||
<p>Also note that it is possible to use the <dfn>Point-to-Point Protocol</dfn>
|
||
(<small>PPP</small>) to tunnel arbitrary <small>IP</small> traffic accross an ssh
|
||
connection. This arrangement provides some of the functionality of
|
||
<small>IPSEC</small>, and is sometimes referred to as "a poor man's Virtual
|
||
Private Network".
|
||
|
||
<p><hr>
|
||
Node:<a name="Installation">Installation</a>,
|
||
Next:<a rel=next href="#Getting%20started">Getting started</a>,
|
||
Previous:<a rel=previous href="#Introduction">Introduction</a>,
|
||
Up:<a rel=up href="#Top">Top</a>
|
||
<br>
|
||
|
||
<h1>Installation</h1>
|
||
|
||
<p>You install <code>lsh</code> with the usual <code>./configure && make &&
|
||
make install</code>. For a full listing of the options you can give to
|
||
<code>configure</code>, use <code>./configure --help</code>. For example, use
|
||
<code>--without-pty</code> to disable pty-support.
|
||
|
||
<p>The most commonly used option is <code>--prefix</code>, which tells
|
||
configure where lsh should be installed. Default prefix is
|
||
<code>/usr/local</code>. The <code>lshd</code> server is installed in
|
||
<code>$prefix/sbin</code>, all other programs and scripts are installed in
|
||
<code>$prefix/bin</code>.
|
||
|
||
<p>The configure script tries to figure out if the linker needs any special
|
||
flags specifying where to find dynamically linked libraries at run time
|
||
(one case where this matters is if you have a dynamic libz.so installed
|
||
in a non -standard place). Usually, you can use
|
||
|
||
<pre>./configure --with-lib-path=/opt/lib:/other/place
|
||
</pre>
|
||
|
||
<p>to specify extra library directories, and the configure script should do
|
||
the right thing. If it doesn't work, or you believe that you know your
|
||
system better than <code>./configure</code>, just set LDFLAGS and/or
|
||
LD_LIBRARY_PATH to the right values instead.
|
||
|
||
<p><hr>
|
||
Node:<a name="Getting%20started">Getting started</a>,
|
||
Next:<a rel=next href="#Invoking%20lsh">Invoking lsh</a>,
|
||
Previous:<a rel=previous href="#Installation">Installation</a>,
|
||
Up:<a rel=up href="#Top">Top</a>
|
||
<br>
|
||
|
||
<h1>Getting started</h1>
|
||
|
||
<p>This section tells you how to perform some common tasks using the
|
||
<code>lsh</code> suite of programs, without covering all options and
|
||
possibilities.
|
||
|
||
<ul>
|
||
<li><a href="#lsh%20basics">lsh basics</a>: Connection with lsh
|
||
<li><a href="#tcpip%20forwarding">tcpip forwarding</a>: Forwarding <small>TCP/IP</small> ports
|
||
<li><a href="#lshd%20basics">lshd basics</a>: Starting the lshd deamon
|
||
<li><a href="#public-key">public-key</a>: Using public-keys
|
||
<li><a href="#srp">srp</a>: Using SRP authentication
|
||
<li><a href="#sexp">sexp</a>: Examining keys and other S-exp files.
|
||
<li><a href="#Converting%20keys">Converting keys</a>:
|
||
</ul>
|
||
|
||
<p><hr>
|
||
Node:<a name="lsh%20basics">lsh basics</a>,
|
||
Next:<a rel=next href="#tcpip%20forwarding">tcpip forwarding</a>,
|
||
Previous:<a rel=previous href="#Getting%20started">Getting started</a>,
|
||
Up:<a rel=up href="#Getting%20started">Getting started</a>
|
||
<br>
|
||
|
||
<h2><code>lsh</code> basics</h2>
|
||
|
||
<p><code>lsh</code> is the program you use for connection to a remote machine. A
|
||
few examples are:
|
||
|
||
<pre>lsh sara.lysator.liu.se
|
||
</pre>
|
||
|
||
<p>Connects to <code>sara.lysator.liu.se</code> and starts an interactive shell.
|
||
In this example, and in the rest of the examples in this section, lsh
|
||
will ask for your password, unless you have public-key user
|
||
authentication set up.
|
||
|
||
<p>The first time you try to connect between two machines, <code>lsh</code>
|
||
typically complains about an "unknown host key". This is because it
|
||
has no reason to believe that it was the right machine that answered,
|
||
and not a machine controlled by the enemy (see <a href="#Threats">Threats</a>). The default
|
||
behaviour is to never ever accept a server that is not properly
|
||
authenticated. A machine is considered authentic if it follows the
|
||
protocol and has its public hostkey listed in <code>~/.lsh/known_hosts</code>.
|
||
|
||
<p>To make lsh less paranoid, use
|
||
|
||
<pre>lsh --sloppy-host-authentication sara.lysator.liu.se
|
||
</pre>
|
||
|
||
<p>Then <code>lsh</code> will display a <dfn>fingerprint</dfn> of the host key of the
|
||
remote machine, and ask you if it is correct. If so, the machine is
|
||
considered authentic and its key is appended to the file
|
||
<code>~/.lsh/captured_keys</code>. You can copy keys you have verified to
|
||
<code>~/.lsh/known_hosts</code>.
|
||
|
||
<p>You can even use
|
||
|
||
<pre>lsh --sloppy-host-authentication --capture-to ~/.lsh/known_hosts
|
||
</pre>
|
||
|
||
<p>to get <code>lsh</code> to behave more like the traditional <code>ssh</code> program.
|
||
|
||
<p>You can create fingerprints for the hostkeys you need regularly, and
|
||
keep with you (see <a href="#sexp">sexp</a>).
|
||
|
||
<pre>lsh -l omar sara.lysator.liu.se
|
||
</pre>
|
||
|
||
<p>Connects, like above, but tries to log in as the user "omar".
|
||
|
||
<pre>lsh sara.lysator.liu.se tar cf - some/dir | (cd /target/dir && tar -xf -)
|
||
</pre>
|
||
|
||
<p>Copies a directory from the remote machine, by executing one remote and
|
||
one local <code>tar</code> process and piping them together.
|
||
|
||
<pre>CVS_RSH=lsh cvs -d sara.lysator.liu.se:/lysator/cvsroot co lsh
|
||
</pre>
|
||
|
||
<p>Checks out the <code>lsh</code> source code from the <small>CVS</small>
|
||
repository.
|
||
|
||
<p><hr>
|
||
Node:<a name="tcpip%20forwarding">tcpip forwarding</a>,
|
||
Next:<a rel=next href="#lshd%20basics">lshd basics</a>,
|
||
Previous:<a rel=previous href="#lsh%20basics">lsh basics</a>,
|
||
Up:<a rel=up href="#Getting%20started">Getting started</a>
|
||
<br>
|
||
|
||
<h2>Port forwarding</h2>
|
||
|
||
<p>One useful feature of <code>lsh</code> and other ssh-like programs is the
|
||
ability to forward arbitrary connections inside the encrypted
|
||
connection. There are two flavors: "local" and "remote" forwarding.
|
||
|
||
<p>An example of local forwarding is
|
||
|
||
<pre>lsh -L 4000:kom.lysator.liu.se:4894 sara.lysator.liu.se
|
||
</pre>
|
||
|
||
<p>This makes <code>lsh</code> listen on port 4000 on the <em>local</em> machine. When
|
||
someone connects, <code>lsh</code> asks the server to open a connection from
|
||
the <em>remote</em> machine (i.e. <code>sara</code>) to port 4894 on another machine
|
||
(i.e. <code>kom</code>). The two connections are piped together using an
|
||
encrypted channel.
|
||
|
||
<p>There are a few things that should be noted here:
|
||
|
||
<ul>
|
||
<li>By default, <code>lsh</code> only listens on the loopback interface, so only
|
||
clients on the same machine can use the tunnel. To listen on all
|
||
interfaces, use the <code>-g</code> flag.
|
||
|
||
<li>A connection through the tunnel consists of three parts:
|
||
|
||
<ol type=1 start=1>
|
||
<li>From a client socket to the local port (4000 in this example) that
|
||
<code>lsh</code> listens on.
|
||
|
||
<li>The tunnel itself, from the local machine to the tunnel endpoint,
|
||
which is <code>sara</code> in this example.
|
||
|
||
<li>The connection from the tunnel endpoint to the ultimate target, in this
|
||
example from <code>sara</code> to <code>kom</code>.
|
||
|
||
</ol>
|
||
|
||
<p>Only the middle part is protected by <code>lsh</code>: all data flowing
|
||
through the tunnel is sent across the first and last part <em>in the
|
||
clear</em>. So forwarding doesn't offer much protection unless the tunnel
|
||
endpoint and the ultimate target machine are close to eachother. They
|
||
should usually be either the same machine, or two machines connected by
|
||
a local network that is trusted.
|
||
|
||
</p><li>Port forwarding is very useful for traversing firewalls. Of course, you
|
||
don't need to use lsh-style forwarding just to get out, there are other
|
||
tools like HTTPTunnel for that. But <code>lsh</code> helps you get out through
|
||
the firewall in a secure way.
|
||
|
||
<li>Port forwarding is done in addition to anything else <code>lsh</code> is
|
||
doing. In the example above, a tunnel is set up, but <code>lsh</code> will
|
||
also start an interactive shell for you. Just like the <code>-L</code>
|
||
option was not present. If this is not what you want, the <code>-N</code>
|
||
option is for you (see <a href="#Invoking%20lsh">Invoking lsh</a>)
|
||
</ul>
|
||
|
||
<p>Remote forwarding is similar, but asks the <em>remote</em> machine to
|
||
listen on a port. An example of remote forwarding is
|
||
|
||
<pre>lsh -g -R 8080:localhost:80 sara.lysator.liu.se
|
||
</pre>
|
||
|
||
<p>This asks the remote machine to listen on port 8080 (note that you are
|
||
probably not authorized to listen on port 80). Whenever someone
|
||
connects, the connection is tunnelled to your local machine, and
|
||
directed to port 80 on the same machine. Note the use of <code>-g</code>;
|
||
the effect is to allow anybody in the world to use the tunnel to connect
|
||
to your local webserver.
|
||
|
||
<p>The same considerations that apply to forwarded local ports apply also to
|
||
forwarded remote ports.
|
||
|
||
<p>At last, you can use any number of <code>-L</code> and <code>-R</code> options
|
||
on the same command line.
|
||
|
||
<p><hr>
|
||
Node:<a name="lshd%20basics">lshd basics</a>,
|
||
Next:<a rel=next href="#public-key">public-key</a>,
|
||
Previous:<a rel=previous href="#tcpip%20forwarding">tcpip forwarding</a>,
|
||
Up:<a rel=up href="#Getting%20started">Getting started</a>
|
||
<br>
|
||
|
||
<h2><code>lshd</code> basics</h2>
|
||
|
||
<p>There are no global configuration files for <code>lshd</code>; all
|
||
configuration is done with command line options (see <a href="#Invoking%20lshd">Invoking lshd</a>).
|
||
|
||
<p>To run <code>lshd</code>, you must first create a hostkey, usually stored in
|
||
<code>/etc/lsh_host_key</code>. To do this, run
|
||
|
||
<pre>lsh-keygen | lsh-writekey -o /etc/lsh_host_key
|
||
</pre>
|
||
|
||
<p>This will also create a file <code>/etc/lsh_host_key.pub</code>,
|
||
containing the corresponding public key.
|
||
|
||
<p>A typical command line for starting lshd in daemon mode is simply
|
||
|
||
<pre>lshd --daemonic
|
||
</pre>
|
||
|
||
<p>You can find init script for <code>lshd</code> tailored for Debian's and
|
||
RedHat's GNU/Linux systems in the <code>contrib</code> directory.
|
||
|
||
<p>It is also possible to let <code>init</code> start <code>lshd</code>, by adding it in
|
||
<code>/etc/inittab</code>.
|
||
|
||
<p><hr>
|
||
Node:<a name="public-key">public-key</a>,
|
||
Next:<a rel=next href="#srp">srp</a>,
|
||
Previous:<a rel=previous href="#lshd%20basics">lshd basics</a>,
|
||
Up:<a rel=up href="#Getting%20started">Getting started</a>
|
||
<br>
|
||
|
||
<h2>Using public-key user authentication</h2>
|
||
|
||
<p>Public-key user authentication is a way to authenticate for login,
|
||
without having to type any passwords. There are two steps: Creating a
|
||
key pair, and authorizing the public key to the systems where you want
|
||
to log in.
|
||
|
||
<p>To create a keypair, run
|
||
|
||
<pre>lsh-keygen | lsh-writekey
|
||
</pre>
|
||
|
||
<p>This can take some time, but in the end it creates two files
|
||
<code>~/.lsh/identity</code> and <code>~/.lsh/identity.pub</code>.
|
||
|
||
<p>If you want to use the key to login to some other machine, say
|
||
<code>sara</code>, you can do that by first copying the key,
|
||
|
||
<pre>lsh sara.lysator.liu.se '>my-key.pub' <~/.lsh/identity.pub
|
||
</pre>
|
||
|
||
<p>then authorizing it by executing, on <code>sara</code>,
|
||
|
||
<pre>lsh-authorize my-key.pub
|
||
</pre>
|
||
|
||
<p>For security reasons, you should keep the private key
|
||
<code>~/.lsh/identity</code> secret. Anybody who can read that file will be
|
||
able to login in your name to any machine where the corresponding public
|
||
key is registered as an authorized key.
|
||
|
||
<p>Naturally, you should also make sure not to authorize any keys but your
|
||
own. For instance, it is inappropriate to use an insecure mechanism such
|
||
as unauthenticated email, <code>ftp</code> or <code>http</code> to transfer your
|
||
public key to the machines where you want to authorize it.
|
||
|
||
<p>If you have accounts on several systems, you usually create a single
|
||
keypair on each of the systems, and on each system you authorize some or
|
||
all of your other public keys for login.
|
||
|
||
<p>Note that <code>lsh</code> does <em>not</em> currently encrypt your private
|
||
key in any way. That means that you can lose it if a backup tape gets
|
||
into the wrong hands, and if you use NFS it will likely be sent in the
|
||
clear across your local network. (Actually, you can encrypt the key
|
||
using a pass phrase, by passing the <code>-c 3des</code> option to
|
||
<code>lsh-writekey</code>, but <code>lsh</code> doesn't yet support decrypting
|
||
it).
|
||
|
||
<p><hr>
|
||
Node:<a name="srp">srp</a>,
|
||
Next:<a rel=next href="#sexp">sexp</a>,
|
||
Previous:<a rel=previous href="#public-key">public-key</a>,
|
||
Up:<a rel=up href="#Getting%20started">Getting started</a>
|
||
<br>
|
||
|
||
<h2>Using <small>SRP</small> authentication</h2>
|
||
|
||
<p>The Secure Remote Password protocol is a fairly new protocol that
|
||
provides mutual authentication based on a password. To use it, you must
|
||
first choose a secret password. Next, you create a <dfn>password
|
||
verifier</dfn> that is derived from the password. The verifier is stored on
|
||
the target machine (i.e. the machine you want to log in to).
|
||
|
||
<p>To create a verifier, you run the <code>srp-gen</code> program and type
|
||
your new password. You have to do it on either the target machine,
|
||
redirecting the output to ~/.lsh/srp-verifier, or you can generate it on
|
||
some other machine and copy it to the target.
|
||
|
||
<p>The main advantage of using <small>SRP</small> is that you use the password
|
||
not only to get access to the remote machine, but you also use it to
|
||
authenticate the remote machine. I.e. you can use it to connect
|
||
securely, <em>without</em> having to know any hostkeys or fingerprints
|
||
beforehand!
|
||
|
||
<p>For instance, you could connect using <small>SRP</small> to fetch the hostkey
|
||
fingerprint for the remote machine, as a kind of bootstrapping
|
||
procedure, and then use traditional authentication methods for further
|
||
connections.
|
||
|
||
<p>For this to work, the verifier <em>must</em> be kept <em>secret</em>. If the
|
||
enemy gets your verifier, he can mount some attacks:
|
||
|
||
<ul>
|
||
<li>He can mount a <dfn>dictionary attack</dfn> on your password, i.e. generate a large
|
||
list of likely password and check if any of them matches yours.
|
||
|
||
<li>He can impersonate the server. That means that if you try to connect to
|
||
the remote machine using <small>SRP</small>, and the attacker can intercept
|
||
your connection (e.g. by attacking the name resolution or routing
|
||
system) he can successfully pretend to be the real server.
|
||
</ul>
|
||
|
||
<p>If you use <small>SRP</small> to get the hostkey or fingerprint for the
|
||
remote machine, as outlined above, the impersonation attack destroys
|
||
security, you could just as well connect the hostkey presented by the
|
||
remote server without verifying it at all.
|
||
|
||
<p>If you use <small>SRP</small> exclusively, the situation seems somewhat
|
||
different. As far as I can see, an attacker knowing your verifier can
|
||
not mount a traditional man-in-the-middle-attack: He can play the
|
||
server's part when talking to you, but in order to play your part when
|
||
talking to the real server, he needs to know your password as well.
|
||
|
||
<p><small>SRP</small> support is disabled by default, but can be enabled by the
|
||
<code>--srp-keyexchange</code> option to <code>lshd</code> and <code>lsh</code>
|
||
(naturally, it won't be used unless enabled on both sides). At the time
|
||
of this writing, <small>SRP</small> is too new to be trusted, at least
|
||
according to conservative cryptographers (and remember that conservatism
|
||
is a virtue when it comes to security).
|
||
|
||
<p>And even if <small>SRP</small> in itself is secure, the way <code>lsh</code>
|
||
integrates it into the <code>ssh</code> protocol has not had much peer review.
|
||
The bottom line of this disclaimer is that the <small>SRP</small> support in
|
||
<code>lsh</code> should be considered experimental.
|
||
|
||
<p>As far as I know, <small>SRP</small> is not supported by any other <code>ssh</code>
|
||
implementation. The protocol <code>lsh</code> uses is described in the
|
||
<code>doc/srp-spec.txt</code>.
|
||
|
||
<p><hr>
|
||
Node:<a name="sexp">sexp</a>,
|
||
Next:<a rel=next href="#Converting%20keys">Converting keys</a>,
|
||
Previous:<a rel=previous href="#srp">srp</a>,
|
||
Up:<a rel=up href="#Getting%20started">Getting started</a>
|
||
<br>
|
||
|
||
<h2>Examining keys and other sexp files</h2>
|
||
|
||
<p>Keys and most other objects <code>lsh</code> needs to store on disk are
|
||
represented as so called S-expressions or <dfn>sexps</dfn> for short.
|
||
S-expressions have their roots in the Lisp world, and a variant of them
|
||
are used in the Simple Public Key Infrastructure (<small>SPKI</small>).
|
||
Currently, <code>lsh</code>'s support for <small>SPKI</small> is quite limited,
|
||
but it uses <small>SPKI</small>'s formats for keys and Access Control Lists
|
||
(<small>ACL</small>:s).
|
||
|
||
<p>There are several flavours of the sexp syntax:
|
||
|
||
<ul>
|
||
<li>The canonical syntax is somewhere between a text and a binary format,
|
||
and is extremely easy for programs to read and write.
|
||
|
||
<li>The transport syntax, which is suitable when embedding sexps in text
|
||
files. It is essentially the canonical representation, encoded using
|
||
base64.
|
||
|
||
<li>The advanced syntax, which is intended for humans to read and write, and
|
||
bears some resemblance to Lisp expressions.
|
||
</ul>
|
||
|
||
<p>To see what your <code>~/.lsh/known_hosts</code> file really contains, try
|
||
|
||
<pre>sexp-conv -i advanced < ~/.lsh/known_hosts
|
||
</pre>
|
||
|
||
<p>The <code>sexp-conv</code> program can also be used to computes
|
||
fingerprints. The fingerprint of a key (or any sexp, for that matter) is
|
||
simply the hash of its canonical representation. For example,
|
||
|
||
<pre>sexp-conv --raw-hash </etc/lsh_host_key.pub
|
||
</pre>
|
||
|
||
<p><hr>
|
||
Node:<a name="Converting%20keys">Converting keys</a>,
|
||
Previous:<a rel=previous href="#sexp">sexp</a>,
|
||
Up:<a rel=up href="#Getting%20started">Getting started</a>
|
||
<br>
|
||
|
||
<h2>Converting keys from <code>ssh2</code> and OpenSSH</h2>
|
||
|
||
<p>If you are already using <code>ssh2</code> or OpenSSH, and have creating
|
||
one or more personal keypairs, you need to convert the public keys to
|
||
<code>lsh</code>'s format before you can authorize them. Use the supplied
|
||
<code>ssh-conv</code> script,
|
||
|
||
<pre>ssh-conv <openssh-key.pub >new-key.pub
|
||
</pre>
|
||
|
||
<p>You can then use the usual <code>lsh-authorize</code> on the converted
|
||
keys. For this to work, you must be using <small>DSA</small> keys:
|
||
<code>lsh</code> doesn't support <code>RSA</code>.
|
||
|
||
<p>There is currently no tools for converting private keys.
|
||
|
||
<p><hr>
|
||
Node:<a name="Invoking%20lsh">Invoking lsh</a>,
|
||
Next:<a rel=next href="#Invoking%20lshd">Invoking lshd</a>,
|
||
Previous:<a rel=previous href="#Getting%20started">Getting started</a>,
|
||
Up:<a rel=up href="#Top">Top</a>
|
||
<br>
|
||
|
||
<h1>Invoking <code>lsh</code></h1>
|
||
|
||
<p><a name="lsh-usage"></a>
|
||
|
||
<p>You use <code>lsh</code> to login to a remote machine. Basic usage is
|
||
|
||
<p><code>lsh [-p <var>port number</var>] sara.lysator.liu.se</code>
|
||
|
||
<p>which attempts to connect, login, and start an interactive shell on the
|
||
remote machine. Default <var>port number</var> is whatever your system's
|
||
<code>/etc/services</code> lists for <code>ssh</code>. Usually, that is port 22.
|
||
|
||
<p>There is a plethora of options to <code>lsh</code>, to let you configure where
|
||
and how to connect, how to authenticate, and what you want to do once
|
||
properly logged in to the remote host. Many options have both long and
|
||
short forms. This manual does not list all variants; for a full listing
|
||
of supported options, use <code>lsh --help</code>.
|
||
|
||
<ul>
|
||
<li><a href="#Algorithm%20options">Algorithms</a>: Selecting algorithms.
|
||
<li><a href="#Hostauth%20options">Hostauth options</a>:
|
||
<li><a href="#Userauth%20options">Userauth options</a>:
|
||
<li><a href="#Action%20options">Actions</a>: What to do after login.
|
||
<li><a href="#Verbosity%20options">Messages</a>: Tuning the amount of messages.
|
||
</ul>
|
||
|
||
<p><hr>
|
||
Node:<a name="Algorithm%20options">Algorithm options</a>,
|
||
Next:<a rel=next href="#Hostauth%20options">Hostauth options</a>,
|
||
Previous:<a rel=previous href="#Invoking%20lsh">Invoking lsh</a>,
|
||
Up:<a rel=up href="#Invoking%20lsh">Invoking lsh</a>
|
||
<br>
|
||
|
||
<h2>Algorithm options</h2>
|
||
|
||
<p>Before a packet is sent, each packet can be compressed, encrypted
|
||
and authenticated, in that order. When the packet is received, it is
|
||
first decrypted, next it is checked that it is authenticated properly,
|
||
and finally it is decompressed. The algorithms used for this are
|
||
negotiated with the peer at the other end of the connection, as a part
|
||
of the initial handshake and key exchange.
|
||
|
||
<p>Each party provides a list of supported algorithms, and the first
|
||
algorithm listed by the client, which is also found on the server's
|
||
list, is selected. Note that this implies that order in which algorithms
|
||
are listed on the server's list doesn't matter: if several algorithms
|
||
are present on both the server's and the client's lists, it's the
|
||
client's order that determines which algorithm is selected.
|
||
|
||
<p>Algorithms of different types, e.g. data compression and message
|
||
authentication, are negotiated independently. Furthermore, algorithms
|
||
used for transmission from the client to the server are independent of
|
||
the algorithms used for transmission from the server to the client.
|
||
There are therefore no less than six different lists that could be
|
||
configured at each end.
|
||
|
||
<p>The command line options for lsh and lshd don't let you specify
|
||
arbitrary lists. For instance, you can't specify different preferences
|
||
for sending and receiving.
|
||
|
||
<p>There is a set of default algorithm preferences. When you use a command
|
||
line option to say that you want to use <var>algorithm</var> for one of the
|
||
algorithms, the default list is replaced with a list containing the
|
||
single element <var>algorithm</var>. For example, if you use <code>-c
|
||
arcfour</code> to say that you want to use <code>arcfour</code> as the encryption
|
||
algorithm, the connection will either end up using <code>arcfour</code>, or
|
||
algorithm negotiation will fail because the peer doesn't support
|
||
<code>arcfour</code>.
|
||
|
||
<p><table><tr align="left"><td>Option
|
||
<td>Algorithm type <td>Default <td>
|
||
<br></tr><tr align="left"><td><code>-z</code> <td>Data compression
|
||
<td><code>none</code>, <code>zlib</code>
|
||
|
||
<td>The default preference list supports zlib compression, but
|
||
prefers not to use it.
|
||
|
||
<br></tr><tr align="left"><td><code>-c</code> <td>Encryption
|
||
<td><code>3dec-cbc</code>, <code>blowfish-cbc</code>, <code>arcfour</code>
|
||
<code>arcfour</code>
|
||
|
||
<td>The default encryption algorithm is triple-DES in CBC mode. This
|
||
seems to be the algorithm of choice among conservative cryptographers.
|
||
The default list includes only quite old and well studied algorithms.
|
||
There is a special algorithm name <code>all</code> to enable all supported
|
||
encryption algorithms (except <code>none</code>).
|
||
|
||
<br></tr><tr align="left"><td><code>-m</code> <td>Message Authentication
|
||
<td><code>hmac-sha1</code>, <code>hmac-md5</code>
|
||
|
||
<td>Both supported message authentication algorithms are of the
|
||
<small>HMAC</small> family.
|
||
<br></tr></table>
|
||
|
||
<p>As a special case, <code>-z</code> with no argument changes the compression
|
||
algorithm list to <code>zlib</code>, <code>none</code>, which means that you want to
|
||
use <code>zlib</code> if the other end supports it. This is different from
|
||
<code>-zzlib</code> which causes the negotiation to fail if the other end
|
||
doesn't support <code>zlib</code>. A somewhat unobvious consequence of
|
||
<code>-z</code> having an <em>optional</em> argument is that if you provide an
|
||
argument, it must follow directly after the option letter, no spaces
|
||
allowed.
|
||
|
||
<p><hr>
|
||
Node:<a name="Hostauth%20options">Hostauth options</a>,
|
||
Next:<a rel=next href="#Userauth%20options">Userauth options</a>,
|
||
Previous:<a rel=previous href="#Algorithm%20options">Algorithm options</a>,
|
||
Up:<a rel=up href="#Invoking%20lsh">Invoking lsh</a>
|
||
<br>
|
||
|
||
<h2>Host authentication options</h2>
|
||
|
||
<p>As described earlier (see <a href="#Threats">Threats</a>), proper authentication of the
|
||
remote host is crucial to protect the connection against
|
||
man-in-the-middle attacks. By default, <code>lsh</code> verifies the server's
|
||
claimed host key against the <dfn>Access Control Lists</dfn> in
|
||
<code>~/.lsh/known_hosts</code>. If the remote host cannot be authenticated,
|
||
the connection is dropped.
|
||
|
||
<p>The options that change this behaviour are
|
||
|
||
<dl>
|
||
<dt><code>--host-db</code>
|
||
<dd>Specifies the location of the <small>ACL</small> file.
|
||
|
||
<br><dt><code>--sloppy-host-authentication</code>
|
||
<dd>Tell <code>lsh</code> not to drop the connection if the server's key can not
|
||
be authenticated. Instead, it displays the fingerprint of the key, and
|
||
asks if it is trusted. The received key is also appended to the file
|
||
<code>~/.lsh/captured_keys</code>. If run in quiet mode, <code>lsh -q
|
||
--sloppy-host-authentication</code>, <code>lsh</code> connects to any host, no
|
||
questions asked.
|
||
|
||
<br><dt><code>--strict-host-authentication</code>
|
||
<dd>Disable sloppy operation (this is the default behaviour).
|
||
|
||
<br><dt><code>--capture-to</code>
|
||
<dd>Use some other file than <code>~/.lsh/captured_keys</code>. For example,
|
||
|
||
<pre>lsh --sloppy-host-authentication --capture-to ~/.lsh/known_hosts
|
||
</pre>
|
||
|
||
<p>makes <code>lsh</code> behave more like the <code>ssh</code> program.
|
||
|
||
<br><dt><code>--srp-keyexchange</code>
|
||
<dd>Try using <small>SRP</small> for keyexchange and mutual authentication.
|
||
|
||
</dl>
|
||
|
||
<p><hr>
|
||
Node:<a name="Userauth%20options">Userauth options</a>,
|
||
Next:<a rel=next href="#Action%20options">Action options</a>,
|
||
Previous:<a rel=previous href="#Hostauth%20options">Hostauth options</a>,
|
||
Up:<a rel=up href="#Invoking%20lsh">Invoking lsh</a>
|
||
<br>
|
||
|
||
<h2>User authentication options</h2>
|
||
|
||
<dl>
|
||
|
||
<br><dt><code>-l</code>
|
||
<dd>Provide a name to use when logging in. By default, the value of the
|
||
<code>LOGNAME</code> environment variable is used.
|
||
|
||
<br><dt><code>-i</code>
|
||
<dd>Try the keys from this file to log in. By default, <code>lsh</code> uses
|
||
<code>~/.lsh/identity</code>, if it exists. It ought to be possible to use
|
||
several <code>-i</code> options to use more than one file, but that is
|
||
currently not implemented.
|
||
|
||
<br><dt><code>--no-publickey</code>
|
||
<dd>Don't attempt to log in using public key authentication.
|
||
|
||
<br><dt><code>--no-userauth</code>
|
||
<dd>Attempt to start a session without performing the user authentication
|
||
sub-protocol at all. This is the default if <small>SRP</small> was used for
|
||
the initial handshake, and should not make much sense otherwise.
|
||
|
||
</dl>
|
||
|
||
<p><hr>
|
||
Node:<a name="Action%20options">Action options</a>,
|
||
Next:<a rel=next href="#Verbosity%20options">Verbosity options</a>,
|
||
Previous:<a rel=previous href="#Userauth%20options">Userauth options</a>,
|
||
Up:<a rel=up href="#Invoking%20lsh">Invoking lsh</a>
|
||
<br>
|
||
|
||
<h2>Action options</h2>
|
||
|
||
<p>There are many things <code>lsh</code> can do once you are logged in. There
|
||
are two types of options that control this: <dfn>actions</dfn> and
|
||
<dfn>action modifiers</dfn>. For short options, actions use uppercase letters
|
||
and modifiers use lowercase.
|
||
|
||
<p>For each modifier <code>--foo</code> there's also a negated form
|
||
<code>--no-foo</code>. Options can also be negated be preceding it with the
|
||
special option <code>-n</code>. This is mainly useful for negating short
|
||
options. For instance, use <code>-nt</code> to tell <code>lsh</code> not to
|
||
request a remote pseudo terminal. Each modifier and its negation can be
|
||
used several times on the command line. For each action, the latest
|
||
previous modifier of each pair apply.
|
||
|
||
<p>First, the actions:
|
||
|
||
<dl>
|
||
|
||
<br><dt><code>-L</code>
|
||
<dd>Requests forwarding of a local port. This option takes mandatory
|
||
argument of the form
|
||
<var>listen-port</var>:<var>target-host</var>:<var>target-port</var>. This option tells
|
||
<code>lsh</code> to listen on <var>listen-port</var> on the local machine. When
|
||
someone conects to that port, <code>lsh</code> asks the remote server to open
|
||
a connection to <var>target-port</var> on <var>target-host</var>, and if it
|
||
succeeds, the two connections are joined together through an the
|
||
<code>lsh</code> connection. Both port numbers should be given in decimal.
|
||
|
||
<br><dt><code>-R</code>
|
||
<dd>Requests forwarding of a remote port. It takes one mandatory argument,
|
||
just like <code>-L</code>. But in this case <code>lsh</code> asks the
|
||
<em>remote</em> server to listen on <var>listen-port</var>. When someone
|
||
connects to the remote hosts, the server will inform the local
|
||
<code>lsh</code>. The local <code>lsh</code> then connects to <var>target-port</var> on
|
||
<var>target-host</var>.
|
||
|
||
<br><dt><code>-E</code>
|
||
<dd>This option takes one mandatory argument, which is a command line to be
|
||
executed on the remote machine.
|
||
|
||
<br><dt><code>-S</code>
|
||
<dd>Start an interactive shell on the remote machine.
|
||
|
||
<br><dt><code>-G</code>
|
||
<dd>Open a gateway on the local machine. A gateway is a local socket,
|
||
located under /tmp, that can be used for controlling and using the ssh
|
||
connection. It is protected using the ordinary file permissions. This
|
||
feature is experimental.
|
||
|
||
<br><dt><code>-N</code>
|
||
<dd>This is a no-operation action. It inhibits the default action, which is
|
||
to start an interactive shell on the remote machine. It is useful if you
|
||
want to set up a few forwarded tunnels, and nothing more.
|
||
|
||
</dl>
|
||
|
||
<p>If there are trailing arguments after the name of the remote system,
|
||
this is equivalent to a <code>-E</code> option, with a command string
|
||
constructed by catenating all the remaining arguments, separated by
|
||
spaces. This implies that the arguments are usually expanded first by
|
||
the local shell, and then the resulting command string is interpreted
|
||
again by the remote system.
|
||
|
||
<p>If there are no trailing arguments after the name of the remote system,
|
||
and the <code>-N</code> option is not given, the default action is to start
|
||
a shell on the remote machine. I.e. this is equivalent to the
|
||
<code>-S</code> option.
|
||
|
||
<p>There are a few supported modifiers:
|
||
|
||
<dl>
|
||
|
||
<br><dt><code>-t</code>
|
||
<dd>Request a pseudo terminal. <code>lsh</code> asks the remote system to allocate
|
||
a pseudo terminal. If it succeeds, the local terminal is set to raw
|
||
mode. The default behaviour is to request a pty if and only if the
|
||
local <code>lsh</code> process has a controlling terminal. This modifier
|
||
applies to actions that create remote processes, i.e. <code>-E</code> and
|
||
<code>-S</code>, as well as the default actions.
|
||
|
||
<p>Currently, this option is ignored if there is no local terminal.
|
||
|
||
<br><dt><code>--stdin</code>
|
||
<dd>Redirect the stdin of a remote process from a given, local, file.
|
||
Default is to use <code>lsh</code>'s stdin for the first process, and
|
||
<code>/dev/null</code> for the rest. This option applies to the <code>-E</code>
|
||
and <code>-S</code> options as well as to the default actions. The option
|
||
applies to only one process; as soon as it is used it is reset to the
|
||
default.
|
||
|
||
<br><dt><code>--stdout</code>
|
||
<dd>Redirect the stdout of a remote process to a given, local, file. Default
|
||
is to use <code>lsh</code>'s stdout. Like <code>--stdin</code>, it is reset
|
||
after it is used.
|
||
|
||
<br><dt><code>--stderr</code>
|
||
<dd>Redirect the stdout of a remote process to a given, local, file.
|
||
Analogous to the <code>--stdout</code> option.
|
||
|
||
<br><dt><code>-g</code>
|
||
<dd>Remote peers, aka Global forwarding. This option applies to the
|
||
forwarding actions, i.e. <code>-L</code> and <code>-R</code>. By default, only
|
||
connections to the loopback interface, ip 127.0.0.1, are forwared. This
|
||
implies that only processes on the same machine can use the forwarded
|
||
tunnel directly. If the -g modifier is in effect, the forwarding party
|
||
will listen on <em>all</em> network interfaces.
|
||
|
||
</dl>
|
||
|
||
<p><hr>
|
||
Node:<a name="Verbosity%20options">Verbosity options</a>,
|
||
Previous:<a rel=previous href="#Action%20options">Action options</a>,
|
||
Up:<a rel=up href="#Invoking%20lsh">Invoking lsh</a>
|
||
<br>
|
||
|
||
<h2>Verbosity options</h2>
|
||
|
||
<p>These options determines what messages <code>lsh</code> writes on
|
||
its stderr.
|
||
|
||
<dl>
|
||
|
||
<br><dt><code>-q</code>
|
||
<dd>Quiet mode. Disables all messages and all questions, except password
|
||
prompts and fatal internal errors.
|
||
|
||
<br><dt><code>-v</code>
|
||
<dd>Verbose mode. Makes <code>lsh</code> a little more verbose. The intention is
|
||
to provide information that is useful for ordinary trouble shooting,
|
||
and makes sense also to those not familiar with <code>lsh</code> internals.
|
||
|
||
<br><dt><code>--trace</code>
|
||
<dd>Trace mode. Prints some internal information to aid tracking
|
||
<code>lsh</code>'s flow of control.
|
||
|
||
<br><dt><code>--debug.</code>
|
||
<dd>Debug mode. Dumps <em>a lot</em> of information, including dumps of all
|
||
sent and received packets. It tries to avoid dumping highly sensitive data,
|
||
such as private keys and the contents of <code>SSH_MSG_USERAUTH_REQUEST</code>
|
||
messages, but you should still use it with care.
|
||
|
||
</dl>
|
||
|
||
<p>Note that all these options are orthogonal. If you use <code>--trace</code>,
|
||
you usually want to add <code>-v</code> as well; <code>--trace</code> does not
|
||
do that automatically.
|
||
|
||
<p><hr>
|
||
Node:<a name="Invoking%20lshd">Invoking lshd</a>,
|
||
Next:<a rel=next href="#Terminology">Terminology</a>,
|
||
Previous:<a rel=previous href="#Invoking%20lsh">Invoking lsh</a>,
|
||
Up:<a rel=up href="#Top">Top</a>
|
||
<br>
|
||
|
||
<h1>Invoking <code>lshd</code></h1>
|
||
|
||
<p><a name="lshd-usage"></a>
|
||
|
||
<p><code>lshd</code> is a server that accepts connections from clients
|
||
speaking the Secure Shell Protocol. It is usually started automatically
|
||
when the systems boots, and runs with root privileges. However, it is
|
||
also possible to start <code>lshd</code> manually, and with user
|
||
privileges.
|
||
|
||
<p>There are currently no configuration files. Instead, command line options
|
||
are used to tell <code>lshd</code> what to do. Many options have <code>--foo</code>
|
||
and <code>--no-foo</code> variants. Options specifying the default behaviour
|
||
are not listed here.
|
||
|
||
<p>Some of the options are the shared with <code>lsh</code>. In particular, see
|
||
<a href="#Algorithm%20options">Algorithm options</a> and <a href="#Verbosity%20options">Verbosity options</a>.
|
||
|
||
<p>Options specific to the <code>lshd</code> server are:
|
||
|
||
<dl>
|
||
|
||
<br><dt><code>-p</code>
|
||
<dd>Port to listen to. The mandatory argument is a decimal port number or a
|
||
service name. Default is "ssh", usually port 22.
|
||
|
||
<br><dt><code>--interface</code>
|
||
<dd>Network interface to listen on. By default, <code>lshd</code> listens on all
|
||
interfaces.
|
||
|
||
<br><dt><code>-h</code>
|
||
<dd>Location of the server's private key file. By default,
|
||
<code>/etc/lsh_host_key</code>.
|
||
|
||
<br><dt><code>-i</code>
|
||
<dd>Variant of the s-expression syntax to use when reading the host key.
|
||
Default is to use transport format. Not a terribly useful option.
|
||
|
||
<br><dt><code>--ssh1-fallback</code>
|
||
<dd>This options enables fallback to <code>ssh1</code>. <code>lshd</code> doesn't
|
||
implement version 1 of the Secure Shell Protocol. But it can fork an
|
||
<code>ssh1</code> server when an old client connects. Falling back to
|
||
<code>ssh1</code> is inefficient, and requires some special features of the
|
||
server fallen back to. It should work with the <code>sshd</code> daemon
|
||
supplied with reasonably new versions of F-Secure's <code>sshd1</code>,
|
||
and with OpenSSH.
|
||
|
||
<p>The optional argument provides the filename of the ssh1 daemon to use.
|
||
The default name is <code>/usr/local/sbin/sshd1</code>, unless something else
|
||
was configured at compile time.
|
||
|
||
<br><dt><code>--daemonic</code>
|
||
<dd>Enables daemonic mode. <code>lshd</code> forks into the background,
|
||
redirects its stdio file descriptors to <code>/dev/null</code>, changes its
|
||
working directory to <code>/</code>, and redirects any diagnostic or debugging
|
||
messages via syslog.
|
||
|
||
<p><code>lshd</code> should be able to deal with the environment it inherits
|
||
if it is started by <code>init</code> or <code>inetd</code>, but this is not
|
||
really tested.
|
||
|
||
<br><dt><code>--pid-file</code>
|
||
<dd>Creates a locked pid file, to make it easier to write start and stop
|
||
scripts for <code>lshd</code>. The mandatory argument provides the filename.
|
||
This option is enabled by default when operating in daemonic mode, and
|
||
the default filename is <code>/var/run/lshd.pid</code>.
|
||
|
||
<br><dt><code>--enable-core</code>
|
||
<dd>By default, <code>lshd</code> disables core dumps, to avoid leaking sensitive
|
||
information. This option changes that behaviour, and allows <code>lshd</code>
|
||
to dump core on fatal errors.
|
||
|
||
<br><dt><code>--no-password</code>
|
||
<dd>Disable the "password" user authentication mechanism.
|
||
|
||
<br><dt><code>--no-publickey</code>
|
||
<dd>Disable the "publickey" user authentication mechanism.
|
||
|
||
<br><dt><code>--root-login</code>
|
||
<dd>Enable root login. By default, root can not log in using <code>lshd</code>.
|
||
|
||
<br><dt><code>--kerberos-passwords</code>
|
||
<dd>Verify passwords against the kerberos database. This is implemented
|
||
using the <code>lsh-krb-checkpw</code> helper program. Note that this does
|
||
<em>not</em> use the Kerberos infrastructure in the Right Way. Experimental.
|
||
|
||
<br><dt><code>--password-helper</code>
|
||
<dd>Tells <code>lshd</code> to use a helper program for verifying passwords.
|
||
This is a generalization of <code>--kerberos-passwords</code>, and it could
|
||
be used for verifying passwords against any password database. See the
|
||
source files <code>lsh-krb-checkpw.c</code> and <code>unix_user.c</code> for
|
||
details.
|
||
|
||
<br><dt><code>--login-shell</code>
|
||
<dd>Use the specified program as the login shell for all users, overriding
|
||
the login shell in the passwd database.
|
||
|
||
<br><dt><code>--srp-keyexchange</code>
|
||
<dd>Enable <small>SRP</small> keyexchange and user authentication.
|
||
|
||
<br><dt><code>--no-pty-support</code>
|
||
<dd>Disable support for pseudo terminals.
|
||
|
||
<br><dt><code>--no-tcp-forward</code>
|
||
<dd>Disable support for tcp forwarding, in both directions.
|
||
|
||
</dl>
|
||
|
||
<p><hr>
|
||
Node:<a name="Terminology">Terminology</a>,
|
||
Next:<a rel=next href="#Concept%20Index">Concept Index</a>,
|
||
Previous:<a rel=previous href="#Invoking%20lshd">Invoking lshd</a>,
|
||
Up:<a rel=up href="#Top">Top</a>
|
||
<br>
|
||
|
||
<h1>Terminology</h1>
|
||
|
||
<p><hr>
|
||
Node:<a name="Concept%20Index">Concept Index</a>,
|
||
Previous:<a rel=previous href="#Terminology">Terminology</a>,
|
||
Up:<a rel=up href="#Top">Top</a>
|
||
<br>
|
||
|
||
<h1>Concept Index</h1>
|
||
|
||
<ul compact>
|
||
</ul>
|
||
|
||
<h1>Table of Contents</h1>
|
||
<ul>
|
||
<li><a href="#Top"></a>
|
||
<li><a href="#Introduction">Introduction</a>
|
||
<ul>
|
||
<li><a href="#Threats">Threats</a>
|
||
<li><a href="#Features">Features</a>
|
||
<li><a href="#Related%20techniques">Related programs and techniques</a>
|
||
<ul>
|
||
<li><a href="#ssh1"><code>ssh-1.x</code></a>
|
||
<li><a href="#ssh2"><code>ssh-2.x</code></a>
|
||
<li><a href="#Kerberos">Kerberos</a>
|
||
<li><a href="#ipsec"><small>IPSEC</small></a>
|
||
</ul>
|
||
</ul>
|
||
<li><a href="#Installation">Installation</a>
|
||
<li><a href="#Getting%20started">Getting started</a>
|
||
<ul>
|
||
<li><a href="#lsh%20basics"><code>lsh</code> basics</a>
|
||
<li><a href="#tcpip%20forwarding">Port forwarding</a>
|
||
<li><a href="#lshd%20basics"><code>lshd</code> basics</a>
|
||
<li><a href="#public-key">Using public-key user authentication</a>
|
||
<li><a href="#srp">Using <small>SRP</small> authentication</a>
|
||
<li><a href="#sexp">Examining keys and other sexp files</a>
|
||
<li><a href="#Converting%20keys">Converting keys from <code>ssh2</code> and OpenSSH</a>
|
||
</ul>
|
||
<li><a href="#Invoking%20lsh">Invoking <code>lsh</code></a>
|
||
<ul>
|
||
<li><a href="#Algorithm%20options">Algorithm options</a>
|
||
<li><a href="#Hostauth%20options">Host authentication options</a>
|
||
<li><a href="#Userauth%20options">User authentication options</a>
|
||
<li><a href="#Action%20options">Action options</a>
|
||
<li><a href="#Verbosity%20options">Verbosity options</a>
|
||
</ul>
|
||
<li><a href="#Invoking%20lshd">Invoking <code>lshd</code></a>
|
||
<li><a href="#Terminology">Terminology</a>
|
||
<li><a href="#Concept%20Index">Concept Index</a>
|
||
</ul>
|
||
|
||
|
||
</body></html>
|
||
|