So I have tried and tried to get my ssh to work with kerberos on Mavericks to no avail. Here are my versions:
ssh: OpenSSH_6.2p2, OSSLShim 0.9.8r 8 Dec 2011
kerberos: Heimdal 1.5.1apple1
I also tried the built in ssh with no effect as well. Here is my config:
ForwardAgent yes
GSSAPIAuthentication yes
GSSAPIDelegateCredentials yes
GSSAPIKeyExchange yes
i have checked, there are no overriding settings in my user config
After all of this, I still get prompted for a password when ssh'ing to a linux host that does work with linux clients. (I am able to successfully kinit and i do get a ticket)
Any clues what I am missing? Has anyone has this problem before.
HERE is a link to the ssh connection log. It just seems to abandon gssapi without even trying it... why????
NOTE ON OSX SIERRA:
It appears that Apple broke it again.... The gssapitrusdns stuff is actually a third-party contribution and Apple revved to a newer ssh that doesn't include those patches... See HERE and HERE
ORIGINAL ANSWER (pre Sierra):
Ok, so after even more head-scratching, giving up, and violent attempts to strangle my computer with a power cord, I have found the answer... Turns out, OSX need to be told to explicitly trust DNS.... Add the following line to your ssh config:
GSSAPITrustDNS yes
Source (check the 'Problems and Workarounds' section)
From the logs it looks like server is sending "gssapi-keyex,gssapi-with-mic" methods but somehow client doesn't have support for it.
Look at this logs
preferred publickey,keyboard-interactive,password
can you check your client whether it supports it or not ?
you can check client config file /user//.ssh/config -> on linux system.
Related
I've got a macOS 10.13 server running, on which I have recently had to change the hostname (upstream IT requirements) - and I suspect this has broken Kerberos.
Changing the hostname appears to have been successful: I exported the Open Directory setup, modified it, and reimported it into the updated setup - user accounts exist, and manual authentication works as expected. changeip is happy:
mac-mini:~ server_admin$ sudo changeip -checkhostname
dirserv:success = "success"
However SSO from client machines does not appear to be successful.
Attempting to run kinit with a valid user account shows this:
mac-mini:~ server_admin$ kinit test#MAC-MINI.EXAMPLE.COM
test#MAC-MINI.EXAMPLE.COM's password:
kinit: krb5_get_init_creds: Server (krbtgt/MAC-MINI.EXAMPLE.COM#MAC-MINI.EXAMPLE.COM) unknown
Looking at /etc/krb5.conf, I only see this:
[libdefaults]
kdc_timeout=5
...which is the same as it was on my previously-working configuration.
And now I'm a bit stumped. All the documentation for destroying and rebuilding Kerberos setups seem to be out of date. Any ideas?!
Thanks.
I builded MariaDB 10.4 using GitHub source on CentOS 8.
(https://mariadb.com/kb/en/get-build-and-test-latest-mariadb-the-lazy-way/)
But mariadb-secure-installation is not working.
There is no error when running it. But nothing works. For example, changing the root password or deleting an anonymous account does not work.
What should I check?
thank you.
I figured out why.
https://serverfault.com/a/897341
https://mariadb.com/kb/en/authentication-plugin-unix-socket/
In MariaDB 10.4.3 and later, the unix_socket authentication plugin is installed by default, so if you do not want it to be available by default on those versions, then you will need to disable it.
there are two solutions.
disable unix_socket authentication
# /etc/my.cnf.d/server.cnf
[mariadb]
...
unix_socket=OFF
# or
disable_unix_socket
...
set client to use TCP protocol
# /etc/my.cnf.d/client.cnf
[client]
protocol=tcp
or using '-h' option
# mysql -h 127.0.0.1 -u root -p
My eventual workaround for the issue below was to convince our IT guys not to man-in-the-middle the dockerhub registry. I was not able to get anything else to work, alas.
I am running into a problem with my initial attempt to get Docker running on my Mac at work, which is running 10.8.5. It appears that my company's certificate-rewriting proxy seems to be getting in the way of fetching images:
orflongpmacx8:docker pohl_longsine$ docker run hello-world
Unable to find image 'hello-world:latest' locally
Pulling repository hello-world
FATA[0001] Get https://index.docker.io/v1/repositories/library/hello-world/images: x509: certificate signed by unknown authority (possibly because of "crypto/rsa: verification error" while trying to verify candidate authority certificate "bcauth")
(Indeed, when I log onto the guest wireless – which does not have the meddlesome proxy – I can get past this step. However, I need to figure out how to make this work through the proxy since using the guest wireless is untenable as a long-term solution.)
My issue, on the surface, appears to be very much like the one answered in this question. However, the accepted answer in that question does not work for me, since the root_unix.go file they discuss does not get invoked on a Mac. (From browsing around, I would guess that root_cgo_darwin.go and/or root_darwin.go would be involved instead.)
That doesn't really tell me how, operationally, I need to do the equivalent work of installing some sort of trusted certificate. I managed to get my hands on a *.cer file that I believe to be the one that I need, but I'm at a loss as to what to do with it.
I'm hoping that someone can point me in the right direction.
Edit: I thought that maybe I needed to to something akin to what this page suggests, to add the certificate. Alas, my attempt at following those instructions failed in the following way:
orflongpmacx8:docker pohl_longsine$ sudo security add-trusted-cert -d -r trustRoot -k "/Library/Keychains/System.keychain" "~/Desktop/Certs/redacted.cer"
Password:
***Error reading file ~/Desktop/Certs/redacted.cer***
Error reading file ~/Desktop/Certs/redacted.cer
Edit 2: I may have come one step closer to solving this. I should have known better to use a path with a tilde inside quotation marks. If I use an absolute path instead, I can successfully run the above command to add certs.
Alas, this did not alleviate the ultimate symptom:
FATA[0001] Get https://index.docker.io/v1/repositories/library/hello-world/images: x509: certificate signed by unknown authority (possibly because of "crypto/rsa: verification error" while trying to verify candidate authority certificate "bcauth")
According to the boot2docker README
Insecure Registry
As of Docker version 1.3.1, if your registry doesn't support HTTPS, you must add it as an insecure registry.
$ boot2docker init
$ boot2docker up
$ boot2docker ssh
$ echo 'EXTRA_ARGS="--insecure-registry <YOUR INSECURE HOST>"' | sudo tee -a /var/lib/boot2docker/profile
$ sudo /etc/init.d/docker restart
then you should be able to do a docker push/pull.
The source of http://golang.org/src/crypto/x509/root_darwin.go shows that the command:
cmd := exec.Command("/usr/bin/security", "find-certificate", "-a", "-p", "/System/Library/Keychains/SystemRootCertificates.keychain")
is used to find the certificate.
Try adding the .cer file into the OSX certificate key-chain.
If you use the docker-machine
edit $USER/.docker/machine/machines/default/config.json
"EngineOptions": {
"InsecureRegistry": [
"XXX.XXX.virtual"
],
}
I am facing an issue while sending request to server for push notification. While trying to connect to apple server we are getting the following response,
ApnsPHP[15748]: INFO: Trying ssl://gateway.sandbox.push.apple.com:2195... Tue, 15 Jan 2013 08:20:28 +0100 ApnsPHP[15748]: ERROR: Unable to connect to 'ssl://gateway.sandbox.push.apple.com:2195': Permission denied (13)
We checked the server settings and the server is not blocking any out going requests. We created the p12 certificate as per the guidelines by apple, and we are converting it to .pem by executing following shell command in the server.
openssl pkcs12 -in HSPushNopassword.p12 -out HSPushNopassword.pem -nodes -clcerts
And the same code and certificate is working fine in another server.
Please let me know why we are getting this error? Thanks,
There is a better solution than disabling SELinux completely. The problem is that on most SELinux systems (as RedHat, which I am using) HTTPD is not allowed to create network connections.
You can use this command to enable it:
setsebool -P httpd_can_network_connect=1
-P for permanent setting.
I hope it helps, though this thread is accepted
I sorted it out. Yes, the problem was the server, but it was likely due to when they had root and reloaded things. In a nutshell, there is a very restrictive security system called 'selinux'. So I disabled that, and set the config so it stays off after reboot. And the push notification is working fine now.
I made my own git server on a centos distribution.
I can contact the server via git protocol at my home. But when I try to access via https at office I obtain:
Cloning into /Users/vito/Documents/... error:
error:14077458:SSL routines:SSL23_GET_SERVER_HELLO:reason(1112) while
accessing https://gitolite#myserverxyz.com/vitorepo.git/info/refs
fatal: HTTP request failed
Where is the problem? On my server or on my office-mac?
I got the exact same response from curl when trying to connect with an ubuntu instance running openssl 1.0.0e. I successfully resolved the problem by adding the -ssl3 flag to the curl command.
It seems that it's a compatibility problem between older version of OpenSSL (0.9.8) acting as a client and recent OpenSSL version (1.0.0) acting as a server with some specific options used by Curl on client side and Apache on server side.
It's probably due to some recent security fix in OpenSSL (probably the one against protocol downgrade attacks).
Try upgrading the OpenSSL library version on the client side to 1.0.0.
See:
https://sourceforge.net/tracker/?func=detail&atid=100976&aid=3395520&group_id=976
In case anyone has this issue with XMLRPC.
Daniel's answer (forcing SSL version 3) solved the issue for me. just specify XMLRPC_SSLVERSION_SSLv3 in the clientXmlTransport_curl options (C++).
The problem began when we upgraded our server to OpenSSL version 1.0.1-4ubuntu5.5 and the clients were still running 0.9.8o-5ubuntu1.7.
I believe this is a host-name matching issue on the server. Error 1112 is SSL_R_TLSV1_UNRECOGNIZED_NAME, and comes from an SNI name mismatch (info on SNI). I was having the same issue in curl.
For me, the work around was to make sure the name I used on the client matched one of the ServerName or ServerAlias configurations on the server. Of course, these commands are for an apache server; I don't know what you need to do for a git server. But I suspect the server names you're using from home and work are different, and the home name is the cannonical name the git server is using (and therefore SNI is working).
The 'real' fix will probably take a client change in git to allow a way to ignore the name-mismatch warning (the way your browser already does).
Not sure if I had exactly the same problem, but the error message was the same. It only seemed to be happening on the ubuntu box I set up a git server on, for some reason the centos box with a git server set up on it was fine.
I only just solved it after 3 or 4 days. It turns out to be because git's underlying Curl library has a broken Keep-alive implementation (I ended up dumping HTTP traffic and verifying the behaviour by hand).
In a nutshell Curl (at least the version used inside every Git implementation I could find, including command line git and eclipse's EGit) doesn't seem to correctly interpret the Connection response header, or more correctly doesn't seem to correctly interpret the absence of it.
To fix the problem you need to configure the SSL virtual host inside the apache that is serving your GIT repository with an extra directive specifically for git. Add these lines just before the </VirtualHost>.
BrowserMatch "git" nokeepalive ssl-unclean-shutdown
You unfortunately can't tell apache to just downgrade to HTTP/1.0 (would be cleaner) because Curl can't handle that, but you can just tell it to force a Connection:close on every request which Curl does know how to handle.
In a misleading coincidence, if you try to test Curl directly without this change it will seem to work, because it makes a single request and then aborts. Only by getting curl to execute two requests on the same keep-alive connection over ssl will this problem become apparent.
I had the same error. The root cause seems to be incompatibility of client/server openssl versions.
I've upgraded my server with apt-get upgrade openssl and upgraded my windows git installation.
The combination of windows git client
git version 1.9.4.msysgit.0, which contains openssl version:
OpenSSL 0.9.8e 23 Feb 2007
And server with openssl version:
OpenSSL 1.0.1c 10 May 2012
seems to work fine together.