What ssh key do I have?

Would it be a SSH-1 key or a SSH-2 key? Is there a way to tell?

Version 1 or version 2 refers to the ssh protocol version. Keys generated by ssh-keygen work with either. This refers to how the ssh client and server exchange key information…there's no such concept as key version.

Would an ed25519 key be better?

Only if you don't want it to work with other systems (e.g. github.com or M$ Azure VMs). RSA is perfectly fine. Maybe 2-5 years from now, that won't be the case but for now RSA is pretty universal. RSA is getting pretty long in the tooth but it hasn't been cracked yet.

Does Ubuntu 20.x recognize it for SSH?

This is not a function of your distro/version. It's a function of your ssh client and server configuration. The answer to your specific question is yes…see

https://linux-audit.com/using-ed25519-openssh-keys-instead-of-dsa-rsa-ecdsa/

There's very little (if any) advantage to be gained by using ed25519 over RSA. You'd just be making your life harder…

-- sw

Thanks for the good info. The reason I ask is that on my old iMac I generated rsa keys back in 2012. They have always worked fine and still work to SFTP via Transmit app to Linode Ubuntu 20.x. But they won't work with Transmit on SFTP to my Pair server anymore. (They used to work.) I get authentication failure. (However, SSH to Pair via command line works with the keys.) With the SFTP Transmit app I can log in via password but not the keys.

The Pair people think that I should re-gen the keys as they will be a RSA-2 and that might solve the issue.

Well, if I do that I have to replace the id_rsa.pub on both Linode servers and Pair. I can do that, just was hoping I would not have to. If I create a new key on my iMac I believe it will over-write the old one. I guess I could give it a different name and pop it in ./ssh folder… or figure out how to use a .config file?

To be honest, I may as well keep what I have and just use the password from home to Pair. :-)

Thanks for the help… per usual.

-Al

The Pair people think that I should re-gen the keys as they will be a RSA-2 and that might solve the issue.

There's no such thing as RSA-2… There's RSA with different key lengths:

-b bits
             Specifies the number of bits in the key to create.  For RSA keys,
             the minimum size is 1024 bits and the default is 3072 bits.
             Generally, 3072 bits is considered sufficient.  DSA keys must be
             exactly 1024 bits as specified by FIPS 186-2.  For ECDSA keys, the
             -b flag determines the key length by selecting from one of three
             elliptic curve sizes: 256, 384 or 521 bits.  Attempting to use bit
             lengths other than these three values for ECDSA keys will fail.
             ECDSA-SK, Ed25519 and Ed25519-SK keys have a fixed length and the
             -b flag will be ignored.

On my MacBook Air, the man page for ssh-keygen has the following description for the -t flag:

-t dsa | ecdsa | ecdsa-sk | ed25519 | ed25519-sk | rsa
      Specifies the type of key to create.  The possible values are
      “dsa”, “ecdsa”, “ecdsa-sk”, “ed25519”, “ed25519-sk”, or “rsa”.

This flag may also be used to specify the desired signature type
      when signing certificates using an RSA CA key.  The available RSA
      signature variants are “ssh-rsa” (SHA1 signatures, not
      recommended), “rsa-sha2-256”, and “rsa-sha2-512” (the default).

You might try one of the variants and/or different key lengths…

This is macOS 12.0.1 (Monterey) with

stevewi:~ $ ssh -V
OpenSSH_8.6p1, LibreSSL 2.8.3

If I create a new key on my iMac I believe it will over-write the old one.

You can tell ssh-keygen the name/location of the file you want to use. Look at the man page. It just defaults to id_rsa.*.

-- sw

or figure out how to use a .config file?

They’re pretty simple. I’ve not had to use one on my Mac yet, but I have on Windows before.

Create a ~/.ssh/config file with the contents:

Host your.server.ip.or.hostname
   IdentityFile /path/to/your/private.key

Just make sure the Host entry matches the hostname you use to connect via SSH. E.g. if you connect using ssh dns.host.name, then putting the server’s IP address won’t work (I don’t believe any name resolution takes place to match against a Host entry in the .config file.)

To be honest, I may as well keep what I have and just use the password from home to Pair.

If you have a working key, I’d strongly suggest using it. Then disable password authentication in SSH to improve security (no dictionary or brute force attacks will be possible.)

I created a new key-pair on my iMac (Big Sur) via:

ssh-keygen -t rsa

I don't know if it is SHA-1 or SHA-2.

I copied it to the authorized_keys file of my two Linode servers and my Pair server.

It works fine with Linodes. It does not work with Pair. It fails with SFTP (Transmit) but works fine with SSH on the command line (ssh me@pairserver-address.com)

The only thing I can think of is that the /etc/ssh/sshd_config file in Pair has:

#UsePAM no

while Linode has it has:

UsePAM yes.

Both the Transmit and the Pair people are looking into all of this for me. My guess is the Pair server in configured for PW only, but the sshd_config file shows:

#PasswordAuthentication yes .

What a puzzlement.

I created a new key-pair on my iMac (Big Sur) via:
 
ssh-keygen -t rsa
 
I don't know if it is SHA-1 or SHA-2.

The man page for ssh-keygen says that rsa-sha2-512 is the default, so I would assume that:

ssh-keygen -t rsa

is the same as

ssh-keygen -t rsa-sha2-512

This is a pretty good explanation of public/private key pairs (for both ssh and TLS):

https://www.thedigitalcatonline.com/blog/2018/04/25/rsa-keys/

The only thing I can think of is that the /etc/ssh/sshd_config file in Pair has:
 
#UsePAM no

while Linode has it has:
 
UsePAM yes

These are actually both the same. UsePAM yes is the default.

It fails with SFTP (Transmit) but works fine with SSH on the command line (ssh me@pairserver-address.com)

Is Transmit some sort of app? Does it work with

sftp sftp://me@pairserver-address.com/

on the command line (see man sftp)? I use a text editor (BBEdit) that does this internally for editing remote files but I'm not well-versed in sftp. I usually use scp…

-- sw

I heard back from the PairNetworks people. They tried to log into their server with the Transmit SFTP app (https://panic.com/transmit/ --- which is the 'gold standard' for getting into remote servers in the Mac world… it handles just about every protocol out there… Amazon S3, Box, WebDav, M$OneDrive, GoogleDrive etc.) and they could not do it either with RSA keys.

They told me to generate an ed25519 key, put it into the auth-keys file… and try it since it worked for them with Transmit.

I genereated the keys, sent them to the server auth-keys file… and it worked. (Yay!)

I've read that ed25519 is more secure than RSA and also somewhat faster… so I set up my Linodes to use it as well with Transmit.

Problem solved. Thanks, Steve.

I've read that ed25519 is more secure than RSA and also somewhat faster… so I set up my Linodes to use it as well with Transmit.

Here's a pretty detailed treatise on ed22519 vs RSA security:

https://security.stackexchange.com/questions/90077/ssh-key-ed25519-vs-rsa

You should make sure it works with command-line stuff too…ssh, scp, sftp etc.

I'll prob switch everything to RSA w/4096-bit key length after the first of the year and then to ED22519 maybe mid-year 2022. It's not hard…just tedious…

Just FYI, it appears Lets Encrypt doesn't have any plans to support ED22519 certificates for the foreseeable future. I'll keep an eye on this issue. As long as RSA hasn't been cracked, it should be fine.

Problem solved. Thanks, Steve.

You're welcome…

-- sw

You should make sure it works with command-line stuff too…ssh, scp, sftp etc.

Yes, I did that since I use all of those commands as well as rsync. By putting a "-v" option in each command and run at the prompt you get a ton of debugging stuff in the terminal and if you wade through it you can see which key was used/accepted.

As I understand it there is no way to change the default of the "ssh" command using the RSA key. So you have to use the "i" option:

ssh -i/home/anc1/.ssh/id_ed25519 abc@xyz.net touch zzz-test-6.txt

If you don't want to use the "-i" option for a path to the key, you need to make and use the /.ssh/config file which is pretty easy.

I had a ton of scripts that had in them:

ssh abc@xyz.com [some command]

I didn't want to go change each one so I used the wildcard * making the "Host" in config as: *xyz.com:

Host *xyz.com
HostName xyz.com
user abc
IdentityFile /home/yyy/.ssh/id_ed25519
IdentitiesOnly yes

( You cannot have Host abc@xyz.com. I think the @ sign screws things up… thus the use of the wildcard.)

Doing this saved me an hour of work, maybe two… searching all my scripts for the rsync, ssh and scp commands used to do functions on remote servers I own by putting in the the '-i' option … or changing them all to a "host" name… like

ssh server1 [some command] .

Thanks again.

One last thing…

If you run a shell script as root and you try to send a file or 'touch' a file to another server, root does not know any of your keys… not the ed25519 or the RSA, etc. It is 'keyless" and your job will fail.

The reason is because root does not usually have its own keys or a config file in its /root/.ssh/ directory.

You can make put keys in there or make a config file if you want but there is a better way.

You can put the host connection info into a (global) file called /etc/ssh/ssh_config. The ssh program reads its keys from the following files in this order (from [https://man7.org/linux/man-pages/man5/ssh_config.5.html]):

ssh(1) obtains configuration data from the following sources in the
following order:
1. command-line options
2. user's configuration file (~/.ssh/config)
3. system-wide configuration file (/etc/ssh/ssh_config)

Since root does not see a command-line and does not have a /.ssh/config, it will get what it needs from what you put in the /etc/ssh/ssh_config file.

(I hate having to run a job as root, but some functions such as truncating log files which are owned by root require running as root. I don't know if the logs have to be owned by root, but setting up a virtual host using Linode's instructions, that's what you get!)

Hope this helps someone.(I wish I had known all of this before I upgraded to the ed25519 key)

…but some functions such as truncating log files which are owned by root require running as root….

Why don't you just use logrotate for this? There's nothing that says a log file has to live in /var/log for logrotate to be able to rotate it automagically. Your log file can live anywhere in the filesystem. logrotate runs as the super-user. See:

https://linuxconfig.org/logrotate

A logrotate spec can run programs before and after a rotation. Why re-invent the wheel…and have to maintain it?

-- sw

Why don't you just use logrotate for this?

Simple. I can write bash code/scripts to do stuff I want to do usually in far less time than it takes to figure out a Linux utility with ten-zillion options. I looked at logrotate and decided that I could do what I wanted to do in 3 lines of code… that is to just keep a rolling 3 log files for each domain.

The way Pair does their www logs is to lump them all into one folder (www-logs) with no rotate or compression, etc…. just a date :

my.domain-one-110121.log
my doamin-one-110221.lon
my domain-one-110321.log
.
.
.
my.domain-two-110121.log
my doamin-two-110221.lon
my domain-two-110321.log
.
.
.
another seven domains.

So the folder would grow and grow.

All I want is the last 3 days of error logs for each domain. Doing this in logrotate would mean I'd have to write a long logrotate.conf file… AFTER I figured out how to do it!

All I need is two lines of code in a script run each night:

export TZ=America/Los_Angeles
find /usr/home/me/www_logs -maxdepth 1 -type f -mtime +2 | xargs rm -f

Here is the rest of the story if interested.

(The tiny shared server on Pair.com is only used to send and get email. I don't have root access. Their are no actual working domains on it… all web traffic goes to Linode… and mail to Pair via DNS records, but there are domains with space allocated on Pair and an IP address assigned (although most are shared IPs) so I can get mail. I get a bunch of 'hits' by hackers just hitting every IP address they can find… and Pair's block is no secret.

Actually Pair gives you a setting buried deep in their control panel to set the number of days to keep logs… but I prefer to have control of what happens on the server and not leave it up to the Pair system.)

Consider the following:

/the/path/to/my.domain-one*log 
/the/path/to/my.domain-two*log
...
{
   rotate 3                  # keep 3 logs
   daily                     # rotate daily
   compress                  # days 2 & 3 past current will be compressed
   delaycompress             # day 1 past current will not be compressed
}

Finish it (replace the … with the rest of your log file wildcards); save the file in /etc/logrotate.d and the job will be done. How many cron jobs will that eliminate (at least one; could be 7)?

-- sw

My two lines of code go in one .sh bash script that is run nightly via Cron.

This explains it:

# Since the server is in Denver I want the actual time for the 'find' command to use PST and not MST.
#
export TZ=America/Los_Angeles

#

# The find command goes through the entire www-logs folder and looks for any file that is older than 2 days from today and deletes it via the 'pipe' to the 'rm' command
#
find /usr/home/me/www_logs -maxdepth 1 -type f -mtime +2 | xargs rm -f

I don't see how the logrotate utility improves on this as these log files are very small (usually less than 2K each) and not worth the 'overhead' of compressing and the hassle of uncompressing if I want to look at a current or previous log… which I very rarely do.

If it doesn't meet your needs that's fine… However, that's different from

Doing this in logrotate would mean I'd have to write a long logrotate.conf file… AFTER I figured out how to do it!

I use your method too. Given that the names of the log files use the date in them (hint to subsystem developers: don't do this!), logrotate may not be suitable (although, IMHO, it would fairly straightforward to overcome this…but, as you point out, at what cost?).

My only point here is that, if there's a system facility available to do what you want (or can be easily-configured to do what you want), it's advisable to try and use it to your advantage. You don't have to test and maintain the system facility…the Gods of Linux™ do that. New tricks are always good things to learn…

not worth the 'overhead' of compressing and the hassle of uncompressing if I want to look at a current or previous log

logrotate does not require you to use compression. Leave out compress and delaycompress in the example I posted above.

For example, my DMARC milter produces a log. That log contains the particulars of the DMARC analysis of incoming mail. The DMARC standard says that I'm supposed to notify senders of that stuff according to a spec provided in their DMARC records. It's very convenient for me to have logrotate run the program that does all that on the just-rotated log file. It's always done at the right time with the right data and I don't have to remember if there's a cron job for it (which is never going to be synchronous with log rollover).

I do all this in a logrotate postrotate clause:

#
#   1.  Import the log file just rotated into the DMARC database
#
/srv/dmarc/bin/dmarc import /var/log/opendmarc/opendmarc.log.0 

#   2.  Generate/deliver rua aggregate reports appropriately
#
/srv/dmarc/bin/dmarc report --age 30

#   3.  Expire old data appropriately (the default is 90 days)
#
/srv/dmarc/bin/dmarc expire

The logs are not compressed and rotated weekly. These log files are about 75K when they get rotated and I keep them for a month. If something screws up, I get notified and I can run this series of steps manually on the (now-rotated but uncompressed) log file.

/srv/dmarc/bin/dmarc is my program. It's the only thing I have to maintain. Eventually, the processed log files get rotated into oblivion. I don't have to worry about throwing them away (let alone throwing them away at the right time and/or throwing away the right ones).

-- sw

Thanks for letting me know about logrotate. It is a utility that I was not experienced with… and may have use for in the future.

This was a valuable discussion.

I'll end by saying that if anyone needs some short, tight, minimalist backup scripts for backing up web directories or MySQL databases, or deleting old log files, or truncating large log files… you can contact me here.

-Al