I just upgraded to Xcode 10.2 from 10.1. I did my first git push in the new version. Xcode displayed message in a dialog.
The identity of a repository hosted on “git.example.com” has changed.
The fingerprint ‘AAAAAAAABBBBBBBBCCCCCCCCDDDDDDDD’ for this repository
has changed since it was trusted. You might be connecting to a
repository that is pretending to be “git.example.com”, which
could put your confidential information at risk. Would you like to
connect to the repository anyway?
I killed Xcode 10.2. I started up Xcode 10.1 again. I did a git push operation, and it succeeded. This proves that the git repos host did not change fingerprints. It strongly hints that Xcode 10.2 determines ssh host fingerprints differently than 10.1.
My guess is that Xcode does not use ~/.ssh/known_hosts otherwise 10.2 would behave the same as 10.1.
I pressed "Trust" in the dialog and noted the time.
I saw no new entries in Keychain. I immediately went to Terminal and ran find . -mmin -3 in ~/Library/Developer/Xcode and saw no relevant files changed. File ~/.ssh/known_hosts was not updated.
So, where does Xcode 10.2 store its ssh known hosts info? Could I have somehow pointed Xcode 10.2 to the ssh known hosts fingerprints that 10.1 was using?
I don't known about Xcode 10, but for Xcode 12 it seems Xcode's list of trusted SSH hosts is in ~/Library/Preferences/com.apple.dt.Xcode.plist, in IDESourceControlKnownSSHHostsDefaultsKey.
Related
I've got a strange behaviour of ssh and ssh-keygen: they do not react at all. Cygwin is started with admin rights and works normally. The host 192.168.1.1 is up and I can remote desktop to it:
When I try:
$ ssh -vvv pi#192.168.1.1
OpenSSH_8.3p1, OpenSSL 1.1.1f 31 Mar 2020
I get only one line but nothing else, even if I wait hours. I reinstalled cygwin, openssh, I deleted the .ssh folders, no success.
When I enter
ssh-keygen -b 4096
nothing happens at all. For me it seems that the user interaction does not work. Any ideas?
Thanks
Update: I tried:
reinstalling cygin for all users, one user, running the installation with admin rights, without. No success.
Started ssh and ssh-keygen with an absolute path to make sure that the windows openssh is not used
Checked the folder permissions on .ssh
Here is my strace: Pastebin
Update 2: I found the following: if I run ssh-keygen or ssh often enough (!) it will sometimes work! Now that's weird.
Philippe had the right idea. Basically the citrix workspace app is crashing ssh cygwin. When I uninstalled citrix everything worked fine!
I found that it is down to a bug in epclient64.dll of citrix: it crashes my ssh in my internal network. After uninstallation of citrix it would work normally. Here is the log
Pastebin log of strace
https://pastebin.com/FJfUj3C1[Pastebin][1]
Without the app protection it works fine. So to sum up:
with app protection ssh crashes again and again, it does not even start properly
without citrix ssh works fine
citrix without app protection ssh works fine
--> epclient64.dll does not work with ssh
And we are talking about the most recent versions of ssh & citrix as of Jan 2021.
I found that when I uninstalled citrix, it had no effect.
I opened up the folder in Windows Explorer where the ssh.exe resides. I right clicked on this executable, navigated to Compatibility tab, selected Run this program in compatibility mode for "Windows 8". Then I at least got a response from the command line, but it would never connect to the host I entered. It would get stuck and I would have to kill it from taskmgr.
When I ran whereis ssh, I had 2 versions in Cygwin, one in /usr/bin and one in /cygdrive/c/WINDOWS/System32/OpenSSH. So what I did was to move the /usr/bin version to a backup file and create a link in a cygwin shell to /cygdrive/c/WINDOWS/System32/OpenSSH/ssh.exe. Now it works like it used to.
By the way my OpenSSH version is "OpenSSH_for_Windows_7.7p1, LibreSSL 2.6.5" running on Windows 10.
I have installed NetBSD 6.1.5 with full installation setting. However, when I run startx it says no screens could be found. So i tried "X -configure" and then "X -config ~/xconfig.conf.new" and I was brought to a very generic screen with a black x crosshair, but I was unable to exit this using the suggested ctrl+alt+backspace, so I had to force power off and check if my keyboard was recognized in the conf file generated, which it was. I have installed xdm, xterm, Xorg, and other X programs.
I am not familiar with setting up desktop environments from scratch. I am a newb who is used to Ubuntu esque installers doing that stuff for me.
Would someone be able to walk me though the installation or point me to a link which explains a step by step process?
What happens if you rename your xorg.conf.new to /etc/X11/xorg.conf? Does startx or xdm work then?
Are you running this inside a VirtualBox or other emulator?
I have NetBSD on a Thinkpad T420 which I occasionally boot into Windows, and I've setup VirtualBox to be able to run the same NetBSD install when I'm in Windows. The key difference in the xorg.conf file is in the Device section:
Section "Device"
Driver "vesa"
EndSection
Also I've found the free version of http://mobaxterm.mobatek.net/ very handy - I use it to ssh into the virtual NetBSD box and then run X apps and have them display on the Windows desktop.
Final note - you might want to look out for the NetBSD-7 RC1 which should be out 'Real Soon Now', as there are some very handy improvements, including better support for most modern display hardware :)
I found that running startx from any directory with a .xinitrc file gives strange behavior in amd64 6.1.5 and 6.1.4. Delete (or rename) any .xinitrc files and try
xinit /path/to/windowmanager
Please read Chapter 9 of NetBSD Guide:
http://www.netbsd.org/docs/guide/en/chap-x.html
Section 9.9 discusses installing various Desktop Managers/Environments.
It turns out that I could run "X -config xorg.conf.new" as root on host and then ssh using putty to manually launch windows.
I seem to be having issues with integrating Xcode6 with jenkins, I currently have this setup and working with Xcode 5.
With xcode 6 running remotely via SSH the simulator time-out, when I run locally it succeeds.
Command
xcodebuild -workspace PROJECTNAME.xcworkspace -scheme BGO_Tests -destination 'platform=iOS Simulator,name=iPhone 5s' -derivedDataPath ./Build clean test
2014-08-19 10:46:36.591 xcodebuild[33966:381f] iPhoneSimulator: Timed out waiting 120 seconds for >simulator to boot, current state is 1.
Testing failed:
Test target BGO_Tests encountered an error (Timed out waiting 120 seconds for simulator to boot, current state is 1
Tested with recent Xcode 6 beta 6
Note: the device names changed in Xcode 7, so you no longer specify them using iPhone 5 (9.1 Simulator) but rather iPhone 5 (9.1).
Use xcrun instruments -s to get the current list of devices and then you can pre-launch it using:
xcrun instruments -w "iPhone 5 (9.1)" || echo "(Pre)Launched the simulator."
Prelaunching
I got to a point where what I proposed down there wasn't working anymore. In addition to making the changes mentioned here, you need to launch the simulator xcodebuild is expecting BEFORE xcodebuild is ran:
# First get the UDID you need
xcrun instruments -s
# Then launch it
open -a "iOS Simulator" --args -CurrentDeviceUDID <sim device UDID>
# and wait some time....
sleep 5
# Then launch your unit tests
xcodebuild [...] -destination 'platform=iOS Simulator,name=<device name matching the UDID>'
Old post
This bug is fixed in Xcode 6.3 and above. If you are experiencing similar problems in newer Xcode, it's likely another bug.
Apple follow up regarding Bug ID# 18001199:
The context provided by LaunchDaemons is not supported for running GUI
applications. The SSH service, and the default setup for Jenkins, are
both implemented as LaunchDaemons. In earlier versions of Xcode 5
xcodebuild could run tests on the iOS simulator in this context, but
that was never a supported configuration, and as you have noted that
is no longer working as of Xcode 6.
Unlike LaunchDaemons, LaunchAgents provide a context where you can run
GUI applications - if the user is logged in at the time, with a window
server / Aqua session. Converting your Jenkins configuration from
being a LaunchDaemon to being a LaunchAgent would avoid the reported
issue. You can also use launchd for running tests on the iOS simulator
from a SSH session, either by crafting a LaunchAgent and manually
loading / starting that, or by using "launchctl submit”.
Ok, after some more digging around the comments around here (many thanks to Opal), I found out that launching the slave via JNLP instead works.
As many people mentioned, it is not currently possible to run the unit test over SSH, so you might want to turn towards the JNLP agent for now until Apple fixes it.
If connecting with JNLP still does not solve it, try the solution mentioned in this comment.
i.e.: Run these on command line:
DevToolsSecurity -enable
sudo dscl . -append /Groups/_developer GroupMembership "user-that-runs-the-sim"
security authorizationdb write system.privilege.taskport is-developer
See References here and here.
I've recently found out that if you install a new version of Xcode and do not launch it. The simulator might start timing out again. To solve this, I've had to manually launch Xcode, and install the additional tools it requested.
I ended up solving this on Xcode 5 by doing the steps here, essentially running:
sudo security authorizationdb write system.privilege.taskport allow
This will eliminate one class of these authentication popups. You’ll also need to run:
sudo DevToolsSecurity -enable
However, once I upgraded to Xcode 6, I now get an infinite hang when trying to run xcodebuild tests over SSH. They continue to run just fine as long as I'm logged into the console, and running them from the keyboard.
I ran into the same issue. My working theory is that SSH on OSX is started as a LaunchDaemon, and LaunchDaemons are not allowed to present a UI; Reference.
I was able to work around the issue by using Java Web Start to launch the Jenkins slave. I then installed the Jenkins slave as a launchd service.
Unfortunately the Jenkins slave then installs itself as a -you've guessed it- LaunchDaemon, leading to the exact same problem of not being able to launch the tests; Reference.
I worked around that issue by moving the Jenkins Slave LaunchDaemon plist and jar files in /System/Library/LaunchDaemons into ~/Library/LaunchAgents, and updated the paths inside the plist file.
That finally allowed me to run XCode6 (Beta6) tests on an OSX jenkins slave.
I finally managed to find a good simple solution. JNLP was causing numerous issues with our jenkins server.
Workaround for SSH timeout via https://corner.squareup.com/2015/07/ios-build-infrastructure.html
"Mavericks (10.9) and Yosemite (10.10) determine if a process can access accessibility hooks via the parentage of the accessing process. By putting launchd in the list of allowed processes, processes launched via SSH or Jenkins have access to the accessibility hooks across the system. To do this you can modify the TCC database, per this gist. A reboot is required to make the change take effect."
#!/bin/bash
# This will add lauchd to the list of allowed processes for accessibility access
sudo sqlite3 /Library/Application\ Support/com.apple.TCC/TCC.db "INSERT or REPLACE INTO access VALUES('kTCCServiceAccessibility','/sbin/launchd',1,1,1,NULL)"
# This outputs the rows in the TCC database
sudo sqlite3 /Library/Application\ Support/com.apple.TCC/TCC.db 'select * from access'
echo "Restart is required for these changes to take effect"
Update 8/02/2016
This is now fixed in Xcode 7.2.1 ("Command line tool ‘xcodebuild test’ will no longer time out waiting for Simulator.app to launch")
I've seen this error before, one possibility is that since you probably downloaded the Xcode6 Beta from the internet (not the appstore as its not available yet), the machine you are trying to run it on will show a pop up asking you if you really want to open this app as its from the internet.
The same will happen when xcodebuild tries to launch the iPhone simulator app.
One thing you might want to try is to share screen with the machine and click "Open" in that pop up.
If that still doesn't work, I would try to:
Reset the Content & Settings of the simulator
Reboot the machine and make sure no simulator is running on start up (you can just choose not to re-open any app when restarting)
I am using OSX 10.7.5 from my MacBook Air to login to remote Linux workstation, running Suse (/etc/issue: SUSE Linux Enterprise Desktop 11 SP2 (x86_64) - Kernel \r (\l))
Everything was working fine until I started to play with macports latest X11, XQuartz XWindow System (XQuartz 2.7.4 (xorg-server 1.13.0)). By default OSX 10.7.5 comes with XQuartz 2.6.4 (xorg-server 1.10.6), however I've installed and made default XQuartz 2.7.4. I am now observing two issues:
(1) When logging to my remote Suse box (this is done via VPN tunnel btw, not sure if it matters), via 'user1> ssh -X user2#wks01' I am getting
Warning: untrusted X11 forwarding setup failed: xauth key data not generated
This (at least appears) to be traced to the fact that there's no 'Security' extension on the new Xquarts server. Traced via ssh -vvv option, and then due to the fact that xauth is failing, so running it separately on MacBox, or remote Suse gives:
user2#wks04:~> xauth generate "$DISPLAY" .
trustedxauth: (argv):1: couldn't query Security extension on display "localhost:10.0"
'ssh -Y' logs in without warning
(2) What is also interesting, that in both ssh modes -X and -Y I am able to open and forward to my display any X-application that I have checked, including xclock, xlogo, xcalc and even eclipse. However running simple 'xterm' results in a hanging job (i.e. appears running), but xterm never displays on my Mac.
While rolling back to will XQuartz 2.6.4 probably help with the issues above (as all the above operations worked smoothly before), but I am curious now to understand the root of the matter.
Thank you in advance for your help,
Dmitry
I am trying to ssh into a remote Linux server using x11. I found that Mountain Lion no longer supports x11 when I upgraded, so I installed Quartz. However, my terminal commands are not working anymore. Here are two important terminal commands that no longer work for me.
I did a Google search and looked elsewhere on Stack Overflow, but didn't find what I am looking for. Namely, I was hoping there are some new commands that work with Quartz in place of the standard x11 phrases I have been using. I tried these after I installed Quartz on my machine, and it didn't work. I just taught myself these x11 commands on 10.7 when 10.8 just came out. Here are a few examples.
1.
ssh -X username#serverlocation.com
2.
./configure -- this/is/an/example/directory --enable--gdb --with-x -with-x11 --with-term --with-nogui
If anyone could tell me how to get this working with Quartz on Mountain Lion, I would be grateful. Otherwise, I would have to run a VM on my Mac with either Windows and putty in, or try to figure out how to use x11 on my Ubuntu machine.
Have you logged out/in after installing XQuartz? XQuartz is just a distribution of X11 and is completely compatible with what was previously included with the OS X.