|
Softpanorama |
May the source be with you, but remember the KISS principle ;-)
|
| News | SSH | Recommended Links | Solaris | Mini-tutorial | FAQs |
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:
A private/public keys pair is generated using ssh-keygen command line utility. 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 is 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:
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.
$HOME/.ssh/authorized_keys.
$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 probably either /etc/ssh/ssh_config
or /usr/local/etc/ssh_config, depending on how
you installed OpenSSH. (In either configuration file, you can set the parameters
on a host-by-host basis, so that different options can apply to different target
systems.)
ssh-copy-id -i .ssh/id_rsa remoteuser@remote.hostThis 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 ~/.sshWe 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
logoutWe 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_configYou 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
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.
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 rsaThis 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@mysteryThis 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.00What 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 yesOnce that's been done you can restart the SSH server - don't worry this won't kill existing sessions:
/etc/init.d/ssh restartFile 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/.sshTo fix this error you need to login to the machine (with your password!) and run the following command:
cd chmod 700 .sshFinally 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-keygenThen 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 OpenSSHRe: Password-less logins with OpenSSHA 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 OpenSSHIt 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 OpenSSHUnless 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 keychainTo set up local root's bash profile to run keychain on login, add these lines to ~/.bash_profile:keychain --clear id_dsa . ~/.keychain/$HOSTNAME-shThis 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.
[ Parent | Reply to this comment ]
#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
[ Parent | Reply to this comment ]
#27
[ Parent | Reply to this comment ]
#33 Re: Password-less logins with OpenSSH Posted by redbeard (216.49.xx.xx) on Wed 27 Jun 2007 at 05:44
UsePAM yes ChallengeResponseAuthentication noI 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 ;)
#!/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
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
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:
SSH does not protect against:
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.
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:
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.
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.
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:
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
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-2008 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). Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.
Standard 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.
Last modified: June 02, 2008