|Directory containing information for safesh.|
Mapping file for
describing how to map host names to their canonical form.
This is usually used to map short names to their long form.
The format of the file is one mapping per line, what it is mapped from as the
first word, what it is mapped to as the second.
It is also possible to use this to map domain names to their safe form by having the name of the host as the first parameter, and the name of the host with a period (.) at the end as the second parameter, e.g., "freefall.freebsd.org freefall.freebsd.org.".
|Directory with data for a particular hostname. Automatically generated on first connect to a host with safesh.|
|Private key for use to authenticate as $USER@$HOST. Automatically generated on first connect to a host with safesh.|
|Public key for use by $HOST to authenticate $USER. To connect to $HOST as $USER using safesh without giving a password, add the contents of this file to the end of $HOME/.ssh/authorized_keys2. Automatically generated on first connect to a host with safesh.|
Private key for use when
This is used in preference to
for authentication forwarding through
The file is only used if
is listed in
This file is not generated automatically by
It is only present if you have generated it using
Note that it is usually more than useless (can pose a security risk) to copy a
key used for other authentication to this location.
The use of explict authentication files for authentication forwarding is primarily for protection against the case where the machine you run safesh on is compromised. Using this file, you can use a separate passphrase from the one used for the key for connecting directly to $AUTHTARGET; that key need not even exist. By using IP restrictions in the authorized_keys file for the key, you can make sure that the host safesh runs on cannot connect to $AUTHTARGET using the authentication forwarding key. The use of a separate forwarding key can also be used in combination with a modified SSH to log which key was used where, and thus track key propagation.
|Public key corresponding to the private key described above.|
|List of extra keys to make available for this host. Each line in the file is first attempted matched against the host/user/port database in $HOME/.safesh/. Username and/or port is added if just the hostname is specified extra_keys, and the hostname is always normalized using the map file. If a key exists in $HOME/.safesh/, safesh attempts to add that. Otherwise, it first tries to look for the line as a file relative to /, then relative to $HOME. If it does not find either of these, safesh will exit with an error message. If it finds one, it will add it using ssh-add(1).|
|Bourne shell (see sh(1), bash(1), zsh(1)) script for setting up the environment variables for a particular ssh-agent(1) process used for this host. Only valid if safesh has been run against that host as this user since the machine safesh runs on was last booted. Note that this file must be sourced, not just run as a shell script.|
|CSH (see csh(1), tcsh(1)) script for setting up the environment variables for a particular ssh-agent(1) process used for this host. Only valid if safesh has been run against that host as this user since the machine safesh runs on was last booted. Note that this file must be sourced, not just run as a shell script.|
The safesh utility was written by
.An Eivind Eklund Aq eivind@FreeBSD.org .
ssh(1), ssh-add(1), ssh-agent(1), ssh-keygen(1)
The safesh utility does not handle whitespace in filenames specified in extra_keys correctly.
The ssh-agent(1) processes that are started by safesh will hang around until next reboot unless you put the "killall ssh-agent" command in .logout or similar. This allows any login to your account to use your authentication towards machines you have connected to (including anybody with root on the box), persisting after you log out. You must always assume that root can grab your authentication at the moment you run do it, so this is only an issue in that the authentication stays available longer. This is not resolvable without rewriting ssh-agent(1).
Two-step secure SSH with an untrusted host in the middle It is possible to use the port forwarding capability of ssh(1) to forward authentication through another server, without allowing the other server to indepently authenticate to a third party, and without allowing it to see what is going on in your connection. This is based on just forwarding a tunnel through the untrusted host, and doing direct authentication to the server on the other side. With the present version of OpenSSH, this has the problem of leaving the actual port forwarding open while the tunnel is open, allowing other users to set up their own tunnels, and weakening another side of the security model. Read out fingerprints The safesh utility should make it trivial to retrieve the fingerprint for:
- The host it is running on.
This must presently be done with "ssh-keygen -l /etc/ssh/ssh_host_key.pub" (to get the fingerprint for SSH 1) and "ssh-keygen -l -f /etc/ssh/ssh_host_dsa_key" (for SSH 2).
- Other hosts, as registered in the known_host file on the host it is running on.
This must presently be done by manual inspection.
Merge known_hosts The safesh utility should make it trivial to merge known_hosts and known_hosts2 with ones from another host, including retrieving and uploading known_hosts as appropriate. Manage .ssh/authorized_keys2 The safesh utility should be able to automatically remove keys from the authorized_keys2 file on other machines, to make everything about the safesh process self-contained. Manage setup of key limitations When managing authorized_keys2, it is also reasonable to manage key limitation in this. IP restrictions ("from=") should be handled to make it easy to create setups where the local machine does not have direct access to a target. Command restrictions etc. would be good to have just for completeness. Emulate the entire ssh 1 syntax Presently, the safesh utility has a fairly weird syntax. This is because it is a fairly quick hack, just made to be usable. Later, it would be nice to rewrite it to be fully compatible with ssh(1). This would allow use as a drop-in replacement. Description of the trust/threat/security model It would be nice to have a complete description of the normal SSH threat model as well as the safesh threat model, in order to make people fully conscious of their own model. Emulate scp(1) The scp(1) utility is very useful, and the only way to use it with safesh at the moment is through a subshell created by scpsh. An ideal safesh implementation would include wrapping of scp(1), too.
$HOME Path to your home directory. $HOST The name of the host you are running safesh towards. This is the machine you are ssh 1 ing into. $YOURHOST The name of the host you are running safesh on, as output by hostname(1). This is the name of the machine you are ssh 1 ing from. The use of $YOURHOST makes safesh safe to use with NFS-mounted home directories. $AUTHTARGET The authentication target for an authentication forwarding. This is not the same as $HOST. $AUTHTARGET is a machine you are ssh 1 ing to from $HOST. The format of $AUTHTARGET is
.Sm off <user@<somehost-<someport>>>,
.Sm on where <<user>> defaults to the username you run safesh as, and <<someport>> default to 22 (and it is not possible to set anything else at this time).
$USER The username used on $HOST; defaults to the same as the username you have on $YOURHOST, but will be different if you do "safesh user@host" instead of just "safesh host". $PORT The port used on $HOST. Presently always 22.