The SSH (Secure Shell) is widely used to provide secure access to remote systems, we have few ways to do it. Basically, everybody who uses it knows...
For further actions, you may consider blocking this person and/or reporting abuse
Just a note:
default ssh-keygen does not generate secure enough keys. At least on Ubuntu 18.04 it generates RSA based, 2048 bit key, which is considered weak already.
While generating 4096 RSA bit key is possible (and may be still required to ssh into systems using old versions of ssh) it is beneficial to switch to shorter but computationaly more expensive elliptic curves like
ed25519.To further increase security against brute-forcing in case your key was stolen, you should specify to save the key in new format (the old one is really weak) by using
-oand additionally to specify to use many KDF function rounds to secure the key using-a 100or more.The final command then should be:
Oh, nice to know it, thx a lot, going to update it.
This doesn't address dangling agents. Each time you 'eval $(ssh-agent -s)' you are creating a new process. This will leave stranded processes that aren't cleaned up and don't die with timeouts. There is a method to reuse a PID rather than recreating each time.
I have this problem also. It would nice to know the correct way to handle this in .bash_login, .profile, .bashrc, .bash_logout files so if an agent already exists, it is reused, or on logout the agent is removed. I often have ssh sessions broken by connection failures so the session is not logged out.
Hey, if it can help, I've a repo containing a tiny script that handle that.
The way it works is pretty simple: it exposes an alias named ssh-auth that ask to authenticate the first time it is used and then re use an existing agent if invoked in a different terminal. Just, ensure to look at both .bashrc_ssh-auth.sh as well as .bashrc files : github.com/MetaBarj0/configs/tree/....
Let me know if it helps.
Is it possible to re-use the same key-pair files with other local machines to access the server?
Yep, just copy them over there and that’s it. Repeat the process.
Thank you :)
when I test the agent forwarding with the ssh command to github as in
$ ssh -T git@github.com
I get:
git@github.com: Permission denied (publickey)
I guess it's not working then...
any hint on debugging where I might have gone astray? Thanks Levi; useful.
Sorry, I didn't see your comment, you already solved it ?
I would propose mentioning
ssh-copy-idover manually editing~/.ssh/authorized_keys.ssh-copy-idtakes the same-iargument, so if you use a non-standard location for your key, lets say~/foo/bar/id_rsaand~/foo/bar/id_rsa.pub, thenwill open ssh, ask for password, copy the
~/foo/bar/id_rsa.pubfile into~/.ssh/authorized_keyson the remote.Otherwise
will copy whatever keys it finds to the remote (might be multiple!)
It says private key has a .pub extension appended, but its the other way around, pub is for public
Thx, was a typo.
"The private key will have .pub appended to its name"
What do I even say to this.
I fixed it, was a typo.
I believe SSH agent forwarding is considered harmful, and it is better to use ProxyCommand instead
How to make it as if we access a website, we use the website provided vpn?
How to handle the case where your git uses a different key than the one you use to login to the remote host?
You can add keys to SSH Agent Forwarding, so you can use 1 key for sshintg into the remote host and the other one for pulling from github.
Note: you don't forward the key itself, you forward the agent, so basically, you can add many keys as you want.
You can check here how to do it
superuser.com/questions/1140830/ss...
Adding the key to ssh-agent is what I've been missing.
Thank you Levi!
You forgot to add the "-A" in your "Testing SSH agent forwarding" example.
This works great with my Yubikey, thanks!
Oh yes, you right, thanks for it.