Solar's Rootdirectory

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
The ''~/.ssh'' directory can do a lot more than just keep your SSH keys. Use it correctly, and SSH turns from a chore to something you use as transparently as a mountpoint.

==== Remote Execution ====

If your goal is to just execute one command on the remote, you can do better than log in - execute - log out: You can pass the command to execute directly to SSH:

<code>ssh user@example.com "ls ~"</code>

This prints the contents of your //remote// home directory to your //local// shell.

==== ~/.ssh/authorized_keys ====

If you copy the contents of your local ''~/.ssh/*.pub'' file (i.e., the public part of your key pair) into the remote ''~/.ssh/authorized_keys'' file, future connections to that remote will make use of pubkey authentification. You don't need to remember the remote's password, just the keyphrase for your local private key.

As for "how do I get my ''.pub'' file contents into that file, that can be done by remote execution of ''cat'' plus output redirection:

<code>cat ~/.ssh/id_ed25519.pub | ssh user@example.com "cat >> ~/.ssh/authorized_keys"</code>

==== ~/.ssh/config ====

A much underappreciated gem is ''~/.ssh/config''. This can be used for by-host configurations of SSH. Try this:

<code>
Host MyHost
    Hostname MyHost.example.com
    User MyHostUser1234
    Port 8022
</code>

Instead of having to write ''MyHostUser1234@MyHost.example.com:8022'', all you need to write now is ''MyHost''.

==== ssh-agent ====

One thing you cannot -- and indeed should not -- write into a config file is the pass phrase for your private key. Neither should you use a private key //without// a pass phrase. Instead, you should set up a key agent: A process that takes your passphrase //once//, unlocks your private key with it, and keeps it available until you log out again.

SSH comes with one such key agent included -- ''ssh-agent''. Unfortunately many setup tutorials are rather basic, telling you to just ''eval $(ssh-agent)''. Yes, that works, but if you put that into your shell profile, you will spawn another agent  //every time you open a new shell//. Instead, add a bit of extra logic that 1) tracks any agent you already launched, and 2) launches a new one only if necessary, re-using the already-running process wherever possible:

<code>
start_agent() {
    mkdir -p "$(dirname "$SSH_ENV")"
    ssh-agent -s > "$SSH_ENV"
    chmod 600 "$SSH_ENV"
    . "$SSH_ENV" >/dev/null
}

agent_is_usable() {
    [ -n "$SSH_AGENT_PID" ] &&
    kill -0 "$SSH_AGENT_PID" 2>/dev/null &&
    [ -n "$SSH_AUTH_SOCK" ] &&
    [ -S "$SSH_AUTH_SOCK" ]
}

if [ -f "$SSH_ENV" ]; then
    . "$SSH_ENV" >/dev/null
fi

if ! agent_is_usable; then
    start_agent
fi
</code>

Now, when you need SSH the first time, call ''ssh-add'', which adds your private key to the agent's "keychain". You will be asked for your passphrase this one time. Any subsequent use of SSH in the same login session will use the agent's keychain; you won't need to enter your pass phrase a second time.

Many passkey managers have some kind of SSH agent integration, but this is not the place to discuss their respective setups.

==== Bottom Line ====

If you have set up your SSH environment correctly, copying a file from local to remote becomes as easy as ''scp <oldfile> MyHost:~/<newfile>''.