Does current PCI code require SSH connections be restricted to
enumerated (specific) client IP addresses on the unsecure, dirty side?
Not really. PCI dictates that there should be firewall rules in place to limit access, but if you can justify an any -> 22/ssh rule, then you've satisfied PCI.
Isn't that outside the scope of the PCI code?
It is very common to see login attempts in the logs. As long as you see the "publickey" message you are good to go.
For example, have a look, I just tried on my AWS instance which only has pubkey auth:
➜ ~ ssh heysecuritystack@x
heysecuritystack@x: Permission denied (publickey).
And this is how it looked on my logs:
Apr 8 07:37:25 ip-x sshd[...
Assuming that there is no active MITM attack going on (which can be detected by properly checking the host keys when connecting to rpi), the server sees only the SSH traffic between laptop and rpi.
Since the payload is encrypted in SSH the server can only do some broad traffic analysis (i.e. source, destination, timing, size of data, ...) but not see or even ...
While Conor's answer remains the answer to this question, I'm dropping here the solutions I ended up considering for this matter, in case they could help someone else in the same situation. In my specific case the solution had to be implemented purely at system level (hence no awareness from the applications that their logs are being sent/streamed somewhere ...
Using it with the -p option is what most people talk about but it has other, more secure options, too.
You can also use sshpass with a GPG-encrypted file. When the -f switch
is used, the reference file is in plaintext. Let's see how we can
encrypt a file with GPG and use it.
First, create a file as follows:
$ echo '!4u2tryhack' > .sshpasswd
A common analogy for asymmetric cryptography is a padlock and key. Like most analogies, it will fall down if taken too far, but I think it serves as a good top level explanation for questions like this.
The analogy goes something like this:
Alice wants to put something in a locked box, and let Bob open it, but she's worried someone will make a copy of the ...
If I am not wrong, both private key and public key are the same
Unfortunately, you are wrong. The private key and the public key are not the same.
The entire idea of public key cryptography depends on this difference. The public key is public, it can be published, it can be widely disseminated. The private key is private, it must be kept secret.
If you are using OpenSSH server, then be aware that there is a bug that can prevent authorization if there are more than 5 keys in the default .ssh directory. Here is the explanation directly from ssh.com
OpenSSH's limitation on the number of private keys
The OpenSSH server has a feature (I would call it a bug) that it counts testing whether a particular key ...