~ $ cat ~/.ssh/id_rsa
cat: /data/data/com.termux/files/home/.ssh/id_rsa: No such file or directory
~ $ cat ~/.ssh/id_ed25519
cat: /data/data/com.termux/files/home/.ssh/id_ed25519: No such file or directory
The first command works for me on Termux, but the second matches your output. Does this just mean you have not set up SSH?
I use ssh regularly, I just use a different key for each server. And thus I don't use the default name (id_rsa) because it doesn't make sense.
Let's see the hackers figure that one out!
cat ~/.ssh/* perhaps?
Damn okay well if the hackers are at that level I guess you're just screwed.
No that means they haven't ran ssh-keygen yet
Or they did not use the default name. Devious D:
id_rsa shouldn't exist any more.
If I had a nickel for every time I had to change my ssh key algorithm I'd have two nickels.
Which isn't much but it's concerning that it happened twice.
A few days ago I was messing with my ubiquiti dream router and its ssh config option said the key should start with ssh-rsa 🙄
It probably accepts other key types and it's just the UI that's outdated. I doubt they're using an SSH implementation other than Dropbear or OpenSSH, and both support ed25519.
Could be stupid input validation which requires ^ssh-rsa
Fact of the matter is RSA is perfectly secure still...and ECDSA/ED25519 should also be extinct given the rising need for post quantum cryptography
The problem is not the RSA math itself but that it is both extremely slow and implementing it is particularly susceptible to bugs and side channel attacks
https://blog.trailofbits.com/2019/07/08/fuck-rsa/
Most of the situations I encounter RSA are in projects where I hope RSA is implemented correctly. I have a lot of Let's Encrypt certs that are still RSA and my main SSH keys are still RSA. All of these were generated quite some time ago. I understand the problem with projects that implement it incorrectly but I'd hope OpenSSH and certbot aren't those projects 😥
For Certbot, I think it's even further up the chain - OpenSSL. And if you're installing it to Apache or Nginx, its probably just OpenSSL again.
Azure DevOps only allows you to use RSA keys. This caused a major outage in May (they switched from V1 to V2) :).
Here you go!
The first command works for me on Termux, but the second matches your output. Does this just mean you have not set up SSH?
I use ssh regularly, I just use a different key for each server. And thus I don't use the default name (id_rsa) because it doesn't make sense.
Let's see the hackers figure that one out!
cat ~/.ssh/*perhaps?Damn okay well if the hackers are at that level I guess you're just screwed.
No that means they haven't ran
ssh-keygenyetOr they did not use the default name. Devious D:
id_rsa shouldn't exist any more.
If I had a nickel for every time I had to change my ssh key algorithm I'd have two nickels.
Which isn't much but it's concerning that it happened twice.
A few days ago I was messing with my ubiquiti dream router and its ssh config option said the key should start with ssh-rsa 🙄
It probably accepts other key types and it's just the UI that's outdated. I doubt they're using an SSH implementation other than Dropbear or OpenSSH, and both support ed25519.
Could be stupid input validation which requires
^ssh-rsaFact of the matter is RSA is perfectly secure still...and ECDSA/ED25519 should also be extinct given the rising need for post quantum cryptography
The problem is not the RSA math itself but that it is both extremely slow and implementing it is particularly susceptible to bugs and side channel attacks https://blog.trailofbits.com/2019/07/08/fuck-rsa/
Most of the situations I encounter RSA are in projects where I hope RSA is implemented correctly. I have a lot of Let's Encrypt certs that are still RSA and my main SSH keys are still RSA. All of these were generated quite some time ago. I understand the problem with projects that implement it incorrectly but I'd hope OpenSSH and certbot aren't those projects 😥
For Certbot, I think it's even further up the chain - OpenSSL. And if you're installing it to Apache or Nginx, its probably just OpenSSL again.
Azure DevOps only allows you to use RSA keys. This caused a major outage in May (they switched from V1 to V2) :).
None of them...
ssh-keygen -t ecdsa -b 384Then get it signed and use the certificate.
SSH certificates are where its at.
cat ~/.ssh/id[TAB]