Having difficulty to get SSH with a Yubikey working with macOS monterey - yubico

I'm following the FIDO U2F instructions on https://developers.yubico.com/SSH/ on macOS Monterey with openSSH 8.6 and run into the following issue:
~ ssh-keygen -t ecdsa-sk -f ~/.ssh/id_ecdsa_sk
Generating public/private ecdsa-sk key pair.
You may need to touch your authenticator to authorize key generation.
Key enrollment failed: unknown or unsupported key type
Anyone know what I'm missing here?

Use Homebrew's OpenSSH
$ brew install openssh
Once installed, you have to override the one in your PATH by putting the openssh folder at the beginning of your PATH in your rc file like this
$ export PATH=$(brew --prefix openssh)/bin:$PATH
Once you've done that and you've sourced your rc file you should be able to generate your key
Tested on macOS Monterey and OpenSSH_8.8p1, OpenSSL 1.1.1l

Related

gnome-keyring GPG integration in headless Ubuntu server not working

I'm trying to use gnome-keyring to memorize my GPG passphrase in a headless Ubuntu server (22.04.1 LTS GNU/Linux 5.15.0-57-generic x86_64). The reason I'm trying to do this with gnome-keyring and not using the gpg-agent cache is that I'd like for the GPG certificate to be immediately accessible to be used by some systemd cronjobs when I reboot my server.
I've followed the Gnome/Keyring instructions but using pinentry-gnome3 doesn't seem to work:
No Gcr System Prompter available, falling back to curses
I've also tried using pinentry-gtk-2 like it is mentioned in GnuPG instructions and although I don't get any error, the passphrase is not stored.
When doing some debugging, I've found some weird behavior. Trying to store something in my keyring gives me this error:
$ secret-tool store --label='test' foo bar
secret-tool: Cannot create an item in a locked collection
Anyone can help me? I'm also willing to drop using gnome-keyring for something else, but I haven't found anything that would fit my use case.

Linux gpg to encrypt a file but it does nothing?

I thought this is how to encrypt a file in linux with gpg.
So,
xxx#xxx:~$ gpg -c /home/xxx/secretfilename.txt
But it does nothing but this,
usage: gpg [options] --symmetric [filename]
Any idea what this means and what have I done wrong?
You are attempting to use GPG to encrypt data without sufficient understanding. While it can do symmetric encryption, most use cases for GPG use public/private key encryption (see "public-key cryptography" in the FAQ), and the default CAST5 is not the best choice today.
First, try
gpg -v --version
to see what version of gpg you're currently working with.
Then, study!
Please have the GnuPG FAQ open for reference.
Then start with the GnuPG MiniHOWTO
Then refer to the GnuPG Manual

Connecting to a gitolite server from Windows and Eclipse

So, I followed this tutorial to install a gitolite server.
But my client machine is a Windows machine, not a Linux box.
So, instead of using ssh-keygen, I used Eclipse "ssh2" utility (in windows, preferences, general, network connections, ssh2).
I generated the .pub file and used to setup gitolite (like in the tutorial).
But it doesn't seems to work, I always get a "Connection refused: connect" when I try to connect to my server from windows using this URL :
ssh://gitolite#192.168.0.193:22/gitolite-admin
I opened the .pub files generated by Eclipse and what I find funny is that there is always 2 equals signs at the end.
For example, here's one generated public key :
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAAAgQCQbDy+Nfoq+AitTrAbxy0PwRuBmgnm/vJk27KNOB3EzsZFKQ7+89I12nbxc8N+7z4Seq9fhNrYHfM7PvzgdI8F5QLxWbl2QV0UapBpjWmX+7WEE9bjEHIf7re3FpRzVdJrCAwscaUawmsIGi1rvw8ZFrbfPdS6ITiI10WcfTEdCw== RSA-1024
Is it possible to try another key pair without having to reinstall gitolite?
Can I generate the key pairs on my linux box and just upload the private key generated on my Windows machine?
Any other help on how I can diagnose the problem would be great.
UPDATE #1 :
I found out that no ssh server was running on my server. You can see that with :
sudo nmap -sS xxx.xxx.xxx.xxx -p 22
If the port's state is closed, then your SSH service is either closed or doesn't exists.
You can also try to connect with Putty (on windows) with SSH on your Linux machine, you'll see if the SSH server is working properly.
If your SSH service is not started, you can start the service with :
sudo service ssh start
If the service doesn't exists, you'll need to install an ssh server. I installed mine (on Ubuntu) like this :
sudo apt-get purge openssh-server
sudo apt-get install openssh-server
After installing openssh, everything was working fine on my box.
First, if you have msysgit installed, you perfectly can use ssh-keygen (included in this msysgit module).
The official help page for installing gitolite can also help.
Don't worry about the two == at the end of the public key. It is normal, and what follows those two == is always ignored (for instance, you can place a comment here for you to remember what that public key is for, if you want).
Now:
Is it possible to try another key pair without having to reinstall gitolite?
.
Yes. See "lost admin key/access":
Make yourself a new keypair and copy the public key to the server as 'alice.pub'.
Log on to the server, and run gitolite setup -pk alice.pub.
.
That's it; the new alice.pub file replaces whatever existed in the repo before.
Can I generate the key pairs on my linux box and just upload the private key generated on my Windows machine?
.
No, you need both private and public key on your %HOME%/.ssh folder (which means you must have HOME environment variable defined on Windows)
I would then recommend an %HOME%/.ssh/config file to use your keys.
Any other help on how I can diagnose the problem would be great.
.
The official doc has many tips.
I have a few ssh debugging tips as well.

Automating Enter keypress not working for Linux Mint 15

I've got this post installation script I made for users of Linux Mint 14 (and also usable on Ubuntu 12.10) and now I'm testing it for Linux Mint 15 and the 'echo -ne "\n" | sudo add-apt-repository ppa:some-ppa-to-add' command isn't working on Linux Mint 15, but still works on Mint 14. I want to update this script for the new version of Linux Mint.
Here's a link to my post install scipt: The Minty Developer
The output for Mint 14 looks like this:
$ echo -ne "\n" | sudo add-apt-repository ppa:apt-fast/stable
You are about to add the following PPA to your system:
This PPA contains tested (stable) builds of apt-fast.
More info: https://launchpad.net/~apt-fast/+archive/stable
gpg: keyring `/tmp/tmpddxueh/secring.gpg' created
gpg: requesting key CA8DA16B from hkp server keyserver.ubuntu.com
gpg: /tmp/tmpddxueh/trustdb.gpg: trustdb created
gpg: key CA8DA16B: public key "Launchpad PPA for apt-fast" imported
gpg: Total number processed: 1
gpg: imported: 1 (RSA: 1)
OK
And here's the output on Mint 15:
$ echo -ne "\n" | sudo add-apt-repository ppa:apt-fast/stable
You are about to add the following PPA to your system:
This PPA contains tested (stable) builds of apt-fast.
More info: https://launchpad.net/~apt-fast/+archive/stable
And that's it. Nothing happens.
I've also tested doing just echo | ppa:some-ppa-to-add and it's the same results.
Can anyone help me figure out how to make this line of code/command work so that the script can be updated for those interested in using it with a new version of their system?
Thank you.
You could use add-apt-repository --yes but you are overriding a system-wide security policy by answering that question.
You don't say who the user is; I would be annoyed if your script did that for me, but I'm not a typical end-user. I just looked at your script, and it is conversational enough generally. If it said something like
I'm going to add these packages from reasonably trustworthy sources and set them up so they will automatically update, etc., etc.
it would be more polite.
Added
There is an undocumented feature in add-apt-repository which allows you to override the question programmatically:
if (sys.stdin.isatty() and
not "FORCE_ADD_APT_REPOSITORY" in os.environ):
if options.remove:
print(_("Press [ENTER] to continue or ctrl-c to cancel removing it"))
else:
print(_("Press [ENTER] to continue or ctrl-c to cancel adding it"))
sys.stdin.readline()
Thus the bash sequence
export FORCE_ADD_APT_REPOSITORY=force
sudo add-apt-repository ppa:webupd8team/sublime-text-2
sudo add-apt-repository ...
should stop the questions. It will still show the noise
You are about to add the following PPA to your system:
Sublime Text 2 packages - the .deb will automatically download the
latest build from http://www.sublimetext.com/dev or beta from
http://www.sublimetext.com/2 (Adobe Flash Player installer - style).
More info and feedback:
http://www.webupd8.org/2011/03/sublime-text-2-ubuntu-ppa.html
http://www.webupd8.org/2012/03/sublime-text-2-ppa-separate-development.html
More info: https://launchpad.net/~webupd8team/+archive/sublime-text-2
but that is put on stdout so should be able to be sent to > /dev/null with errors still appearing on stderr.

SCP error: Bad configuration option: PermitLocalCommand

When I execute this command below:
scp -P 36000 hdfs#192.168.0.114:~/tmp.txt SOQ_log.txt
I get an error:
command-line: line 0: Bad configuration option: PermitLocalCommand
Does anyone know why?
scp runs a copy of the ssh program to create the communications channel, and it runs ssh with the options:
-oForwardAgent=no -oPermitLocalCommand=no -oClearAllForwardings=yes
So that explains where the "PermitLocalCommand" option is coming from in the first place. I'll add that sftp uses the same options to run ssh, so it'll probably display the same behavior.
"PermitLocalCommand" is normally a valid ssh configuration option. If your copy of ssh is complaining about it, then it seems that your copy of ssh isn't the normal copy of ssh that goes with your copy of scp.
This serverfault question suggests that the error could be due to someone installing a malware version of ssh (ie, a rootkit) on your system. This forum thread also suggests that the problem is due to having an altered version of ssh, which was fixed by removing and reinstalling the OpenSSH client utilities.
An alternate explanation would be that someone--maybe your Linux distro maintainer--has installed a version of ssh on your system with that option removed, and you're using it unawares. Or you have a very old version of the ssh program for some reason, which doesn't support the option.
My system is CentOs 5.9
I'm facing the same problem, I found it to be due to this configuration line in /etc/ssh/sshd_config:
# override default of no subsystems
Subsystem sftp /opt/libexec/sftp-server
But I cannot run /opt/libexec/sftp-server, it is broken for some reason
now it is solved by reinstall the remote openssh-server:
yum erase openssh-server
yum install openssh-server
now the changes to
# override default of no subsystems
Subsystem sftp /usr/libexec/openssh/sftp-server
and /usr/libexec/openssh/sftp-server is runnable
don't forget to execute:
/etc/init.d/sshd restart
Sometimes command cannot parse this kind of stuff
:~/
Id change it to the full path.

Resources