They are pretty similar. It’s hard to judge because they are different sizes, different boundaries, and different brightness. If VLC is playing a bit dimmer, it makes sense that some artifacts would be less visible.
They are pretty similar. It’s hard to judge because they are different sizes, different boundaries, and different brightness. If VLC is playing a bit dimmer, it makes sense that some artifacts would be less visible.
None of what you’ve just said here is true. They don’t work like house keys. Your system and my system are VERY different because I’m not making copies of my private keys anywhere. They never leave the safe place I created them. I only ever transfer the public keys. I could post my public keys here and there would be no security compromise for me. You came here asking for help. I tried to help you. I’m sorry it wasn’t what you wanted to hear. Your attitude sucks.
No, it is inherently bad to copy around private keys. You have some fundamental misunderstandings of how key authentication security works. RTFM.
No, you’re missing the point and creating a false choice here. You’re supposed to generate new keys for each client device and load their various public keys into the authorized keys file in your server user’s home folder. Copying around your private key like that is just BAD security and not how public key authentication is designed to work. It’s not as if the only two options are your bad way or passwords.
As an example, you copy your single private key to various devices and even carry (a probably un encrypted) copy around with you on a thumb drive, while I generate a fresh key set from each client that I use to connect. When your private key is compromised (when, NOT if), you must remove that public key from your server to lock out the bad actor, but that also completely locks you out. Unless you have physical password access to the machine at the moment its compromised, you’re also locked out. When one of my keys is compromised, I can just exclude that machine’s key from my authorized keys list on the server and continue accessing my machine remotely via any of the other uncompromised clients.
Why are you trying to reuse an ssh key? That seems like a really bad practice. It’s just not the way key pair authentication is supposed to work. Passing around and sharing private keys is BAD. Client devices create their own private keys and only share public keys. Just create a new key from ConnectBot and get it to your server via other methods. If you’re already away from home without any other means of connecting, that last part is admittedly tricky and you may be SOL.
Isn’t ConnectBot a dead project anyway? Last I checked, it hadn’t been updated in years. Well, I guess I was wrong here. I can’t find a simple full list of all the past updates, but I seem to remember moving away from ConnectBot because it lacked some feature I wanted and no longer worked on my new Android device. I’ve been satisfied with JuiceSSH, but I’m happy that ConnectBot is still alive since it was one of the first apps I installed on the first generation Android phone.
Combination wifi & router devices are notoriously unstable. Those provided by ISPs are particularly bad. If you have the ability and the funds, spend a little more to get a prosumer router and wireless AP as separate devices that connect to your modem in bridge mode. In the long run, for me anyway, the stability and reliability of this kind of setup paid for itself quickly in less of my time wasted. My setup: my own cable modem per the specs my ISP provided, a unifi edge router X, and a unifi AP. I already had a server so I installed the AP management software on it, but unifi also sells a single board device to run that. Everything except the AP live in a little electronics cabinet tucked away. The AP gets it’s power over Ethernet, so it can be mounted to a better placement with regard to walls, doors, pipes, etc. on a wall or ceiling with only a length of Ethernet cable running to the router. The AP itself just looks like a hand sized bump of white on the wall. I turned off the AP’s status lights once it was setup so that it remains as discreet as possible. Adding a WiFi repeater from unifi nearer to the one room I still had a little trouble with was almost as easy as plugging it into the wall outlet.
Not everyone can or should go this route, and it was a learning experience for me with some growing pains, but in the end it was worth it to me. UniFi isn’t the only game in town either. Either way separating your network devices so that each only does one job (the modem connects, the router routes, and the AP does wifi) means that one underpowered chip isn’t being crushed under the weight of too many tasks at once.
You could spend a little for a prosumer router and AP. I have a very similar setup with a cable modem, edge router X (ubnt), a single UniFi AP, and a service running on my server (this could be replaced with a separate hardware device or Raspberry Pi, but the server is going to be running anyway). It’s been rock solid since I set it up, compared to the WiFi/router combo with open-wrt I was running before that struggled and needed restarting regularly.
Why? If the power has gone out there are very few situations (I can’t actually think of any except brownouts or other transient power loss) where it would be useful to power my server for much longer than it takes to shut down safely.