the threat model is exactly the same for those two scenarios, bear with it and focus on something else :)
this post was submitted on 20 Dec 2023
46 points (97.9% liked)
Linux
48328 readers
641 users here now
From Wikipedia, the free encyclopedia
Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).
Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.
Rules
- Posts must be relevant to operating systems running the Linux kernel. GNU/Linux or otherwise.
- No misinformation
- No NSFW content
- No hate speech, bigotry, etc
Related Communities
Community icon by Alpár-Etele Méder, licensed under CC BY 3.0
founded 5 years ago
MODERATORS
Yes, it can be done. Not to the point of deleting your key (that makes no sense - you need the key), but ssh-agent is what you want. Add it to your shell config and it will only ask to be unlocked once per however often you define.
I have this function defined and called:
function ssh-agent-setup() {
# SSH agent
pid_file="$HOME/.ssh/ssh-agent.pid"
SSH_AUTH_SOCK="$HOME/.ssh/ssh-agent.sock"
if [ -z "$SSH_AGENT_PID" ]
then
# no PID exported, try to get it from pidfile
SSH_AGENT_PID=$(cat "$pid_file")
fi
if ! kill -0 "$SSH_AGENT_PID" &> /dev/null
then
# the agent is not running, start it
rm "$SSH_AUTH_SOCK" &> /dev/null
>&2 echo "Starting SSH agent, since it's not running; this can take a moment"
eval "$(ssh-agent -s -a "$SSH_AUTH_SOCK")"
echo "$SSH_AGENT_PID" > "$pid_file"
>&2 echo "Started ssh-agent with '$SSH_AUTH_SOCK'"
fi
export SSH_AGENT_PID
export SSH_AUTH_SOCK
}
ssh-agent-setup
This way it stores the unlocked key in memory until the end of the session.
that makes no sense - you need the key
But if it's stored in a keyring or similar (like on windows) and the client reads from it you don't need the file with the plain text key. Like you don't store the git credentials in a file, but with libsecret.
I would prefer something that never ask for the password.
Things like the gnome-keyring or kwallet keep all the passwords in an encrypted file, they get decrypted and kept in ram using your login password when you log into gnome/KDE session and programs can ask for passwords using some API. Once you log out the passwords are removed from ram and no one can read them. My goal is to have something like this, so I'm never asked for a password, I just log into my session and everything is available
I don't like what you're trying to do, but I think gnome-keyring would do this for you. Seahorse is the gui for it
I'n Windows it is not stored in a keyring but instead in the registry. This has basically the same security threat model as a local key file.
The ssh-agent on Linux will do what you want with effectively the same security. The biggest difference being that it doesn't run as a system service but instead runs in userspace which can make it easier to dump memory. There are some other agent services out there with additional security options but they don't change the threat model much.
The basic concept is the same. The URL you provide is specifically for Windows.
Check the Arch wiki on SSH keys to achieve what you want. It applies to other Linux distros
What about a hardware key? Like nitrokey or yubikey?
I store my keys via KeepassXC. They got a Freedesktop.org secret service and key-agent integration
Your ssh private keys are safe, assuming nobody has physical access to your home directory. You can configure them to not require a password.
If someone has physical access to your computer then they could become compromised. If you are worried about that you could encrypt the whole drive.
Unless some sandboxing or other explicit security measure is in place, any software you run typically has access to your entire home directory, including .ssh/. If any one of those was compromised somehow, they've got access to your SSH keys.
That's a gigantic attack surface if you ask me.
It's not a solution.
Example: there's another user with sudo access, he has access to my home folder, encrypting the drive doesn't solve anything. Or maybe you just are not the system administrator.
It's not my usecase, but it's definitely a reasonable situation.
You can encrypt your /home separate with another password.
Anyone with sudo access can keylog your password