I have an iMac that I use somewhat as a server, and a Macbook laptop. For months I've opened a terminal on my laptop, typed "ssh user#host" (with more useful choices for 'user' and 'host', and was promptly rewarded with a "Password:" prompt, then the normal '$' prompt. Today it doesn't give me the $ prompt aftr a correct password. As a test, I gave an invalid pssword, and was rewarded with another prompt for password. The final test was to open the Terminus app on my iPhone, and got immediately to the $ prompt.
What might be the problem here, and where do I look first for a solution?
The first thing to try is:
ssh -v user#host
to get verbose messages.
If you have recently upgraded the server to macOS Ventura and you used to use RSA keys, you will probably need to log into the server and edit /etc/ssh/ssh_config and add the following two lines at the end since Apple tightened up security to disallow that older, relatively less secure method:
HostkeyAlgorithms +ssh-rsa
PubkeyAcceptedAlgorithms +ssh-rsa
Related
1st I followed the answer at this thread: How to run ssh-add on windows?
2nd typed this: ssh-add .ssh/gitea_key
It worked for git bash, but not for Sourcetree.
After turning on the ssh agent, Sourcetree still asks for the password EVERY TIME I open it or close the Options. This is pure madness! In addition now it gives me this error:
'ssh-agent' failed with code -1: Sstem.ComponentModel.Win32Exception: Access is denied 0
I just want it to save the password, this is crazy hard or almost impossible to achieve. This is so ridiculous.
On a Mac (Big Sur) machine, I can easily get a password from the keychain via the command line:
security find-generic-password -l Foo -w
But, if I ssh into that same machine, the exact same command returns nothing.
Any ideas why that would be happening?
Jeff Holt's response helped me.
Indeed the remote keychain was locked and can be unlocked with security unlock-keychain. If you are interacting via the command line perhaps using a script you can test for whether the default keychain is unlocked with show-keychain-info which returns a non-zero value when locked.
In bash selectively prompt to unlock the keychain (with squashing of the redundant text output of show-keychain-info to stderr):
if ! $(security show-keychain-info 2> /dev/null); then
security unlock-keychain;
fi
I have a script written in bash and tested working in Linux (CentOS 7) and on MacOS. The script uses cURL to interact with a REST API compliant data platform (XNAT).
I was hoping that Windows users could use the same script within git-bash that comes packaged with Git for Windows. Unfortunately there seems to be an issue when using cURL in git-bash.
The first use I make of cURL is to retrieve a JSESSION cookie:
COOKIE=`curl -k -u $USERNAME https://theaddress/JSESSION`
On Linux, this asks the user for password and stores the cookie in COOKIE.
In git-bash, issuing the command hangs, until using a "ctrl + C" to interrupt it. Strangely at that point the query message for the password is displayed, but too late, the script has terminated.
I have a suspicion that this may have to do with CR or LF issues, but cannot find some info I understand regarding this.
Any pointers would be welcome !
Thank you
EDIT:
It appears the above command works fine if I pass the password in the command like this:
COOKIE=`curl -k -u $USERNAME:$PASSWORD https://theaddress/JSESSION`
However, as pointed here:
Using cURL with a username and password?
I would rather avoid having the user typing their password as a command argument.
So the question is now "why is cURL not prompting for a password when I use the first command?" when in git-bash on Windows, while that command behaves as expected in Linux or MacOS:
COOKIE=`curl -k -u $USERNAME https://theaddress/JSESSION`
Ending up replying to my own question, hope this may be useful to someone else.
It appears this issue is a known problem when running cURL from within git-bash, according to this thread:
https://github.com/curl/curl/issues/573
In particular, see the answer of dscho on 30 Dec 2015:
The problem is the terminal emulator we use with Git Bash since Git for Windows 2.5, MinTTY.
This terminal emulator is not associated with a Win32 Console, therefore the user does not see anything when cURL wants to interact with the user via said Console.
This issue has a workaround, which is documented here:
https://github.com/git-for-windows/build-extra/blob/master/ReleaseNotes.md#known-issues
The workaround is to run curl via winpty as follows:
winpty curl [arguments]
Not an issue with CR or LF after all.
Soooo, git-bash may not be the magic-bullet (tm) to run my bash scripts in Windows with zero effort. Sigh...
I have an interesting dilemma with PuTTY PSFTP.
Set up...
Pageant .60
putty .60
Used command:
D:\psftp.exe -load myserver.domain.us.com -l User1 -b MyCommand Script
This loads PuTTY PSFTP, logs in using the user ID with the help of Pageant and then sends a file using commands in the script.
This works great while logged in as an Admin on the server.
It fails while logged in as a regular user on the server:
"psftp: no hostname specified;"blah blah blah.
Including -v reveals no further messages.
What possible delta could there be with permissions or other settings between a server Admin and regular user when it comes to PuTTY?
You load PuTTY stored site myserver.domain.us.com.
That is stored in Windows registry of the local account.
If you run the script using a different account, it won't see the site definition.
You have to define the session completely on command line. What you probably even attempted.
Remove the -load;
Add -ssh to make it clear you want to use SSH (but it's default anyway)
Add -hostkey=... with a fingerprint of the SSH host key (you need the latest version of PuTTY for the -hostkey switch, but you need to upgrade anyway, the version 0.60 is not secure).
D:\psftp.exe -ssh myserver.domain.us.com -hostkey=... -l User1 -b MyCommand Script
After upgrading to MacOS Sierra (10.12), my sudo command seems to be acting differently. See the following test case:
# Run in terminal pane #1: (should prompt for password)
sudo -v
# Run in terminal pane #2: (should NOT prompt for password)
sudo -v
The above works as expected on earlier versions of OS X. However, on Sierra, the second command prompts for the password again. It does not prompt for the password within the same terminal pane. This seems to only happen for the root user; the following works as expected on all OS versions including Sierra:
# Run in terminal pane #1: (prompts for password)
sudo -v -u "$USER"
# Run in terminal pane #2: (does not prompt for password)
sudo -v -u "$USER"
Looking at /ect/sudoers, the timestamp_timeout value is not set to 0. I've briefly looked over the changelog for 1.7 to 1.8 but could not come up with anything significant other than there being a mention of a policy plugin for Sierra when running sudo -V.
Can anybody help me figure out what has changed? I have a script that relies on the sudo timeout value for a keepalive and on Sierra it is prompting for the password constantly since it seems to no longer use a timestamp for the root user.
After a ton of searching and comparing the sudo configuration on older OS versions to Sierra's (sudo su; sudo -V), it seems that Sierra enables tty_tickets by default now, causing the issues mentioned above. As far as I can tell, this was an undocumented change. To fix, the following needs to be added to the /etc/sudoers file via running sudo visudo,
Defaults !tty_tickets
TLDR; BAD IDEA. This old behavior, while an option to sudo, is used as a default by NO OTHER UNIX-y OS that I have ever encountered. The reason being that it's trivial to exploit, and when exploited, the malignant code doing so will have full control of your system.
Original very long rant-y post, correctly pointed out to be blahdiblah:
LOL, this is funny. I came here from googling because I couldn't remember how I would change the old behavior to this new, correct one (used by every other UNIX-y OS out there). Hadn't even noticed my new Sierra Mac now behaved properly.
I wrote on the Mac forums earlier about this previous behavior which is a gaping security hole. I even supplied a three-line proof-of-concept script that would simply sit around (as a regular user) waiting for a sudo event to appear anywhere, then instantly gain root access to the system. I was booed out of the thread by the fanboys, then got banned from it from calling out lies. Seems Apple were listening, though. Good job, for once, Cupertino. Bad, BAD idea to try to get the old behavior back.
For reference, here's the three-liner. It doesn't do anything malignant, just adds a dummy file to the root of the filesystem once gaining sudo. Run it in a script (or just paste it somewhere which doesn't already have sudo), then either do a sudo in another terminal app/window or app which uses sudo (e.g. TrueCrypt/VeraCrypt or similar), then watch it work.
tail -f -n 0 /var/log/system.log | grep -m 1 -E 'sudo\[[0-9]+\]:\s+'$USER
echo "Gonna play around with root privs ..."
sudo touch /kilroy-was-here