Frühere Suchanfragen

Keine früheren Suchanfragen

Suchoptionen

Nur verfügbar, wenn angemeldet.
mastodontech.de ist einer von vielen unabhängigen Mastodon-Servern, mit dem du dich im Fediverse beteiligen kannst.
Offen für alle (über 16) und bereitgestellt von Markus'Blog

Verwaltet von:

Serverstatistik:

1,4 Tsd.
aktive Profile

mastodontech.de: ÜberStatusProfilverzeichnisDatenschutzerklärung

Mastodon: ÜberApp herunterladenTastenkombinationenQuellcode anzeigenv4.4.8

#openssh

3 Beiträge3 Beteiligte0 Beiträge heute
Fortgeführter Thread
Marcus Adams

That said, since modern versions of #OpenSSH have adopted a post-quantum key exchange by default and #Wireguard isn't, by default at least, totally quantum safe, I wonder if it would be better to use SSH with password login disabled as a VPN instead of Wireguard. You can use the optional PSK option with Wireguard to attain some level of PQ security, but it's not 100% because of the default handshake.

Just thinking out loud.

*
John Shaft

Forgot to check #OpenSSH 10.1's changelog It was released a few weeks ago and has some interesting features #PQ

* ssh(1): add a warning when the connection negotiates a non-post quantum key agreement algorithm.

This warning has been added due to the risk of "store now, decrypt later" attacks. More details at openssh.com/pq.html

This warning may be controlled via a new WarnWeakCrypto ssh_config option, defaulting to on. This option is likely to control additional weak crypto warnings in the future.

openssh.comOpenSSH: Post-Quantum CryptographyOpenSSH post quantum cryptography
Rainer "friendica" Sokoll
#openssh #mikrotik #routeros
❯ ssh router
** WARNING: connection is not using a post-quantum key exchange algorithm.
** This session may be vulnerable to "store now, decrypt later" attacks.
** The server may need to be upgraded. See https://openssh.com/pq.html



  MMM      MMM       KKK                          TTTTTTTTTTT      KKK
  MMMM    MMMM       KKK                          TTTTTTTTTTT      KKK
  MMM MMMM MMM  III  KKK  KKK  RRRRRR     OOOOOO      TTT     III  KKK  KKK
  MMM  MM  MMM  III  KKKKK     RRR  RRR  OOO  OOO     TTT     III  KKKKK
  MMM      MMM  III  KKK KKK   RRRRRR    OOO  OOO     TTT     III  KKK KKK
  MMM      MMM  III  KKK  KKK  RRR  RRR   OOOOOO      TTT     III  KKK  KKK

  MikroTik RouterOS 7.19.6 (c) 1999-2025       https://www.mikrotik.com/


Press F1 for help


[root@homerouter] >

You can work around that like so:
❯ grep -A4 '^Host router' .ssh/config
Host router
    HostName 192.168.1.254
    User root
    KexAlgorithms +curve25519-sha256,curve25519-sha256@libssh.org
    IdentityFile ~/.ssh/router_rsa

But of course, that's only a temp solution, because THEY are after you!
*
ティージェーグレェ
I submitted a Pull Request to update MacPorts' OpenSSH to 10.1p1 here:

https://github.com/macports/macports-ports/pull/28592

GitHub Continuous Integration checks passed OK!

Alas, the agent.patch that iamGavinJ had created, doesn't apply cleanly, in large part because ssh-agent.c has been reworked significantly with this release.

Subsequently, I closed this previous Pull Request: https://github.com/macports/macports-ports/pull/28592 not because I didn't want to restore that functionality to launchd, but because it will require more effort than I can give such things at this time.

But, check out these improvements to ssh-agent from the OpenSSH 10.1 release notes:

"ssh-agent(1)](https://man.openbsd.org/ssh-agent.1), sshd(8): move agent listener sockets from /tmp to
under ~/.ssh/agent for both ssh-agent(1) and forwarded sockets
in sshd(8).

This ensures processes that have restricted filesystem access
that includes /tmp do not ambiently have the ability to use keys
in an agent.

Moving the default directory has the consequence that the OS will
no longer clean up stale agent sockets, so ssh-agent now gains
this ability.

To support $HOME on NFS, the socket path includes a truncated
hash of the hostname. ssh-agent will, by default, only clean up
sockets from the same hostname.

ssh-agent(1) gains some new flags: -U suppresses the automatic
cleanup of stale sockets when it starts. -u forces a cleanup
without keeping a running agent, -uu forces a cleanup that ignores
the hostname. -T makes ssh-agent put the socket back in /tmp."

Anyway, I updated this as well:

https://trac.macports.org/ticket/72482

I should probably actually close this ticket now that I think of it (fingers crossed that adding that to the PR is sufficient, since I forgot to add that note to the commit message as is typically preferred: https://trac.macports.org/ticket/73084).

#OpenSSH #MacPorts #SecureShell #macOS #encryption #security #infosec
GitHubopenssh: restore launchd -l functionality via iamGavinJ by artkiver · Pull Request #28592 · macports/macports-portsVon artkiver
mirabilos

Anyone got an idea how to do this:

  • expose a user on a GNU/Linux system via ssh
  • allow two keys access
    • one is the “self” key, which should be allowed as-is
    • the other is the “external” key, which triggers a password prompt
  • otherwise, password login is not permitted

I know how to do most things of this, but not all at once (AuthenticationMethods is permitted in a Match block, but we cannot match on keys, we want access to the same user, and the “self” key can also be used (agent forwarding) from nōn-local addresses.

It seems like I’ll need a custom PAM module (arrrgh, I don’t want to write one of these) that asks for the password if key B is used (does SSH expose this to PAM?).

Anyone got a better idea?

#ssh#openssh#sshkeys
Tykayn

j'ai reçu des mails de gens qui font des audits "c'est cadeau ça me fait plaiz" de mes serveurs pour me dire qu'on peut trouver des infos sur la version de telle ou telle lib, que je devrais changer ma config ssh... de la part de gens chez gmail.

blague à part, il me semblait que pour les configs ssh les paquets debian / ubuntu étaient géré d'une façon suffisamment saine pour qu'on ait pas besoin de faire de config spéciale pour que ça reste aux meilleures normes. ceussent qui sachent, si vous voulez donner un avis c'est bienvenu.

#cybersec#ssh#openssh
AngesagtLive-Feeds
Über