As I am doing my routine penetration testing and found the vulnerability in which OpenSSH have weak RSA-2048 and DSA-1024 keys.
So, I have downloaded the exploit for the same and got some weak keys.
Now, when I am trying to authenticate into the system using RSA private key/ Public key. It still ask me for the password.
I have used the way
ssh -i /my/keys/location user#IPaddress
But, the conceptually, while using RSA keys for the authentication, it should not ask for the password.
May be you will think that, the RSA keys are not present in authorized_keys
The keys are founded by using bruteforcing so they are present in authroized_keys.
Any comment or suggestion regarding the same are most welcome.
Regards
Related
I'm trying to get SSH authentication to work without needing to store a private key in plaintext. I'm using an api that allows private key signing of a key stored in memory, and I'm wondering what's the best way to incorporate it into SSH. Since all I really need to do is supply a valid Private key signature to the SSH agent when it's doing its authentication, what would be the best way to do this. Can I just modify the ssh-agent a little bit to accept a signature I give it, or will I have to write my own agent to process this request?
There is a lot of ways to do that. Simplest would be to use PKCS#11 interface, which is available in ssh-agent and can be used for exactly this use case (provide signatures from safe place where the keys are stored -- generally Smartcard or HSM module).
Also encrypted keys using passphrase can solve your requirement against "storing private key in plaintext".
I'm following the tutorial here and understand that the I'm making a key that is held in a directory somewhere so that when I go to a website, it will automatically see my key and give me access without me having to sign in. Is that correct? what does the "-t" and "-C" mean? What does putting in my email do? Does that mean that when I go to a site, if I put in my email it will automatically have access to my ssh key?
ssh-keygen -t rsa -C "yourname#yourdomain.ext"
First of all, whenever in doubt, consider checking MAN pages first.
In this case, MAN page tells us that -t rsa sets the type of the key to RSA (or, generates the key using RSA algorithm). The MAN page also mentions that it's the default one, so if you don't put that in, it will still generate RSA key.
As for the -C "yourname#yourdomain.ext", -C specifies a comment which will be put in the generated files that can help you identify the key later on (for whatever reason).
Keys don't work "automatically". Normally, you install your public key (NEVER share your private key - that's the purpose of it being private) on a remote machine, and then when you try logging on to it via SSH, there will be a series of challenge requests between the two that will result you being allowed to log on the instance without typing your password if your private key matches one of the installed remote public keys (there can be more than one if for example you install different public keys for every machine you log on from or have some sort of shared account).
I've installed new Ubuntu from scratch on my new machine and want to have an access to the remote host using ssh. The problem is that even if I have both public and private keys I forgot the passphrase used whilst creating keys because right after that I've passed it to ssh-agent. But I still have it (the passphrase) stored in the ssh-agent in my laptop. How can I restore the passphrase from ssh-agent if I have root access and both keys?
As far as I understand it, the passphrase is used to encrypt the private key. ssh-agent doesn't remember the passphrase - it remembers the decrypted private key.
And, as a damienfrancois mentioned, it shouldn't remember it past a reboot.
If you wished to extract the decrypted private keys from ssh-agent itself, you would have to find a tool written to search the memory of the running process and locate keys. One such tool can be found here, but you may well find it very challenging to use.
For a more practical answer, you can just delete your keys from ~/.ssh/id*, make new ones that you know the passphrase for, and move on - for a new machine, you probably haven't gotten too reliant on them yet.
If you follow the GitHub HowTo "Generating SSH Keys", you get three files in your ~/.ssh directory: known_hosts, id_rsa, and id_rsa.pub.
The file known_hosts is used for the server authentication, id_rsa is used for the client authentification (here is an article, that explains the difference).
Why should I create / why GitHub does need both -- a host and a user authentification files? How does the GitHub authentification work?
Thx
This is just plain old SSH authentication; nothing about it is specific to GitHub.
id_rsa and id_rsa.pub are the two halves of your key: the private key and the public key. Effectively, the public key is the lock for the private key. You put the lock (public key) on whatever servers you want easy access to, without too much worry that someone else will see it, because it's just a lock. You keep the (private) key on your machine, and use it to log into those servers; they see you have a key fitting the lock, and let you in.
(Not to say that you should put your public key on completely untrustworthy machines; there are malicious tricks that can take advantage of shortcuts like ssh -A.)
known_hosts doesn't actually have much to do with this; it's just where ssh stores the fingerprints of all the servers you've connected to, so it can throw up a big scary warning if the fingerprint changes. (That would mean it's not the same machine: either something has changed radically on the server side, or your connection has been hijacked.)
So, anyway, one of the protocols Git itself understands is SSH. When you use git#github.com:... as a repository URL, Git is just connecting over SSH. Of course, GitHub doesn't want you mucking around on their machines, so they only let you do Git things, not get a full shell.
As usual, the Arch wiki has a whole lot more words on this.
known_hosts stores the server's identity the first time you connect, so that you know the next time that you're connecting to the same server. This prevents someone from pretending to be the server the next time you connect (but sadly not the first time)
id_rsa is your secret key that proves that you are really you. Never give this away.
id_rsa.pub is the public key, its purpose for authentication is basically just to prove that you have the secret key without giving it out. This key you can give to anyone what needs it since there's nothing secret about it.
When you connect to the server, SSH first checks that the server has the correct key (ie it should match the one in known hosts. If the client is comfortable that the server is genuine, it uses its private key to sign the following data and sends it to the server;
string session identifier
byte SSH_MSG_USERAUTH_REQUEST
string user name
string service name
string "publickey"
boolean TRUE
string public key algorithm name
string public key to be used for authentication
The server verifies the signature using the public key (which you earlier uploaded to Github), and if it is correct, the client is authenticated.
The known_hosts file is used by ssh whenever you actually connect to a host via SSH. It stores a signed key of sorts for the server. Then, if it changes, you will know.
ssh-keygen -t rsa -C yourgithub#accountemail.com is used to generate the SSH key in which you will give the id_rsa.pub to github. Then, when you connect to github you have the private key id_rsa in your ~/.ssh folder which is then used to validate your information with github.
This is a very low-level explanation, but the private key (non .pub) file is your end, the .pub is for github and the known_hosts is for your box to know what is what.
You can also generate a config file in ~/.ssh for use to specify which key goes to which host..
authorized_keys and known_hosts are entirely different..
Your SSH server (sshd, ie) uses authorized_keys, or whatever file is defined within your /etc/ssh/sshd_config/ for knowing the public side of another key. So when a user connects to your server, they pass their private key, your SSH server verifies against the public key it has within authorized_keys and if it doesn't match, it doesn't work.
Github maintains an authorized_keys so-to-speak on their users. Your public key goes into your authorized_keys on your account and then when you connect via ssh to clone,push,etc, it checks your private key you send over with your public key they already know.
I want to use Gitolite for Git access control.
My question is on ssh keygen for dynamic IP changing workstations. So, do I need to generate ssh keys every time whenever my IP changes. This going to be tedious work for all developers as they use laptops and they need to generate keys and push to Gitolite repo.
Is there any workaround or some other solutions for this ssh public keys generation problem for Gitolite use?
Key generation has nothing to do with IP address from the client perspective.
When you generate an SSH key-pair, for lack of a better analogy, you're generating some files which contain really long numbers which can be used to encrypt or decrypt things. The private key is stored in .ssh/id_rsa (for an RSA key) and the public key is stored in .ssh/id_rsa.pub
You can move that key pair to any machine you wish. You should make sure that the private key is always well protected. The public key, you can give to anyone or copy it wherever you like. It's public. You can also have multiple keys on a machine, with different keys used for different hosts. This is controlled by a .ssh/config file. However, most users don't need that, and stick with a single key pair.
Specifically in the case of gitolite, you'll be storing the public keys of your users in the gitolite-admin/keys directory.
In any case, the fact that your laptop's IP address is changing will have no effect on your keys.