In gitlab's documentation on how to generate ssh key: they suggest to use the -o argument. However, this argument does not seem to appear in the manual of ssh-keygen. No error is thrown so it is acceptable. I am wondering what does it do?
The ssh-keygen "-o" option currently does nothing. It's accepted by ssh-keygen for compatibility, but ignored.
It used to cause ssh-keygen to save the key in a different key format, but that key format is now the default behavior.
It looks like this change was made for OpenSSH 7.8 in 2018. It's not unreasonable in 2021 for someone to be following github's instructions using an older version of ssh-keygen in which the option does something useful.
Related
I use ssh-key based authentication, with the keys being held on a smartcard. I am migrating to a new machine, where in my previous machine I had Emacs+Tramp set up nicely with the workflow.
However, now I am having issues. I found a solution, however I am wondering if there is a better way.
The setup
If I have an .ssh/config with the following entry:
Host remote
HostName 1.2.3.4
User root
remote has my SSH keys authorised, and if I run ssh remote in a normal shell, I am prompted for my smartcard pin, and can SSH with no issues.
However, in Emacs using tramp, I would normally ssh entering the filepath to ssh:remote:. However, in my fresh installation it instead prompts me for a username, and then a password.
First attempts
Following the suggestion of this answer, I increased the log level of tramp.
It showed me that tramp was running the following command: exec ssh -o ControlMaster=auto -o ControlPath='tramp.%C' -o ControlPersist=no -e none remote. Running this in a normal shell worked as expected.
I found that running ssh remote in eshell had the same problem.
I thought that maybe Emacs didn't have access to my ~/.bashrc config, where I configure my smartcard details:
export GPG_TTY="$(tty)"
export SSH_AUTH_SOCK=$(gpgconf --list-dirs agent-ssh-socket)
gpgconf --launch gpg-agent
The solution (is there a better one?)
This answer suggested launching Emacs with bash -c emacs.
This ended up solving the problem, however I wonder if there is a more robust solution, i.e. one encoded in my config.el file, or similar.
As you can see, the problem is caused by inconsistencies between the Emacs and shell environment variables. You can use exec-path-from-shell, especially if you are using macOS. Or you can just setenv manually. Finally, Spacemacs and Doom have their own way of handling it, I see you mention config.el, not sure if you are using Doom, you can refer to them as well.
I need to authenticate rundeck with any of the following:
curve25519-sha256#libssh.org,diffie-hellman-group18-sha512,curve25519-sha256,diffie-hellman-group14-sha256,diffie-hellman-group16-sha512
But it seems only the following options are available:
ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
Is there a possible way to do that with the opensource version?
From rundeck/rundeck issue 4349, apparently not.
An "OpenSSH Node Execution Plugins" might be useful as a workaround.
The other workaround being:
Use the script exec/copy instead of jsch:
service.FileCopier.default.provider=script-copy
service.NodeExecutor.default.provider=script-exec
plugin.script-copy.default.command=scp ${file-copy.file} >${node.username}#${node.hostname}\:${file-copy.destination}
plugin.script-copy.default.remote-filepath=${node.destdir}/${file-copy.filename}
plugin.script-exec.default.command=ssh -o "StrictHostKeyChecking no" >${node.username}#${node.hostname} ${exec.command}
plugin.script-exec.default.shell=bash -c
I have a script that uses SCP to pull a file from a remote Linux host on AWS. After running the same code nightly for about 6 months without issue, it started failing today with protocol error: filename does not match request. I reproduced the issue on some simpler filenames below:
$ scp -i $IDENT $HOST_AND_DIR/"foobar" .
# the file is copied successfully
$ scp -i $IDENT $HOST_AND_DIR/"'foobar'" .
protocol error: filename does not match request
# used to work, i swear...
$ scp -i $IDENT $HOST_AND_DIR/"'foobarbaz'" .
scp: /home/user_redacted/foobarbaz: No such file or directory
# less surprising...
The reason for my single quotes was that I was grabbing a file with spaces in the name originally. To deal with the spaces, I had done $HOST_AND_DIR/"'foo bar'" for many months, but starting today, it would only accept $HOST_AND_DIR/"foo\ bar". So, my issue is fixed, but I'm still curious about what's going on.
I Googled the error message, but I don't see any real mentions of it, which surprises me.
Both hosts involved have OpenSSL 1.0.2g in the output of ssh -v localhost, and bash --version says GNU bash, version 4.3.48(1)-release (x86_64-pc-linux-gnu)
Any ideas?
I ended up having a look through the source code and found the commit where this error is thrown:
GitHub Commit
remote->local directory copies satisfy the wildcard specified by the
user.
This checking provides some protection against a malicious server
sending unexpected filenames, but it comes at a risk of rejecting
wanted files due to differences between client and server wildcard
expansion rules.
For this reason, this also adds a new -T flag to disable the check.
They have added a new flag -T that will ignore this new check they've added so it is backwards compatible. However, I suppose we should look and find out why the filenames we're using are flagged as restricted.
In my case, I had [] characters in the filename that needed to be escaped using one of the options listed here. for example:
scp USERNAME#IP_ADDR:"/tmp/foo\[bar\].txt" /tmp
I know SSHv1 is super insecure, however I need to set it up on a server for some testing. Trying to find an older version of openSSH was a hard task in itself, but now trying to set it up is impossible.
I'm trying to use openSSH 2.1.1 and openSSL 1.0.1.
From what I can tell, openSSL installs fine, however I run in to issues with openSSH
My configure (./configure --prefix=/usr --sysconfdir=/etc) works fine, however I run in to issues when I try to make
The error I'm getting is: authfd.c:354:41: error: dereferencing pointer to incomplete type ‘RSA {aka struct rsa_st}’ buffer_put_int(&buffer, BN_num_bits(key->n));
I've tried looking around, and have even started looking in some of the openSSL files, I think everything is coded correctly.
My guess is that these errors have something to do with trying to compile old versions of ssl and ssh with an up to date version of gcc
Has anyone managed to set up a server to use SSHv1, or at least have any ideas on how to solve this dereferencing error?
From the error you see it looks like you are using OpenSSL 1.1.0, which made RSA structures opaque and is therefore it is not compatible. Things to resolve:
Download older OpenSSL (1.0.2 should do that) and build this one
Configure with --with-ssh1 switch to enable SSH1 support
I am having a cert8.db in /home/hari/Desktop/certs directory. Now I want to convert this into PEM. tried to do this by first trying to export the cert8.db in pkcs12 to pem using pkutil
pk12util -o cert.pem -n cert8.db -d /home/hari/Desktop/certs
However this throws an error
pk12util: function failed: security library: bad database.
I have no idea what's going wrong here. Please help me out with it. Also any suggestions on alternative ways of doing this would also be greatly appreciated. Thanks a lot in advance.
You probably have figured it out by now, that the file belongs to Mozilla Firefox 4.x - security database. On Windows 7 Pro this is stored on the system root for some odd reason, that causes my security software to go nuts...
Then again, you might not have Firefox installed in your env.