14 new of 223 responses total.
MM is like a fine wine and requires a VT52 for full appreciation.
resp:205 `export MAIL=$HOME/Mailbox`
re#211 thanks! How can I validate my account?
#200, cross, what would Grex use instead of OpenBSD?
Re 212: I think you might mean "verify" your account. Your account is already validated. To verify an account on Grex, you need to provide acceptable identification. This can, for example, be a copy of a state-issued valid ID like a driver's license or by using a validated PayPal account to purchase a minimal membership (e.g. $1). Validated PayPal accounts are determined by PayPal. As you might expect that generally means they know your real identity and there is a bank account or credit card connected with the PayPal account. Since verified users have more access to the internet, verification allows Grex to identify people who cause problems, if an agency, like the FBI, come calling (and believe me they have contactd grex before about particular users).
resp:213 Probably FreeBSD.
I noted today that one of my computers wouldn't connect to grex via ssh while another would. They are different versions of FreeBSD (11.4 worked, 12.1 didn't). Same setups of ssh_config. Anyway changing the MTU for 12.1 fixed it, which is a bit weird. I had to edit /etc/dhclient.conf and supersede the interface-mtu setting that normally is set to 1500 by DHCP and setting it to 1400 helped. Probably this is due to the ciphers that get picked in the ssh connection. Each computer picks a different one (using the same setup). So more investigations to do. I had noted someone else had seen something similar in the past couple weeks.
resp:216 I've posted more details on the trouble here: item:garage:60
Thanks, papa.
My guess is that it might have to do with the method now used for accessing Grex. I recently canceled my AT&T service, which allowed me to have static IP's at home. With that now gone, I've established a VPN between my servers in Azure and home, and am routing grex (and m-net) via static IP's I've got in Azure and home over that VPN tunnel. Exactly why this is working without incident for some ssh clients and not others I'm unsure, but that is the change that was made in the past week when this started.
re #219 This is excellent - curious how that is setup. I have a nat behind a nat at my office and want the pi there available for sshd from home and elsewhere. Not sure how to go about it.
resp:220: What I did was created a vm at home to route the tunnel, and established a strongswan tunnel between the two sites. I then created an iptables rule to create a route to my network via the tunnel: -A POSTROUTING -s 10.0.0.0/24 -d 192.168.0.0/20 -j MASQUERADE and the opposite on the other end of the tunnel: -A POSTROUTING -s 192.168.0.0/20 -d 10.0.0.0/24 -j MASQUERADE For the Azure side, I also route the additional bound IP's over the tunnel back home via: -A PREROUTING -d 10.0.0.9/32 -j DNAT --to-destination 192.168.0.110 -A POSTROUTING -d 192.168.0.110/32 -j SNAT --to-source 10.0.0.9 strongswan starts on boot, and I've put the iptables rules in the appropriate file for the OS (ubuntu/centos), so everything comes up on boot and strongswan monitors the tunnel so it automatically restarts should it drop. It ended up working out quite well, and it was much easier to get it running than I'd expected.
re #221 Very tidy, indeed. Thanks for the rundown!
The machine grex is running on had more disk space added yesterday. That took it offline and made it appear the SSH security info had changed. It's back up now and everything should be back the way it was before the changes. Thanks go to Tony for keeping grex going.
You have several choices: