Some ssh tips

Part of Guide to the Local System. This version 20091116, L.S.Lowe.

These notes were made for OpenSSH version 3.6.1p2 on a Red Hat Enterprise Linux 3 system, or SL3 system, and for version 3.9p1 on a SL4 system. On other systems, the file placements may be different, and I suppose there might be different defaults.

Using user-key authentication

For an individual user, login without using a password is best done using ssh keys, protected by a pass-phrase. (If you're the administrator and want password-less login but don't want to give all users individual keys, then you can consider using host-based authentication: next section).

If you do not get prompted for a pass-phrase, only a password ....

If you do not get prompted for a pass-phrase even though you think you've set one up, then there are various possibilities: one is that your authorized_keys file is not accessible on the server; another is that your public-key has not been found in the authorized_keys file.

If you get prompted for a pass-phrase and then a password ....

It can happen that you get prompted for your pass-phrase and you enter it correctly, but then you get prompted for a password. One possible reason for that is that your identity on the server is not complete: for example for a file-based authentication scheme on the server, perhaps your id may exist in /etc/passwd but not in /etc/shadow. It's a requirement that a shadow password entry exists for you on the server, even if it only exists as an entry with a * password. Otherwise the server administrator will see entries in the log messages such as "could not get username from shadow". Another possible reason is that the shadow password entry exists but indicates that your account or password has expired. To summarise, for user-key authentication to work, it's not important that you actually have or know the password for your id on the server, but it's important that the ssh server can access a shadow password entry for you and verify that it's not expired.

AFS and Kerberos quirks

Note that if your remote system has Kerberos-style authentication and AFS, such that AFS permissions take precedence over the Unix file permissions, then you might have to put your private key file in private/.ssh/, and public key and authorized_keys files in public/.ssh/, and put appropriate links to them in your .ssh/ directory, where private and public are directories with the corresponding AFS permissions. If you authenticate using an ssh-key on such a system, then this on its own may not give you full access to your AFS files. Consult local documentation.

Using host-based authentication (protocol version 2)

In host-based authentication, user credentials such as password or user key do not have to be presented, explicitly or implicitly. It's the ssh equivalent of the deprecated rsh protocol, though with a little bit more security. The userid on both systems has to be the same, otherwise you are requested for a password. The server has to trust the client not to fake the userid, nor to be more vulnerable to attack; this is best met if the administrator(s) for those systems are the same. We assume here you're starting from a standard default configuration setup.

To use host-based authentication, the following need to be in place, otherwise you will be prompted for a password:

Using host-based authentication (protocol version 1)

I believe the only difference here is to use RhostsRSAAuthentication for protocol version 1, wherever HostbasedAuthentication is used for protocol version 2. But nobody uses protocol version 1 anymore, for security reasons.


info counter