|
Softpanorama
(slightly skeptical)
Open Source Software Educational Society |
May the
source be with you,
but remember the KISS principle ;-)
|
Authentication without password:
password-less SSH login
When a user connects via SSH, he must prove his identity to the remote
machine using one of several methods. A common question usually arise: "How
can I access a remote host without entering a password at each login?".
Normally, when you log in to a system, you authenticate by entering your
password for that system. Your password goes, as it is typed, to the remote
system, which authenticates it against the /etc/passwd
or /etc/shadow file. By contrast, SSH
allow a "password-less" authentication method based on public-key cryptography.
If you are unfamiliar with public-key cryptography, see
the link or read the PGP Manual
SSH provides two solutions to allow remote logins without password:
- /etc/shosts.equiv and
.shosts method which is similar to
the method using /etc/hosts.equiv and /.rhosts. This form of authentication
should not be allowed because it is not secure. However this weak authentication
method can be combined with RSA-based host authentication where the
client's host key is checked with the known_hosts
file of the remote machine.
- The solution based on the public cryptography:
- First the user need to create his key pair using
ssh-keygen.
- The private key is stored in ~/.ssh
or other directory, depending on the client used (in Windows usually
Putty or
Teraterm are used
and private key can be stored in their directories or subdirectory
underneath)
- The public key in the file ~/.ssh/authorised_keys
on the server.
Note: The access to both
authorized_keys and client-based
private key must be restricted. They should
have permissions 600 on Unix.
Usually the user created the pair on the server and then copy his private
key to the client. After that there are two steps to ensure successful
authentication.
A private/public keys pair is generated using
ssh-keygen command line utility(See
below). The user will be prompted three times
during the generation of the keys: once for the name of the output file
and twice for the passphrase, just hit enter three times.
During a login, SSH will look for a file named
authorized_keys in the user's
~/.ssh directory. This file
contains the keys of users allowed to login to this account. Essentially,
it's a challenge-response mechanism: You can authenticate against a public
key on the server, so when the client connects, the server encrypts a random
number with the public key. If the client possesses the private key, then
it can decrypt the random number and report it back to the server. That
proves to the server that the person logging in has the authorized private
key.
The private key can be further protected when you encrypt it with a password.
The password you type to authenticate via public key cryptography is the
password for your private key.
As we already mentioned the critical part of this authentication scheme
is a pair of public and private keys. The ssh-keygen
command is used to generate them. Here there are several options as there
are several versions of the SSH protocol and OpenSSH 2.5 and higher can
generate three different types of keys:
- rsa1, for compatibility with SSH version 1 clients;
- DSA, for connecting to SSH protocol version 2 clients using the
Digital Signature Algorithm;
- RSA, for connecting to SSH protocol version 2 clients using the
standard RSA algorithm.
My understanding is that RSA was in SSH1, DSA was introduced in SSH2, then
RSA was added back into SSH2. Ususally with ssh2 RSA is used. Here is an
excerpt from
Bruce
Schneier's Crypto-Gram for November 15, 1999:
The security of most other public-key algorithms -- ElGamal, DSA, etc.
-- is based on the discrete logarithm problem. The two problems are
very similar, and all of the modern factoring algorithms can be used
to calculate discrete logarithms in the multiplicative group of a finite
field. To a rough approximation, factoring a number of a certain size
and calculating the discrete logarithm of numbers the same size takes
the same amount of work. This means that
for a given key size, RSA, ElGamal, DSA, etc. are approximately equally
secure. (This isn't strictly true, but it's a good enough
approximation for this essay.)
You can set the type of key SSH generates with the
-t option. Thus to generate your rsa1 public
and private key pair, you would run ssh-keygen -t
rsa1. For the three key types, the keys generated are by default
stored in your .ssh directory beneath
your home directory. The rsa1 keys are
named identity, DSA keys are named
id_dsa, and protocol version 2 RSA keys
are named id_rsa. Each key has a corresponding
public key has a .pub extension. You
want to check the permissions on the private keys and make sure that they're
not world-readable; these are secrets not intended for sharing.
To allow authentication, you must make the public key available on the
computer into which you would like to log in.
- For rsa1 keys, the name of the file into which you put the public
key is
$HOME/.ssh/authorized_keys.
- For SSH protocol version 2 keys (both RSA and DSA), the file is
$HOME/.ssh/authorized_keys2. Each
public key is a single line, so you can use
scp to copy the public keys to the
destination system and then, on the remote system, type
cat id_dsa.pub >> .ssh/authorized_keys2.
After that you can authenticate without sending any sort of password
over the network. (The private key is decrypted on the client only.)
All that is very useful, as you can set your system to require authentication
only once. You can do that with the SSH authentication agent, ssh-agent.
The ssh-agent syntax is rather strange: because it must set some shell variables,
you must use eval `ssh-agent`. The ssh-agent
tries to determine the shell syntax necessary, but occasionally it fails
and you need to pass it the -s option for Bourne shell derivatives such
as ksh and zsh, or the -c option for C Shell derivatives.
You must execute the ssh-agent in your top-level shell for maximum usability.
For a console or ssh-based session that means in your top login shell or,
for X-based sessions, in your .Xclients or another startup script. In either
case, you must kill the ssh-agent with ssh-agent -k
prior to quitting, or lots of startup files will be left around.
The ssh-agent only manages keys; you have to tell it which keys to use.
To do that, you can ssh-add private-key-file,
where private-key-file is
$HOME/.ssh/id_dsa or one of your other private
keys. Once you type the passphrase for your key, ssh-agent remembers it
and automatically handles the key requests from new SSH sessions. To handle
all contingencies, I add all three of my keys at login time and forget about
it until I'm ready to quit. I end up typing three passwords, and then I
need not enter any more passwords for the rest of the day.
If I plan on connecting through one server to another server, I connect
via SSH to that first server with the -A option, which allows the server
to pass any authentication requests it gets back to the initial client.
(You can make that operation the default by setting
ForwardAgent yes in your ssh configuration
file. The per-user configuration file is $HOME/.ssh/config,
and the systemwide configuration file is usually in
/etc/ssh/ssh_config depending on how you installed
OpenSSH.
here are a couple of additional tips: you don't need to create the .ssh
direrectory yourself, ssh-keygen will do that for you if its unable to find
it.
And to copy keys:
ssh-copy-id -i .ssh/id_rsa remoteuser@remote.host
You can also use ssh-copy-id to copy over your key to the remote host
as well. If no .ssh directory or authorized_keys
This mini-howto explains how to set up an SSH server on Debian Etch
with public-key authorization (and optionally with disabled password
logins). SSH is a great tool to control Linux-based computers remotely.
It's safe and secure.There's no warranty that it'll work for you.
All of these settings are applicable for Debian and -like systems! There
may be slightly changes on other systems as well.
... ... ...
On your desktop machine, we install the ssh client (which we use to
connect the server). Note that installing programs requires
root privilege! If you're not logged in
as root, please log in! (su
root then type your password.) Then install the client:
apt-get install openssh-client
Switch back to your normal user (not root,
respectively). Then type these commands in order:
mkdir ~/.ssh
chmod 700 ~/.ssh
cd ~/.ssh
We generate our key-pair, a public-key and a private-key. The public-key
will be placed on the server, and you will log in with your private-key.
When asked, type your passphrase (it'll be needed for future logins,
so remember it!):
ssh-keygen -t rsa -C "A comment... usually an email
is enough here..."
Then we copy the public key (which we've generated just before) to
our (remote) server. The remoteuser should not be
root! Choose the default non-root user as
remoteuser. (Note the colon at the end of the line! It's important.)
scp -p id_rsa.pub remoteuser@remotehost:
Then we log in with SSH, and we copy the public key to its right
place:
ssh remoteuser@remotehost
mkdir ~/.ssh
chmod 700 ~/.ssh
cat id_rsa.pub >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys
mv id_rsa.pub ~/.ssh
logout
We have to delete the public key on the desktop, because otherwise
the SSH client doesn't allow us to log in to the server. So, type this
command:
rm id_rsa.pub
And then we log back:
ssh remoteuser@remotehost
If we've done everything precisely as detailed above, then you'll
be asked for the passphrase. Type it, then you are in and have a fairly
safe SSH-environment!
Disabling Password Authentication
Disabling it is a good way to have a safer SSH-installation. Then
you can log in only with a key-pair, so be careful not to lose
it! It's purely optional but safe to activate! But before doing it,
please make sure that key-based authentication is working out-of-the-box.
Sit down in front the server (so don't log in remotely as we have to
restart the SSH later...) and type these commands manually as
root:
cd /etc/ssh
cp sshd_config sshd_config.orig
nano sshd_config
You will have the nano text-editor on screen open with the main SSH
configuration file. Change these lines (don't bother if any of these
lines have a '#' mark at the beginning; if they have, just delete the
hashmark as well):
PermitRootLogin yes
PasswordAuthentication yes
UsePAM yes
Some good ideas about troubleshooting in replies
I followed this HowTo
http://www.debian-administration.org/articles/152 and I've read
numerous threads here at LQ and on the web but I cannot get this to
function!
I want passwordless logons for root access to work and client servers.
I have set up an RSA key on my box for user@user-desktop (the basic
Kubuntu machine name) and I copied/added the rsa_id_nopass.pub file
to the end of the destination server's ~/.ssh/authorized_keys2 file,
but it still isn't working; I am asked for a password (not passphrase)
every time.
I have edited the ssh_config file (both on local machine and server)
to use
RSAAuthentication yes
PubkeyAuthentication yes
and restarted the sshd server on both machines.
I want to get root access for servers when I log in using these keys.
Unfortunately it isn't giving me root or regular user access at all;
'ssh root@server' is acting like it would had none of my work been done.
My system is Kubuntu 7.04 and the test server is a RedHat Enterprise
Linux 9, but the key setup would eventually go onto a few debian servers
and RHEL servers. I also am failing to get this to function on two Kubuntu
7.04 boxes (one is at home, one is at work (this setup is for two regular
user accounts, not root accounts)). Does this
whole setup require that the user name is identical on both machines???
Cause that's just a pain if I have to become root just to not enter
a root password five seconds later.
Thanks for any advice
====
It sounds like you've checked everything. Create the key pair; put
public key in the remote box's ~/.ssh/authorized_keys2 file. Check that
the remote ~/.ssh directory is chmod 700. The private key applies as
long as you are currently running on the local box as the user you created
the key for; the same user that has it in their ~/.ssh directory. You
also have to be logging in as the user on the remote box that you created
the ~/.ssh/authorized_keys2 file for.
Otherwise, everything you've done sounds correct. If things still don't
work just post the line that created your key here, and we'll try to
help you out some more.
Regards,
Alunduil
===
Try copying ~/.ssh/authorized_keys2 to ~/.ssh/authorized_keys.
Par Pierrick, vendredi 7 septembre 2007 à 16:12
/ categorie:
A long time ago, I've tried to use connect to a SSH server with my
private key in a batch mode (with a cron task). I didn't find the way
to do it. Now I have. It is as simple as to have no passphrase
on your private key. Less secure (but still much more secure
than FTP connection) but makes SSH possible in cron task.
$ ssh-keygen -t dsa
Generating public/private dsa key pair.
Enter file in which to save the key (/home/pierrick/.ssh/id_dsa): /home/pierrick/.ssh/id_dsa2
Enter passphrase (empty for no passphrase):
Enter same passphrase again: /home/pierrick/.ssh/id_dsa2.pub.
Your identification has been saved in /home/pierrick/.ssh/id_dsa2.
Your public key has been saved in /home/pierrick/.ssh/id_dsa2.pub.
Add the content of /home/pierrick/.ssh/id_dsa2.pub into remote
~/.ssh/authorized_keys
$ export EDITOR=vi; crontab -e
* * * * * ssh -i /home/pierrick/.ssh/id_dsa2 remote_user@remote_server 'echo $(date) >> /tmp/pierrick.log'
And see that every second, the date is appended to the remote
/tmp/pierrick.log
Trackbacks
Aucun trackback.
Les trackbacks pour ce billet sont fermés.
Because OpenSSH allows you to run commands on remote systems, showing
you the results directly, as well as just logging in to systems it's
ideal for automating common tasks with shellscripts and cronjobs. One
thing that you probably won't want is to do though is store the remote
system's password in the script. Instead you'll want to setup SSH so
that you can login securely without having to give a password.Thankfully
this is very straightforward, with the use of public keys.
To enable the remote login you create a pair of keys, one of which
you simply append to a file upon the remote system. When this is done
you'll then be able to login without being prompted for a password -
and this also includes any
cronjobs
you have setup to run.
If you don't already have a keypair generated you'll first of all
need to create one.
If you do have a keypair handy already you can keep using that, by
default the keys will be stored in one of the following pair of files:
- ~/.ssh/identity and ~/.ssh/identity.pub
- (This is an older DSA key).
- ~/.ssh/id_rsa and ~/.ssh/id_rsa.pub
- (This is a newer RSA key).
If you have neither of the two files then you should generate one.
The DSA-style keys are older ones, and should probably be ignored in
favour of the newer RSA keytypes (unless you're looking at connecting
to an outdated installation of OpenSSH). We'll use the RSA keytype in
the following example.
To generate a new keypair you run the following command:
skx@lappy:~$ ssh-keygen -t rsa
This will prompt you for a location to save the keys, and a pass-phrase:
Generating public/private rsa key pair.
Enter file in which to save the key (/home/skx/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/skx/.ssh/id_rsa.
Your public key has been saved in /home/skx/.ssh/id_rsa.pub.
If you accept the defaults you'll have a pair of files created, as
shown above, with no passphrase. This means that the key files can be
used as they are, without being "unlocked" with a password first. If
you're wishing to automate things this is what you want.
Now that you have a pair of keyfiles generated, or pre-existing,
you need to append the contents of the .pub file to the correct
location on the remote server.
Assuming that you wish to login to the machine called mystery
from your current host with the id_rsa and id_rsa.pub
files you've just generated you should run the following command:
ssh-copy-id -i ~/.ssh/id_rsa.pub username@mystery
This will prompt you for the login password for the host, then copy
the keyfile for you, creating the correct directory and fixing the permissions
as necessary.
The contents of the keyfile will be appended to the file ~/.ssh/authorized_keys2
for RSA keys, and ~/.ssh/authorised_keys for the older DSA
key types.
Once this has been done you should be able to login remotely, and
run commands, without being prompted for a password:
skx@lappy:~$ ssh mystery uptime
09:52:50 up 96 days, 13:45, 0 users, load average: 0.00, 0.00, 0.00
What if it doesn't work?
There are three common problems when setting up passwordless
logins:
- The remote SSH server hasn't been setup to allow public
key authentication.
- File permissions cause problems.
- Your keytype isn't supported.
Each of these problems is easily fixable, although the first
will require you have root privileges upon the remote host.
If the remote server doesn't allow public key based logins you
will need to updated the SSH configuration. To do this edit the
file /etc/sshd/sshd_config with your favourite text editor.
You will need to uncomment, or add, the following two lines:
RSAAuthentication yes
PubkeyAuthentication yes
Once that's been done you can restart the SSH server - don't
worry this won't kill existing sessions:
/etc/init.d/ssh restart
File permission problems should be simple to fix. Upon the remote
machine your .ssh file must not be writable to any
other user - for obvious reasons. (If it's writable to another user
they could add their own keys to it, and login to your account without
your password!).
If this is your problem you will see a message similar to the
following upon the remote machine, in the file /var/log/auth:
Jun 3 10:23:57 localhost sshd[18461]: Authentication refused:
bad ownership or modes for directory /home/skx/.ssh
To fix this error you need to login to the machine (with your
password!) and run the following command:
cd
chmod 700 .ssh
Finally if you're logging into an older system which has an older
version of OpenSSH installed upon it which you cannot immediately
upgrade you might discover that RSA files are not supported.
In this case use a DSA key instead - by generating one:
ssh-keygen
Then appending it to the file ~/.ssh/authorized_keys
on the remote machine - or using the ssh-copy-id command
we showed earlier.
Note if you've got a system running an older version of
OpenSSH you should upgrade it unless you have a very good reason
not to. There are known security issues in several older releases.
Even if the machine isn't connected to the public internet, and
it's only available "internally" you should fix it.
====
Re: Password-less logins with OpenSSH
A great way to make use of ssh-agent is with the pam_ssh module.
This makes it possible to only type one password when you log in
(as usual) and also lock up you SSH keys. For the rest of the session
you can use SSH without typing any passwords.
The information to enable this (for GDM at least) is available in
the README in the libpam-ssh package.
===
Re: Password-less logins with OpenSSH
It would be more secure to put the command in the authorized_keys
file -- read sshd(8). The remote sshd server then executes the command
and terminates without giving back a shell. That way, even when
someone either compromises the key or the computer with the key
on it, they can only execute that one command. Especially for your
example of 'uptime' or any other simple command you need often,
this would be even much more secure.
To backup remote servers, I use rsync over ssh with the key valid
only for the rsync-listener (and a shell script to double-check
the given parameters). It is the most secure way I can think of
to backup servers directly. And it's pretty fast too...
===
Re: Password-less logins with OpenSSH
Unless you have a very specific command that can be embedded in
an authorized_keys file, you should always use a passphrase on your
keys.
I worked on solving just this problem for an article I'm writing
(which will be posted here in the not-too-distant future). Here
is a section, with some minor modifications:
In order to script our backups while using a ssh key with
a passphrase, we need an application which will retain use of
the key over a long term. We'll use keychain, a tool which itself
uses ssh-agent, which does the actual caching.
Install keychain:
~# apt-get install keychain
To set up local root's bash profile to run keychain on login,
add these lines to ~/.bash_profile:
keychain --clear id_dsa
. ~/.keychain/$HOSTNAME-sh
This will have keychain first clear the existing keys (in
the case of a normal root compromise, the attacker can't access
the remote systems), then attempt to load the id_dsa key and
finally source the appropriate output from ssh-agent.
The next time root logs in, she will be prompted to enter
the passphrase for the ssh key, and any subsequent process running
as root will not need to use a password to log into the remote
system.
Re: Password-less logins with OpenSSH
Posted by
Anonymous (216.220.xx.xx) on Wed 8 Jun 2005 at 19:36
I have never been able to make this work without including the following
line in the /etc/sshd_config of the remote box:
UsePAM no
Am I crazy?
#24
Re: Password-less logins with OpenSSH
Posted by
Anonymous (71.116.xx.xx) on Mon 22 Aug 2005 at 20:11
You are not crazy... in locking down my debian/ubuntu ssh I found that
I had to change this to no otherwise sshd still allowed password-based auth
#27
Re: Password-less logins with OpenSSH Posted
by
Anonymous
(129.42.xx.xx) on Tue 25 Jul 2006 at 20:14
Only a little crazy. "ChallengeResponseAuthentication no" is the more
specific setting for disabling the password prompt generated by the
PAM module.
#33
Re: Password-less logins with OpenSSH Posted by
redbeard
(216.49.xx.xx) on Wed 27 Jun 2007 at 05:44
[
Send Message |
View redbeard's Scratchpad |
View
Weblogs ]
I realize this is a really old thread, but it's a possible answer to
a question I have. Is this really true? In other words, if I have:
UsePAM yes
ChallengeResponseAuthentication no
I can prevent using PAM passwords (requiring public/private key authentication)
but still use the PAM framework for implementing other things? If that's
the case, I'd be absolutely thrilled. Unfortuntaely, the man page is
a little vague on ChallengeResponseAuthentication:
Specifies whether challenge-response authentication is allowed.
All authentication styles from login.conf5 are supported. The default
is "yes".
I'll repost this elsewhere if no one notices ;)
Re: Password-less logins with OpenSSH
Posted by
Anonymous
(69.128.xx.xx) on Wed 29 Jun 2005 at 05:28
Yes, you can use expect. I greatly caution against using this, since
it has the same security issues passwordless secret keys have. You can
customize the script below to change the ssh command or whatever. The
interact command causes the script to "connect" the keyboard to the
spawned command. You can read about expect for more information.
#!/usr/bin/expect spawn ssh user@host expect "Password: " { sleep
1 send "secret\r" } timeout { send_user "Error connecting" } # I
have no idea why this needs to be here, except if it isn't the #
password does not get sent and the login doesn't happen # So this
should just timeout expect "alksjd" { send_user "Whoa" } timeout
{ } interact
Re: Password-less logins with OpenSSH
Posted by
Anonymous
(202.7.xx.xx) on Fri 14 Sep 2007 at 03:16
Also on FC6, but with Debian 4.0 as the client, and FC6 as the server,
on the server I had to do:
chmod 644 ~/.ssh/authorized_keys
... for some reason (not sure why the permissions were set differently),
in order to get password-less SSH logins to work. So that's perhaps
another thing to check if it's not working for you.
FAQ
-
SSH Communications Security
-
Directory of /pub/unix/ssh
Secure Shell (SSH) was originally authored by Tatu Ylцnen, Finland,
is a secure replacement for Telnet, rlogin, rcp, rsh and provides secured
TCP tunnels. Optional compression of traffic is provided and can also
be used together with many Authentication schemes such as SecurID, Kerberos,
S/KEY to provide a highly secure remote access point to UNIX servers.
SSH1 was the the first version (protocol v1.2 and v1.5) that was
free in the earlier days, but licensing has become more restrictive
and SSH Communications
and DataFellows
are trying to get people to move to the newer SSH2 (which is commercial).
However SSH1 is destined for a long life as freeware, now that OpenSSH
has been produced by the OpenBSD team and community.
The Telnet, rlogin, rcp, rsh commands have a number of security weakness:
all communications are in clear text and no machine authentication takes
place. These commands are open to eavesdropping and tcp/ip address spoofing.
A second key UNIX tool, the X11 windows system, also communicates in
clear text, uses dynamic ports (making packet filtering difficult) and
has a difficult-to-use access control mechanism "xhosts" and "xauth",
that few users understand and hence X11 access control is often insecure
on UNIX desktops.
SSH uses public/private key RSA authentication to check the identity
of communicating peer machines, encryption of all data exchanged (with
strong algorithms such as blowfish, 3DES, IDEA etc.). Backwards compatibility
to rlogin/rsh and their trust files (rhosts, hosts.equiv) is provided
to allow communication with non SSH servers. Optionally, an encrypted
tunnel for X11 communications can be automatically setup by SSH (using
the xauth access control and DISPLAY environment variable).
So SSH protects against:
- Eavesdropping of data transmitted over the network.
- Manipulation of data at intermediate elements in the network
(e.g. routers).
- IP address spoofing where an attack hosts pretends to be a trusted
host by sending packets with the source address of the trusted host.
- DNS spoofing of trusted host names/IP addresses.
- IP source routing
SSH does not protect against:
- Incorrect configuration or usage (see disadvantages below).
- A compromised root account. If you login from a host to a server
and an attacker has control of root on either side, he/she can listen
to your session by reading from the pseudo-terminal device, even
though SSH is encrypted on the network, it must communicate in clear
text with the terminal device.
- Insecure home directories: if an attacker can modify files in
your home directory (e.g. via NFS) he may be able to fool SSH.
SSH can be used to log-in securely into another computer over a network,
execute commands on a remote machine, and copy files from one machine
to another. SSH provides strong authentication and secure communications
over insecure channels. It is intended as a replacement for rlogin,
rsh, and rcp. Additionally, SSH provides secure X11 connections and
secure forwarding of arbitrary TCP connections.
- Supports strong, proven authentication systems such as RSA,
SecurID, S/Key, Kerberos and TIS (as well as the usual UNIX username/password
authentication).
- Three types of trust exist: shosts, rhosts compatible and RSA.
RSA trust is stronger (using a private/public key system to identify
peers), but bypasses the username/password authentication of UNIX.
- The SSH Server runs on UNIX, Linux and VAX.
Client runs on the above, plus Windows and many other platforms.
- Data compression can be enabled to improve performance over
slow network links.
- SSH Internet Proxies:
- I don't know of any real working SSH proxies: Magosanyi
Arpad started working on one based on OpenSSH (see the OpenSSH
developers list, message dated 2000-01-13 17:10:05), but
hasn't time to finish it.
- SSH can be compiled so that it can traverse SOCKS proxies.
SOCKS is
a general proxy protocol, originally sponsored by NEC, but now
available from several vendors.
SSH2 is the new protocol version, submitted to the IETF for approval
by SSH Communications.
It is rewritten (improved cryptography) and is designed for more general
purpose VPNs. SSH2:
- Includes sftp, an SSH2 tunneled ftp.
- Uses separate config files to SSH1 (e.g. /etc/ssh2/ssh2_config),
but can call SSH1 if a client requests SSH1 protocols and SSH1 is
available.
- Compatible with SSH1, when ssh1 has been installed prior to
ssh2.
- DSA and Diffie-Hellman key exchange are supported.
- Because of the commercialisation (see licencing below), acceptance
of SSH2 has been slow.
Today there are many versions of SSH, some implement client only,
some both client and server. Commercial, freeware and "restricted freeware"
licensing is in use. The original SSH (SSH1) implemented by Tatu Ylцnen
was free, but versions later than 1.2.12 have restrictive licensing.
The current SSH1 v1.2.27 indicates that it may only be used for non-commercial
purposes only, but it would seem that most situations would allow free
usage:
For commercial licensing please contact Data Fellows, Ltd.
Data Fellows has exclusive licensing rights for the technology for
commercial purposes.....
You may use the program for non-commercial purposes only, meaning
that the program must not be sold commercially as a separate product,
as part of a bigger product or project, or otherwise used for financial
gain without a separate license...
Use by individuals and non-profit organizations is always allowed...
Companies are permitted to use this program as long as it is not
used for revenue-generating purposes..
SSH2 has a more restrictive licensing, basically meaning it is only
free for non-profit organisations:
NON-COMMERCIAL: any use that takes place
in commercial, governmental, military, or similar organizations
and where a salary or similar monetary compensation is paid, unless
the use can be considered to be EDUCATIONAL USE or is purely for
charity.
Commercial versions are produced by DataFellows and cost about $99
for clients and $500 for servers.
SSH contains strong cryptography (no weak versions exist), which
make it a no-no to export from the U.S., under the current regulations
(which will hopefully change in the coming months). Luckily, SSH1 was
developed in Finland meaning export to the U.S. and the rest of the
world is no problem.
The RSA algorithm is patented in the U.S., so U.S. users of SSH have
to use RSAREF, an official RSA library and pay royalties to RSA. This
patent expires in September 2000 however.
Both of these issues make is very difficult for U.S. Operating System
vendors to bundle SSH with their product. OpenBSD (based in Canada)
and S.u.s.e Linux (Germany) both bundle SSH.
The IDEA algorithm is patented by Ascom in Switzerland (and only
free for non-commercial use), is used by SSH, but it can be disabled
when compiling the SSH server.
- Proven technology - I've been using SSH for 4 years and find
it to be robust and reliable.
- Strong international encryption - and no watered down, weak
versions exist.
- Both free and commercial versions exist.
- SSH client runs of most platforms, the server runs on UNIX,
Linux and VMS.
- Tunneling of static TCP ports works well and can be automated
to use for simple VPNs.
- Many authentication methods including Kerberos, TIS, SecurID
and RSA.
- SOCKS5 proxy aware.
- Port ranges & dynamic ports can't be forwarded.
- Few Windows versions implement secure file copy or key generation.
- SSH1 daemon:
- Cannot restrict what ports may or may not be forwarded,
per user.
- When a user is authenticated by password, the client's RSA
identity is not verified (against ssh_known_hosts). The verification
only takes place when .[sr]hosts trust is used.
- Performance can be a problem on old machines (e.g. Sun SPARC1
with 16MB of ram, but how many of these are still around?)
- The standard SSH1 distribution's defaults include a clear text
option and patented algorithms such as IDEA. However, these can
be switched off (see configuration section below).
- Licensing of the original source has become very restrictive
(see above).
SSH1 for UNIX is available as a free or commercial
product (from
DataFellows).
It is the "original" SSH, but is not being further developed at the
moment (except for fixes). The emphasis is now on the commercial SSH2.
- The author has been running the free versions V1.2.13 - 1.2.27
on the following platforms for since late 1995: Solaris 2.4, 2.5,
2.6, 2.7, SunOS 4.1.3, OSF1.3, IRIX 5.3. Works very well on Solaris,
with some problems on IRIX.
- POP, SMTP, FTP authentication and other TCP socket sessions
can be tunneled, e.g. for SMTP:
ssh -L 25:mailhost.target.domain:25 target &
- V1.2.17 (and later) work with SOCKS5 proxies and SecurID authentication
is also supported (the author has used both since 1996).
- See the main FTP site:
ftp.cs.hut.fi/pub/ssh
or one if it's mirrors such as
ftp.cert.dfn.de/pub/tools/net/ssh .
SSH2 from
DataFellows
is a commercial product for UNIX, Windows or Mac. There is a free
version for non-commercial use, but licensing is pretty restrictive.
The SSH2 home page is www.ssh.fi.
LSH: Efforts are underway to develop LSH,
a free version of SSH2
www.net.lut.ac.uk/psst.
It has not yet reached a stable release status.
Mindterm is a free (GPL) SSH client written in 100% pure Java. It
can be run as a stand-alone program or as an applet in a webpage. It
can be run with or without a GUI. It has other useful features: scp
- file copying and a special ftp-tunnel which works with "ordinary"
ftpd's "behind" the sshd.
The current version is v1.1.5, see
www.mindbright.se/mindterm.
Mindterm SSH has been tested by the author for several months as a standalone
application (not an applet) on NT4, Win95 and Solaris 2.5:
- Multi-platform: should run wherever a JVM exists?
- Stable, pretty, flexible terminal emulation, saves properties
per server, can generate RSA keys, session can be logged to file,
can be used as GUI or command line, X11 and port forwarding works.
Brilliant!
Some nifty extras: "clone terminal", "copy on select", capture to
file.
- It has scp (file copy) and ftp
tunneling (in PASV mode).
Example ftp tunnel instructions:
1) On Mindterm client: Go to menu Tunnels -> Basic... Enter a local
port of your choice.. Select protocol ftp... Give host-name of ftp-server
behind sshd... Click Add button
2) On the FTP client (e.g. ws_ftp): Define a new "site" with address
localhost... go to "Site properties"... in "folder" advanced set
"Remote Port:" to local port selected above... enable "Passive transfers"
- Problems: no serious ones, but....
scp will only copy files to the connected server and does
not understand target syntax like john@server3:/mydir or ~john for
home directories.
There's no online help (but the readme is good).
I've also had occasional blocked tunnels and had to restart.
The encryption algorithm can be set to none (not at all
desirable!).
- An install tool for Linux RPMs was available at
ftp.yellowdoglinux.com/pub/yellowdog/install-ssh.
- Compiling SSH1 for UNIX (the following examples are for Solaris)
is straight forward. Assuming we want the standard options, but
want to disable clear text, the old RSH/rlogin and avoid the IDEA
algorithm:
gzcat ssh-1.2.27.tar.gz | tar xf -
cd ssh-1.2.27; ./configure --prefix=/usr --without-none --without-rsh
--without-idea
make
make install
The SSH daemon will have to be added to one of the system startup
files, it is not done by "make install". An example for Solaris
would be to create a startup file
/etc/rc2.d/S10sshd.
- useful compilation options:
--without-idea Don't use the patented IDEA
algorithm
--without-none: never allow clear text (unencrypted) communication
if one of the servers has no key.
--without-rsh: never allow rsh rhosts as
an option when a server has no key.
--prefix=/usr/bsd --sbindir=/usr/bsd --bindir=/usr/bsd : Installation
in non standard locations.
--with-securid=../ace
Add SecurID authentication support (you need the ACE libs)
--with-socks5=/usr/local/lib Socks5 proxing support
- Preparing a binary install package: To make life easier, compile
on (say) one machine as above, then create a tar file of the binaries
(in the C-Shell). The following also assume that you have copied
some SSH documents such as the FQ to /usr/localssh-docs.
tar cvf ssh_bin.tar /usr/local/bin/{ssh,ssh1,scp,scp1,slogin}
tar uvf ssh_bin.tar /usr/local/bin/{ssh-keygen1,ssh-keygen,ssh-agent1,ssh-agent}
tar uvf ssh_bin.tar /usr/local/bin/{ssh-add1,ssh-add,ssh-askpass1,ssh-askpass}
tar uvf ssh_bin.tar /usr/local/bin/{make-ssh-known-hosts1,make-ssh-known-hosts}
tar uvf ssh_bin.tar /etc/{sshd_config,ssh_config}
tar uvf ssh_bin.tar /etc/rc2.d/{S10sshd,K10sshd} /etc/init.d/sshd
tar uvf ssh_bin.tar /usr/local/sbin/{sshd,sshd1}
tar uvf ssh_bin.tar /usr/local/man/man1/{ssh-keygen.1,ssh-agent.1,ssh-add.1,ssh.1,ssh1.1,slogin.1,slogin1.1,scp.1,scp1.1,make-ssh-known-hosts.1}
/usr/local/man/man8/{sshd.8,sshd1.8}
tar uvf ssh_bin.tar /usr/local/ssh-docs
compress ssh_bin.tar
- Installing on a number of machines:
Copy ssh_bin.tar.Z (created in the last step) to the new target
system,
backup any existing config files,
extract in root, "rehash" (if using csh) and then generate a host
key:
ssh-keygen -b 1024 -f /etc/ssh_host_key -N '';
Add the ssh service, by adding the following to /etc/services:
ssh 22/tcp
# Secure Shell
Start the ssh daemon:
sh /etc/rc2.d/S10sshd start
- On OpenBSD 2.6, OpenSSH is already installed, but let's say
you want to install SSH1 or have an older version of OpenBSD and
are not resident in the U.S., then either
1. Install the binary package for the appropriate OS version and
architecture
pkg_add
ftp.openbsd.org/pub/OpenBSD/2.6/packages/sparc/ssh-intl-1.2.27.tgz
2. Or get the sources and compile:
a) Update your ports listing if needed, but be aware that this takes
time and you should select your CVS target server carefully (see
www.openbsd.org/anoncvs.html
):
setenv CVSROOT anoncvs@anoncvs.ca.openbsd.org:/cvs
For a new ports listing:
cd /usr; cvs -q get ports
To update an existing version: cd /usr; cvs -q
update ports
b) See what ssh versions are available:
cd /usr/ports; make search key=ssh
This reports that ssh-1.2.27 is available (for example)
in /usr/ports/security/ssh
c) cd /usr/ports/security/ssh;
make all install USA_RESIDENT=no;
This should download the source, plus a patch and compile
it. If there are are make problems, update the ports listing (above)
and rebuild.
Use "pkg_info" to verify that it is registered as being installed
on the system, it can later be deleted with "pkg_delete".
- Configuration files: The server has a configuration file /etc/sshd_config,
the client reads a configuration file /etc/ssh_config, which gives
site-wide defaults for various options. Options in this file can
be overridden by per-user configuration files (in ~user/.ssh directory).
- Server: Configure the ssh daemon so that access is restricted
to named hosts with known public keys (/etc/ssh_known_hosts) and
rhosts authentication is disabled. See commented example
/etc/sshd_config, In particular, look at options such as:
- The StrictHostKeyChecking
option can be used to prevent logins to machines whose host
key is not known or has changed. If this flag is set to "yes",
ssh will never automatically add host keys to the /etc/ssh_known_host
or $HOME/.ssh/known_hosts file, and refuses to connect hosts
whose host key has changed. This provides maximum protection
against trojan horse attacks. For many Administrator situations
setting this flag to "ask" to prompt the user about whether
to add the key to the known list of hosts is ideal.
- RhostsRSAAuthentication when set to yes, allows ~/.shosts
to define trust relationships. It may be set to "yes", "nopwd",
or "no". The "nopwd" value disables password-authenticated root
logins, unless there is an .shosts allowing access without a
password.
Root login with RSA authentication when the "command" option
has been specified will be allowed regardless of the value of
this setting (which may be useful for taking remote backups
even if root login is normally not allowed.
- An empty config file can be placed in the users home directory
owned by root and writeable only by root. This will force the
system wide settings for all users.
- Use at least v1.2.26 to ensure forward compatibility with
SSH2.
- Logging in without passwords:
- Avoid if possible, but if necessary, setup carefully.
Use .shosts rather than .rhosts. Make sure trust files have
mode 400. Don't use trust on NFS shared home directories.
- Setting up /.shosts root trust from host A to host B:
Add hostA to /.shosts and /etc/hosts on hostB, add the Public
Key of HostA to /etc/ssh_known_hosts or ~/.ssh/known_hosts.
- Setting up RSA trust from host A to host B: The .ssh/Identity.pub
(public key) of the host A needs to be appended to the list
of keys in .ssh/authorized_keys on the destination machine.
- Client configuration: Configure the system wide defaults for
the SSH client. See commented example
/etc/ssh_config
- SSH and SUID root security:
SSH installs two programs that need special privileges. Ssh is the
client program, and it is by default installed as suid root, because
it needs to create a privileged port in order to use .rhosts files
for authentication. If it is not installed as suid root, it will
still be usable, but .rhosts authentication will not be available.
Also, the private host key file is readable by root only.
Sshd is the daemon that listens for connections. It should preferably
be run as root, because it is by normally listening on a privileged
port (22), and it needs to be able to do setuid(), update utmp,
chown ptys etc. when a user logs in. If it is not run as root, explicit
"-p port" option must be given to specify an alternate port (same
port must also be specified for clients), "-h host_key_file_path"
must be given to specify an alternate host key file, and it cannot
be used to log in as any other user than the user running it (because
it cannot call setuid()). Also, if your system uses shadow passwords,
password authentication will not work when running as someone else
than root.
Both the server and the client have been carefully screened for
possible security problems, and are believed to be secure. However,
there can be no guarantee.
- Installation on Windows (tested with v1.1.2, current version
is v1.1.5):
Get it from
www.mindbright.se/mindterm
and install a Java Runtime v1.1 from
Sun,
Or, download
mindterm_install.zip (2MB file with Java runtime v118 and Mindterm
V1.1.5), extract to C:\Progra~1, then setup a shortcut on your desktop
to c:\Progra~1\mindterm\mindterm.bat . This will work with English,
French, German and Italian (hence the use of the short name).
- Installation on Solaris:
- An example startup script for Solaris is
mindterm.sh. Copy this along with
mindterm.zip to /usr/local/bin .
- Install Java (already installed on newer Solaris, make sure
you have v118 or later).
- Make sure /usr/local/bin is in your path and then just type
mindterm.sh.
- SSH1:
- SSH1 can easily forward single sockets (POP3, SMTP, etc..)
out of the box, with either a PC or UNIX client, e.g. ssh
-L 25:mailhost.target.domain:25 target &
SSH cannot tunnel dynamic ports or ranges. Mindterm SSH include
an option for FTP tunneling.
- If PPP is redirected over an SSH socket, SSH can be used
as a general purpose VPN. A practical example using Linux as
a gateway on both sides is described the O'Reilly book
"Virtual Private
networks, 2nd Edition",
chapter7 and more information is at
sunsite.unc.edu/LDP/HOWTO/mini/VPN.html. You'll need Linux
on both sides and it's a bit tricky (dated 1997). I've not yet
tried this.
- Try also
sites.inka.de/sites/bigred/sw/ssh-ppp-new.txt (dated 1996)
- Rdist 6.1.2 (public domain version) runs over SSH (tested
on Solaris 2 & SunOS) and can be used o synchronise file between
two hosts, or report on differing files.
- Fsh is an add-on to keep an SSH tunnel open to allow
several commands to be remotely executed without reopening the tunnel
each time
www.lysator.liu.se/fsh.
I've not yet tried this.
- Using SSH with RPC/keyserv/NFS/NIS+ : see
fy.chalmers.se/~appro/ssh_beyond.html
- Jean Chouanard has produced SecurID/ACE patches for SSH1 that
add support for the "New Pin" and "Next Token", but which only work
if both SSH server and client are modified accordingly. There is
no sign of these patches being integrated into OpenSSH of Mindterm
SSH just yet. See
ftp.parc.xerox.com:/pub/jean/sshsdi/README
-
Virtual Network Computing is a "remote control" program that
allows you to see and use the desktop of another machine (NT, Win95,
UNIX) over the network. It could also be used for teleworking over
insecure networks such as the internet. Or SSH can be used to encrypt
the VNC communications and hence increase it's security.
- Install an NT VNC server on the intranet, one which is part
of the usual NT domain and has accounts for those who need to
logon. [It could also be UNIX, I'm just using NT as an example].
Secure this machine by choosing a strong VNC password,
enabling exclusive VNC access, by enabling a screen saver with
password after 5 minutes of inactivity and by not putting it
in a public area. Regularly monitor the event log.
- Install an Intranet UNIX SSH server.
- Install a SSH internet gateway, which allows SSH connections
from the Internet. Successful logins are presented directly
to the Intranet SSH server.
Security: Put this host in the DMZ between two secure
firewall filters. Harden. Disable all services except SSH. Allow
no protocols except SSH from the Internet. Configure SSH to
refuse root logins and disable trust mechanisms and RSA authentication.
Configure all user accounts to use a strong authentication mechanism
such as SecurID. Configure user shell to automatically
login use to the Intranet UNIX server (don't allow local logins
to this server). Be paranoid, monitor logs carefully and run
integrity checks (such as tripwire) frequently.
- Install an SSH client such as Mindterm on the VNC
client (somewhere on the Internet).
- SSH Client configuration: Connect to SSH gateway and
authenticate with SecurID (or whatever). Login to UNIX Intranet
server. Setup tunnel from local port 5902 to NT_VNC_server
port 5900.
- VNC Client: Start local VNC client, connect to localhost:2,
enter the VNC password and voila, the desktop should appear.
Now login to NT as usual.
- Security: I suggest you use you own machine (not
one in an Internet Cafe), with an up-to-date Virus checker,
File shares disabled, and a personal firewall such as
BlackICE installed (and set protection level to Paranoid,
no file sharing). This machine should be physically protected
and possibly fitted with encrypted disks (e.g.
PGPdisk).
In case of broken links
please try to use Google search. If you find the page please notify
us about new location
How To Set Up SSH With Public-Key Authentication On Debian Etch HowtoForge
- Linux Howtos and Tutorials
Documentation:
SSH FAQ
www.employees.org/~satch/ssh/faq
Getting Started with SSH by Kimmo Suominen
www.tac.nyc.ny.us/~kim/ssh
Getting SSH
See the links in the Implementation section
above.
Search for SSH pages on the net:
www.links2go.com/topic/SSH
Copyright © 1996-2009 by Dr. Nikolai Bezroukov.
www.softpanorama.org was
created as a service to the UN Sustainable Development Networking Programme (SDNP)
in the author free time.
Submit
comments This document is an industrial compilation designed and created
exclusively for educational use and is placed under the copyright of the
Open Content License(OPL).
Site uses AdSense so you need to be aware of Google privacy policy. Original materials copyright belong to respective owners. Quotes are made
for educational purposes only in compliance with the fair use doctrine.
Disclaimer:
- The statements, views and opinions presented on
this web page are those of the author and are not endorsed by, nor do they necessarily
reflect, the opinions of the author present and former employers, SDNP or any other
organization the author may be associated with.
- We do not warrant the correctness of the information provided or its
fitness for any purpose
- In no way this site is associated with or endorse cybersquatters
using
the term "softpanorama" with other main or country domains (e.g. softpanorama.com) with
bad faith intent to profit from the goodwill belonging to
someone else.
Last modified:
August 12, 2009
Commentaires
1. Le dimanche 9 septembre 2007 à 09:16, par Nicolas
2. Le jeudi 20 septembre 2007 à 10:35, par BooK
3. Le vendredi 21 septembre 2007 à 09:17, par Pierrick