With remote access via ssh, there are 2 user accounts to consider :
luser@local ---becomes---> ruser@remote
Although both accounts can have the same account name (e.g. jdoe@local, jd@remote), and although ssh assumes that you will use the same username on both local and remote system, they are 2 distinctive user accounts, on separate machines.
objective : while logged in at 'local' as 'luser', do one of the following :
Those are the basic ssh operations. Advanced ssh usage, e.g. ssh secure tunnels (link), follow the same logic. The problem we will deal with in this mini-howto is that you are, obviously, already logged in as luser@local, but will need to authenticate as ruser@remote for any of the basic ssh operations mentioned above. The default method is password authentication, i.e. you supply the account of the remote user in your ssh statement, and are prompted for ruser's password.
luser@local:~$ ssh ruser@remote ruser@remote's password: ruser@remote:~$ ruser@remote:~$ pwd ruser@remote:~$ /home/ruser
If you don't supply an account, ssh will assume you use the same username on remote as on local. Still, you'll be prompted for a password, and that's not necessarily the same password as for luser@local. Like we said, these are 2 distinct accounts
shh is secure in that the password is sent encrypted, so that it can not (easily) be intercepted on the network - contrary to less secure protocols such as telnet, ftp, ...
However, the password can be cracked by brute force (which is trivial for weak passwords). Using passwordless authentication enhances security.
Passwordless ssh also allows for scripting remote sessions or file transfers so you can create scripts for remote management or file transfers over shh without having the script stop and wait for a password each time it has to initiate an ssh connection.
This howto assumes you're using ubuntu 8.10 clients and debian 4.x servers, but should be applicable to any other Linux system, possibly with minor modifications in file names and paths and such.
we'll look into private/public key pairs for user authentication, and authentication based on the host that initiates the ssh session (host-based authentication).
I assume you have created the relevant user accounts, installed openssh-server on the remote system, and are capable of using ssh with password authentication, so this article only describes how to make it passwordless.
This is rather straightforward : you create a key pair (private key, public key). The public key is stored on the remote system. The remote system uses this key to authenticate you : Public Key Authentication works on the assumption that if a message (i.c. a request to log on) can be read using luser's public key, it must have been generated using luser's private key, and therefore can only be coming from luser, so luser is authenticated.
Keys can be protected by a pass-phrase. This will cause a prompt for the pass phrase when the key is used. It adds security (in case someone else has gained access to your private key) but makes scripting more difficult again. You can use ssh-agent to manage the pass phrases and make it all scriptable again. It is advisable to use a passphrase, because a private key file is equivalent to writing down your account names and passwords in a file in your home directory. If your login account on the local machine gets compromised, all your accounts on remote systems are accessible/
luser@Local01:~$ ssh-keygen -t rsa
Next, the public key (id_rsa.pub) needs to be added to the list of authorized keys on the remote system. You could simple copy the .pub file, but that would overwrite any existing authorized keys. It's better to append the contents of /home/luser/.ssh/id_rsa.pub to .ssh/authorized_keys in the home directory of the remote user you want to log in as.
luser@Local01:~$ scp /home/luser/.ssh/id_dsa.pub ruser@Remote:luser.pub.tmp luser@Local01:~$ ssh ruser@Remote <<EOF mkdir .ssh chmod 700 .ssh cat luser.pub.tmp >> .ssh/authorized_keys chmod 600 .ssh/authorized_keys rm luser.pub.tmp EOF
You could also just do all this in one go with ssh-copy-id -i ~/.ssh/id_rsa.pub ruser@Remote
luser@Local01 can now do ssh ruser@Remote and will be logged on as ruser on Remote, without being prompted for a password. Any other user ssh-ing into ruser on remote will still be prompted for ruser's password, and ssh'ing into any other account on remote (eg root@Remote) will also require a password. Of course, you can repeat the passwordless ssh configuration for any combination of local and remote user accounts.
If you've set up public key authentication for all users that need ssh access to "Remote", you can configure Remote to only allow public key authentication, so that any attempts to log on with password authentication will be denied.
In case things don't work right-a-way, these are some relevant configuration settings, both local and remote :
RSAAuthentication yes PubkeyAuthentication yes
On Debian and Ubuntu, all of these are the default values.
Host-based "or "trusted host" authentication resembles Public Key (user-)authentication, so what follows may get a bit confusing.
In trusted-host authentication, the SSH server does not directly authenticate a user based on something he knows or has (e.g. password or private key). Rather, it authenticates the client host, and then trusts that host to say who the user is (i.e., which client-side account he has already been authenticated to use). It then consults server-side configuration (e.g. /etc/shosts.equiv or ~/.shosts) to determine which account names on the client host are allowed access to which server accounts. So, this mechanism actually delegates responsibility for user authentication to the client host — and hence, compromise of a client means immediate transitive compromise of corresponding accounts on the server. (http://www.snailbook.com/faq/trusted-host-howto.auto.html)
ssh with hostbased authentication closely mimics the behavior of the now depreciated r(emote)-commands (rlogin, rcp, ...). the assumption is that a user on local also has an account on remote (with the same username), and when he's authenticated on local, no further authentication is required :
jdoe@local:~$ ssh remote jdoe@remote:~$
The authentication method is a public key authentication but the keys belong to the host (so-called "host keys"), not a user. We'll look in the (functional, conceptual) difference between public key user authentication and host based authentication later. First, let's set it up and see what it looks like.
scp /etc/ssh/ssh_host_rsa_key.pub root@remote:/etc/ssh/temp.local02.rsa.pub
remote:~# host 192.168.11.222 188.8.131.52.in-addr.arpa domain name pointer Local01.mydomain.yx
cd /etc/ssh echo -n "Local02.mydomain.yx " |cat - temp.local02.rsa.pub >> /etc/ssh/ssh_known_hosts rm temp.local02.rsa.pub
HostbasedAuthentication yesIf you changed this, you must restart the ssh daemon for the changes to take effect.
HostBasedAuthentication yes PreferredAuthentications hostbased,publickey,keyboard-interactive,password EnablesSSHKeysign yes
Any user that is authenticated on Local can connect (with ssh) to Remote, provided there is an account with the same name on Remote, and the user will log in with that account.
FIXME: This doesn"t seem to work for root, maybe because ubuntu's root account is locked (although whoami returns root after sudo -i ), or else because it requires additional configuration on remote (PermitRootLogin yes).
Adding a username (from local) in /etc/hosts.equiv gives that account (from local) access to any account on remote (including system accounts that may have or be capable of escalated privileges, possibly to user accounts that can su or sudo, but not to the root account directly). This is considered a security hazard.
a minus ( - ) sign can be used to exclude a username from using hostbased authentication
see man 5 hosts.equiv
To let a specific account from local (e.g. jrandom), as opposed to all users on local, log in to remote using host-based authentication, you do not use the system-wide ssh_known_hosts file, but a .ssh/know_hosts in the home directory of the account that should be made accessible. This still only works between identically named accounts on local and remote.
To have an account on remote accessible by a differently named account on Local, create a .shosts file in that account's home directory, listing the accounts that should have access to it. The .shosts file must be owned by the user and should have mode 0400. Also make sure that the user's's home directory is owned by that user and is not writable by anyone but that user.
I haven't gotten this account switching to work when using host based authentication. I suspect it involves the use of usernames in /etc/hosts.equiv in combination with .shosts and known_hosts in the target account's home,and possibly loosening up some settings in sshd_config (IgnoreRhosts no ?).
It may be more trouble than it's worth, since public key user authentication is a viable, and maybe preferable, alternative.
Hostbased authentication is simple and straightforward once you"ve set it up, especially if you use identical usernames on the systems involved. Once hostbased authentication is set up, it suffices to create users on local, and accounts on remote with identical usernames as those on local, to have all users from Local be able to ssh into remote - that is, you don't have to set up and manage per-user keypairs for every user anymore. You do have to trust the authenticating host, however. If it allows users to login with weak or blank passwords, those weak accounts have direct access to your server.
Host-based authentication can possibly also be interesting in combination with a centralised user database, eg OpenLDAP or WinBind - but didn't go in to that (yet).
At first sight, Hostbased authentication looks easier in the case where 1 account (luser@local) needs access to multiple servers. However, if this involves different user names on the remote systems, then each target account needs to be set up to allow access. It is then just as easy, or easier, to set up user authentication with these accounts.
Hostbased authentication with switching of user accounts could be useful if all users of a given host need access to the same account of a remote host. It would suffice to create a user account on the local system, and be done with it. This means you need to have total trust in the originating host : any account created there will automatically gain access. Depending on what the server and the target account are, user authentication may be preferable.
Other authentication mechanisms supported by ssh are
All of the above is about client authentication : the remote system checks whether it should allow you access, by asking a login name +password, checking a key, checking what host you connect from, etc.
You don't want to be sending this sort of security-related information to or initiate transactions with a rogue server (man-in-the-middle attack, hijacking, spoofing, ...). Therefore, it is possible to have the server authenticate itself while you set up the connection. This tells you you're actually talking to the server you think you're talking to, so you can be comfortable in telling it your password, sending your files to it, etc.
The remote host can authenticate itself using either
As such, ssh is only secure in that it provides a secure (encrypted) channel over which to transfer data, such as passwords or confidential files. Client / user authentication is a standard feature of any multi-user or networked system. Server authentication adds a level of security in that you can trust that your not sending confidential data to a rogue host.
When using user or host-based authentication based on "something you have" (a private/public key), it is important that you can trust those, i.e that noone but the intended user has access to the private key. As the key is stored in the user's home directory, this means access to that home directory or to the user's original login account compromises the key, and grants access to all remote accounts you've set up to use that key. It's best to protect your keys with a passphrase, and use ssh-agent and ssh-askpass to manage them in a user-friendly way.
In addition, you should build security into your network to prevent unauthorized access to your ssh servers. Good security is layered, and progressively more granular. This allows for easy measures to block the bulk of undesirable connections and provides a safety net should one of the measures be circumvented. Here's an example of some additional measures
The Snail Book, or SSH: The Secure Shell - The Definitive Guide,by Daniel J. Barrett, Ph. D., Richard E. Silverman, and Robert G. Byrnes. (O'Reilly)
ssh.com is (the website of a distributor of) a commercial implementation of ssh. There are some differences between ssh and openssh, especially in file names and paths, but it's a useful resource to gatjher the general principles : SSH Admin Guide