Feb 06, 2023

2837

SSH Key Exchange Ubuntu Server and Client

Hallo Commnity,

ich habe heute festgestellt, dass ich beim SSH login auf meinen Ubuntu Server 22.04. trotz der Einrichtung von ssh-keys aufeinmal eine zusätzliche Passwortabfrage für meinen User erfolgt. Diese Abfrage hatte ich vorher nicht. Ich kann mich auch an keine Änderungen erinnern, die dies verursachen könnte.

Ich habe den ssh key meines clients auf dem server gelöscht (authorized_keys) und wieder kopiert (ssh-copy), allerdings ohne erfolg. Merkwürdiger Weise kann ich die Abfrage mit strg+x abrechen und lande deenoch normal auf meinen system. die sshd_config sieht unverändert aus -> keine Änderungen gemacht die die Abfrage zur Folge haben könnten.

Habt ihr eine Idee?

Please also mark the comments that contributed to the solution of the article

Content-ID: 5882163175

Url: https://administrator.de/contentid/5882163175

Printed on: September 18, 2024 at 20:09 o'clock

29 Comments

Latest comment

Moin,

was zeigt er denn im Verbose-Mode an?

ssh -v <user>@<server>

Merkwürdiger Weise kann ich die Abfrage mit strg+x abrechen und lande dennoch normal auf meinen system.

Es handelt sich aber um eine Passwortabfrage des Servers; und nicht um die Passphrase-Abfrage des Private-Keys?
Falls es doch die Passphrase-Abfrage ist, hast du womöglich 2 PrivateKeys (einen mit Passphrase und einen ohne).

Wenn du RSA-Login nutzt, warum dann nicht Passwortlogin generell abschalten?

PubkeyAuthentication yes
PasswordAuthentication no

Gruß Thomas

https://www.heise.de/select/ct/2022/21/2223709091059562015
Lesen und verstehen...

Wenn es das denn nun war bitte deinen Thread hier dann auch als erledigt schliessen!

Leider noch nciht, hatte nur keine Zeit mich weiter zu kümmern. Aktuell geht leider kein SSH Zugriff mehr. Per Cockpit komme ich per web gui an meinen server

Ich sehe aktuell folgendes:

ssh -v username@xxx.xxx.xxx.xxx

OpenSSH_8.9p1 Ubuntu-3ubuntu0.1, OpenSSL 3.0.2 15 Mar 2022
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: include /etc/ssh/ssh_config.d/*.conf matched no files
debug1: /etc/ssh/ssh_config line 21: Applying options for *
debug1: Connecting to xxx.xxx.xxx.xxx [xxx.xxxx.xxx.xxx] port 22.
debug1: Connection established.
debug1: identity file /home/username/.ssh/id_rsa type 0
debug1: identity file /home/username/.ssh/id_rsa-cert type -1
debug1: identity file /home/username/.ssh/id_ecdsa type -1
debug1: identity file /home/username/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/username/.ssh/id_ecdsa_sk type -1
debug1: identity file /home/username/.ssh/id_ecdsa_sk-cert type -1
debug1: identity file /home/username/.ssh/id_ed25519 type -1
debug1: identity file /home/username/.ssh/id_ed25519-cert type -1
debug1: identity file /home/username/.ssh/id_ed25519_sk type -1
debug1: identity file /home/username/.ssh/id_ed25519_sk-cert type -1
debug1: identity file /home/username/.ssh/id_xmss type -1
debug1: identity file /home/username/.ssh/id_xmss-cert type -1
debug1: identity file /home/username/.ssh/id_dsa type -1
debug1: identity file /home/username/.ssh/id_dsa-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.9p1 Ubuntu-3ubuntu0.1
debug1: Remote protocol version 2.0, remote software version OpenSSH_8.9p1 Ubuntu-3ubuntu0.1
debug1: compat_banner: match: OpenSSH_8.9p1 Ubuntu-3ubuntu0.1 pat OpenSSH* compat 0x04000000
debug1: Authenticating to xxx.xxxx.xxx.xxx:22 as 'head'  
debug1: load_hostkeys: fopen /home/username/.ssh/known_hosts2: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts2: No such file or directory
debug1: SSH2_MSG_KEXINIT sent
Connection closed by xxx.xxx.xxx.xxx port 22

openssh sever neuinstalliert -> keinen erfolg
sshconfig zurückgesetzt -> keinen erfolg

sudo dpkg-reconfigure openssh-server

Creating SSH2 RSA key; this may take some time ...
xxx
Creating SSH2 ECDSA key; this may take some time ...
xxx
Creating SSH2 ED25519 key; this may take some time ...
xxxx
rescue-ssh.target is a disabled or a static unit not running, not starting it.
ssh.socket is a disabled or a static unit not running, not starting it.

ich habe irgendwas mit den ssh keys auf meinem admin rechner gemacht, dann einfach mal unüberlgt auf dem server etwas gelöscht - dumm ja.... habt ihr eine idee?

Hmmm…..jemand ne Idee?

Wenn man nach dem o.a. Heise Artikel vorgeht klappt das wunderbar...

Wenn man denn ein Abo hat, sonst sieht man lediglich die Einleitung….

Schlüsselpaar generieren: ssh-keygen -t ed25519 \ -f ~/.ssh/netzer.ed25519 \ -C "Schlüssel von netzer"
Schlüssel an Zielsystem senden: ssh-copy-id -i \ ~/.ssh/netzer.ed25519.pub \ netzer@netzersrv.de
Alternativ cat ~/.ssh/netzer.ed25519.pub eingeben (Public Schlüssel!!!) und den Output auf dem Server im User Homeverzeichnis unter .ssh in authorized_keys eintragen.
Wenn du dich neu einloggst wirst du nur nach der Passphrase des Keys gefragt
Jetzt Passwortabfrage im SSH Setup /etc/ssh/sshd_ config deaktivieren. PasswordAuthentication auf no und auch ChallengeRes ponseAuthentication auf no.
SSH Daemon neu starten: systemctl restart ssh
Wenn du es bequem haben willst legst du im Client unter ~/.ssh/ die Datei config an und gibst dort ein:
Host netzer-server HostName netzersrv.de User netzer IdentityFile ~/.ssh/netzer.ed25519
Dann reicht ein simples ssh netzer-server. Fertisch...

Hi aqui, danke für die Eklörung. Habe das alles mal ausgeführt. Ich bekomme aber leider weiterhin dieselbe Fehlermeldung:

Connection closed by [IP] port 22

Die lange Version sieht in etwas genauso aus wie oben.

Was ich gesehen habe. Der neue Key wurde wohl mit dem ssh-copy-id auf den Server kopiert, aber auch kam promt: connection closed.

Hatte vorher ssh client und server mal deinstalliert und neuinstalliert

Dann hast du ein größeres Problem...

Hast du mal das Log gecheckt?

da bin ich gerade bei. Anhaltspuntke sind:

sudo /usr/sbin/sshd -ddd

###mit ergebnis:

Missing privilege separation directory: /run/sshd

#Das verzeichnis gibt es nicht

Lösen konte ich durch Anlage auf dem client

....
debug1: load_hostkeys: fopen /home/username/.ssh/known_hosts2: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts2: No such file or directory
...

wobei jetzt die dir da sind, aber ohne hostkeys. Da müsste doch der pub key vom Server rein?

Im Systemlog sehe ich nur start,stop ssh usw. keien Fehlermeldungen bei COnnection. Es scheint ein Serverproblem, da auch von anderen Geräten kein SSH mehr möglich ist.

#Update
Lege ich /run/sshd an und lasse sshd -ddd noch mal laufen und starte ein connect sehe ich folgendes:

....
Connection from [ClientIP] port 52886 on [ServerIP] port 22 rdomain ""  
....
ebug1: Local version string SSH-2.0-OpenSSH_8.9p1 Ubuntu-3ubuntu0.1
debug1: Remote protocol version 2.0, remote software version OpenSSH_8.9p1 Ubuntu-3ubuntu0.1
debug1: compat_banner: match: OpenSSH_8.9p1 Ubuntu-3ubuntu0.1 pat OpenSSH* compat 0x04000000
debug2: fd 3 setting O_NONBLOCK
debug3: ssh_sandbox_init: preparing seccomp filter sandbox
debug2: Network child is on pid 62270
debug3: preauth child monitor started
debug3: privsep user:group 106:65534 [preauth]
debug1: permanently_set_uid: 106/65534 [preauth]
debug3: ssh_sandbox_child: setting PR_SET_NO_NEW_PRIVS [preauth]
debug3: ssh_sandbox_child: attaching seccomp filter program [preauth]
**debug3: append_hostkey_type: ssh-rsa key not permitted by HostkeyAlgorithms [preauth]**
debug1: list_hostkey_types: rsa-sha2-512,rsa-sha2-256,ecdsa-sha2-nistp256,ssh-ed25519 [preauth]
debug3: send packet: type 20 [preauth]
debug1: SSH2_MSG_KEXINIT sent [preauth]
Connection closed by [CLIENTIP] port 52886 [preauth]

Könnte der Teil in bold (also mit den **) etwas sein?

Da müsste doch der pub key vom Server rein?

Die sind aber niemals in /etc/sshd sondern immer im User Verzeichnis /home/userxyz/.ssh
Viel bedenklicher ist "ssh-rsa key not permitted by HostkeyAlgorithms" Bedeutet das dein vom Key verwendeter Hash Algorithmus nicht mit dem des Servers kompatibel ist. Du hast beim Generieren vermutlich etwas anderes verwendet als die vom Server supporteten Optionen rsa-sha2-512, rsa-sha2-256, ecdsa-sha2-nistp256, ssh-ed25519?!

wie ich gelesen habe will ubuntu keinen RSA sondern einen ed25519 key. Auf meinem CLient ist der generiert. Auf meinem Server finde ich nur einen id_rsa? Muss hier neuerdings auch einer hin?

Änderung der /etc/ssh/sshd_config

mit

HostKeyAlgorithms +ssh-rsa
PubkeyAcceptedKeyTypes +ssh-rsa

wie hier beschrieben: https://askubuntu.com/questions/1409105/ubuntu-22-04-ssh-the-rsa-key-isn ... (fals linke erlaubt, wenn nicht sorry.)

Aber bringt auch nichts.

Update:
HostKey /etc/ssh/ssh_host_ed25519_key ist ebenfalls eingetragen, alle anderen mit #

Quote from @aqui:

Da müsste doch der pub key vom Server rein?

wie würdest du vorgehen? Neue Keys auf Client erzeugen? Auf meinem Server habe ich bsiher nie einen erzeugt. Passt vielleicht zu meinem vorherigen post?

Ich habe auf dem client noch mal nach der site und deinem Post einen neues keypair auf meinem client angelegt. leider weiterhin kein erfolg. known host vorher gelöscht - eigentlich müsste doch dann eine Fage zu den nicht known hosts folgen bevor überhaupt was passiert.

Mit ein bisschen weiter lesen habe ich nun wohl erfolgreoch auf ed25519 umstellen können. Jedenfalls taucht die oben genannte Fehlermeldung nicht mehr auf. Leider immer noch Connection closed

Letzte Meldung:

Connection from CientIP port 59850 on ServerIP port 22 rdomain ""  
debug1: Local version string SSH-2.0-OpenSSH_8.9p1 Ubuntu-3ubuntu0.1
debug1: Remote protocol version 2.0, remote software version OpenSSH_8.9p1 Ubuntu-3ubuntu0.1
debug1: compat_banner: match: OpenSSH_8.9p1 Ubuntu-3ubuntu0.1 pat OpenSSH* compat 0x04000000
debug2: fd 3 setting O_NONBLOCK
debug3: ssh_sandbox_init: preparing seccomp filter sandbox
debug2: Network child is on pid 95539
debug3: preauth child monitor started
debug3: privsep user:group 106:65534 [preauth]
debug1: permanently_set_uid: 106/65534 [preauth]
debug3: ssh_sandbox_child: setting PR_SET_NO_NEW_PRIVS [preauth]
debug3: ssh_sandbox_child: attaching seccomp filter program [preauth]
debug1: list_hostkey_types: ssh-ed25519 [preauth]
debug3: send packet: type 20 [preauth]
debug1: SSH2_MSG_KEXINIT sent [preauth]
Connection closed by CLientIP port 59850 [preauth]
debug1: do_cleanup [preauth]
debug1: monitor_read_log: child log fd closed
debug3: mm_request_receive: entering
debug1: do_cleanup
debug1: Killing privsep child 95539
debug1: audit_event: unhandled event 12

gar keine Error mehr? Aber geht nicht.

hmmm....ich sage mal so. Ich habe vieles gelernt, einiges verstanden, einiges nicht. Letzten Endes lag es an irgendwelchen Bloackarden ausgelöst durch Zenarmor auf der OPNsense....najaaa.....wer halt secure shell in zenarmor blockiert....was soll ich sagen

Wahrscheinlich war es auch eine Mischung aus beiden, Fehlermeldungen hat man hassle wohl im Log sehen können.

Nun bin ich wieder am Anfang dieses Themas, da die "sudo password Abfrage" nach dem Login weiterhin erfolgt.

Passwortabfrage im SSH Setup File unter /etc/ssh/sshd_ config hast du deaktiviert? Dort PasswordAuthentication auf "no" und auch ChallengeResponseAuthentication auf "no".
Dann mit systemctl restart sshd den SSH Daemon neu starten.

ja, so weitich das sehe ist alles korrekt. Der reine Login funktioniert ja auch. Erst wenn ich bereits am System angemeldet bin fragt er nach dem sudo kennwort meines users, also für meine Begriffe bereits nach dem eignetlichen "SSH" Prozess - als wenn ein script oder irgendwas starten würde direkt nach dem Login welches das sudo kennwort benötigt.

sshd_config:

# update 20.02.2023
# This is the sshd server system-wide configuration file.  See
# sshd_config(5) for more information.

# This sshd was compiled with PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games

# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented.  Uncommented options override the
# default value.

Include /etc/ssh/sshd_config.d/*.conf

#Port 659
AddressFamily inet
#ListenAddress 0.0.0.0
#ListenAddress ::

#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key

# Ciphers and keying
#RekeyLimit default none

# Logging
#SyslogFacility AUTH
#LogLevel INFO

# Authentication:

#LoginGraceTime 2m
#PermitRootLogin prohibit-password
PermitRootLogin no
#StrictModes yes
MaxAuthTries 4
MaxSessions 3

#PubkeyAuthentication yes

# Expect .ssh/authorized_keys2 to be disregarded by default in future.
#AuthorizedKeysFile	.ssh/authorized_keys .ssh/authorized_keys2

#AuthorizedPrincipalsFile none

#AuthorizedKeysCommand none
#AuthorizedKeysCommandUser nobody

# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
#HostbasedAuthentication no
# Change to yes if you don't trust ~/.ssh/known_hosts for 
# HostbasedAuthentication
#IgnoreUserKnownHosts no
# Don't read the user's ~/.rhosts and ~/.shosts files 
#IgnoreRhosts yes

# To disable tunneled clear text passwords, change to no here!
PasswordAuthentication no
#PermitEmptyPasswords no

# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
KbdInteractiveAuthentication no

# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#KerberosGetAFSToken no

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes
#GSSAPIStrictAcceptorCheck yes
#GSSAPIKeyExchange no

# Set this to 'yes' to enable PAM authentication, account processing, 
# and session processing. If this is enabled, PAM authentication will
# be allowed through the KbdInteractiveAuthentication and
# PasswordAuthentication.  Depending on your PAM configuration,
# PAM authentication via KbdInteractiveAuthentication may bypass
# the setting of "PermitRootLogin without-password". 
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and KbdInteractiveAuthentication to 'no'. 
UsePAM yes

#AllowAgentForwarding yes
#AllowTcpForwarding yes
#GatewayPorts no
X11Forwarding yes
#X11DisplayOffset 10
#X11UseLocalhost yes
#PermitTTY yes
PrintMotd no
#PrintLastLog yes
#TCPKeepAlive yes
#PermitUserEnvironment no
#Compression delayed
# After 10min idle disconnect
#ClientAliveInterval 600 
#ClientAliveCountMax 1
#UseDNS no
#PidFile /run/sshd.pid
#MaxStartups 10:30:100
#PermitTunnel no
#ChrootDirectory none
#VersionAddendum none

# no default banner path
#Banner none

# Allow client to pass locale environment variables
AcceptEnv LANG LC_*

# override default of no subsystems
Subsystem sftp	/usr/lib/openssh/sftp-server

# Example of overriding settings on a per-user basis
#Match User anoncvs
#	X11Forwarding no
#	AllowTcpForwarding no
#	PermitTTY no
#	ForceCommand cvs server

Sudo hat ja per se erstmal gar nichts mit dem SSH Login zu tun. Nach einem klasssichen SSH Login passiert erstmal gar nix. Wenn er nach den sudo Passwort fragt hast du ggf. ein Autostart im Login was das sudo Kommando für den User ausführt. Das hat dann aber mit der eigentlichen Problematik von oben nichts zu tun! Nicht das du hier etwas durcheinander bringst?!
Du kannst das ja einfach testen indem du einmal einen neuen User anlegst und das mit dem durchspielst.

genau, dass ist ja mein Ansatz vom vorherigen Post. Im Grunde könnte ich das Thema hier auch schließen, da SSh Problem nicht besteht bzw. gelöst ist.

Update:
Test mit neuem User brachte genau das Ergebnis, dass beim neuen user keine Abfrage erscheint. Also irgendwas muss da triggern...wo könnte ich am besten ansetzen? Am einfachsten wäre es wohl alten user löschen und neuen nutzen

wo könnte ich am besten ansetzen?

Mal in der /etc/passwd nachsehen ob bei dem betroffenen User was beim Login gestartet wird.

Zitat von @aqui:

wo könnte ich am besten ansetzen?

Mal in der /etc/passwd nachsehen ob bei dem betroffenen User was beim Login gestartet wird.

oder in der "$HOME/.bashrc".

Gruß Thomas

nach was müsste ich in der passwd suchen? Sagt mir momentan relativ wenig. Erkenne nichts was ich evtl. per script benannt habe oder definitionen etc.

In beiden Datein konnte ich keine Unterschiede feststellen, bis auf das in der .bashrc beim user mit kennwort aliase definiert sind:

#own alias
alias update="sudo apt update && sudo apt upgrade -y"  
alias os_update="cd /mnt/data_1/scripts && sudo ./os_update.sh"  
alias b_log="cat /mnt/data_1/logs/data_backup.txt"  
alias p_log="cat /mnt/data_1/logs/data_prune.txt"  
alias sys_log="sudo nano /var/log/syslog"  
alias con_sta="sudo docker start $(sudo docker ps -aq)"  
alias con_sto="sudo docker stop $(sudo docker ps -aq)"  

keiner davon wird meines Wissens nach allerdings beim Start ausgeführt.
Vor kurzem habe ich das Tool "Cockpit" testweise mal installiert, ich weiß allerdings nicht mehr, ob die Kennwortabfrage schon vorher da war. ABer auch hier eigentlich hat das nichts mit einem Login zu tun.

Zitat von @149680:
In beiden Datein konnte ich keine Unterschiede feststellen

also ruft die /etc/passwd bei dem User /bin/bash auf?

bis auf das in der .bashrc beim user mit userabfrage aliase definiert sind:

für Aliase ist eigentlich die "$HOME/.bash_aliases" gedacht. Sei's drum, daran kann es nicht liegen.

Es gibt noch ein paar andere Dateien, an die ggfs. in Frage kommen: ".bash_profile", ".bash_login" oder ".profile" - alle im Homeverzeichnis. Standardmäßig existiert aber eigentlich nur letztere.
Natürlich musst du ggfs. auch alle Dateien checken die von den Dateien gesourced werden.

Hast du schon mal versucht, die Passwortabfrage mit Strg+C abzubrechen? Falls das geht, ist es wahrscheinlich, dass das Problem irgendwo im Homeverzeichnis liegt.

Gruß Thomas

Unterschiede bei den usern in passwd sehe ich aktuell:

main:x:1001:1001:,,,:/home/main:/bin/bash
head:x:1000:1000:head:/home/head:/bin/bash

habe mal in

head:x:1000:1000:,,,:/home/head:/bin/bash

geändet. Bringt aber nichts, muss ich irgendwas restarten? Ich denke /bin/bash ist der Aufruf den du @TK1987 meinst? head ist der user mit passwort.

ok, dann werd ich mal die bash_aliases nutzen, gut zu wissen!

Im Home sehe ich einige Unterschiede - prüfe ich gerade mal. Die bereits genannten sehe aber alle inhaltilich identisch aus. Beim "head" sind noch enige mehr :

total 88
drwxr-x--- 7 head head  4096 Feb 21 22:30 .
drwxr-xr-x 4 root root  4096 Feb 20 22:51 ..
-rw------- 1 head head 35736 Feb 20 23:30 .bash_history
-rw-r--r-- 1 head head   220 Jan  6  2022 .bash_logout
-rw-r--r-- 1 head head  4156 Feb  6 17:19 .bashrc
drwx------ 2 head head  4096 Jan 19 17:56 .cache
drwx------ 4 head head  4096 Jan 21 22:26 .config
-rw------- 1 head head    20 Feb 20 00:06 .lesshst
drwxrwxr-x 3 head head  4096 Jan 19 19:06 .local
-rw-r--r-- 1 head head   807 Jan  6  2022 .profile
drwxr-xr-x 2 root root  4096 Feb 20 22:59 .ssh
-rw-r--r-- 1 head head     0 Jan 19 17:00 .sudo_as_admin_successful
-rw-rw-r-- 1 head head   163 Jan 19 21:18 .wget-hsts
drwx------ 3 head head  4096 Feb 20 15:25 snap

vs.

total 36
drwxr-x--- 5 main main 4096 Feb 21 22:11 .
drwxr-xr-x 4 root root 4096 Feb 20 22:51 ..
-rw------- 1 main main  183 Feb 20 23:31 .bash_history
-rw-r--r-- 1 main main  220 Feb 20 22:51 .bash_logout
-rw-r--r-- 1 main main 3771 Feb 20 22:51 .bashrc
drwx------ 2 main main 4096 Feb 20 23:11 .cache
drwxrwxr-x 3 main main 4096 Feb 20 23:30 .local
-rw-r--r-- 1 main main  807 Feb 20 22:51 .profile
drwxr-xr-x 2 root root 4096 Feb 20 23:11 .ssh
-rw-r--r-- 1 main main    0 Feb 20 22:54 .sudo_as_admin_successful

Ja, abbrechen kann ich mnit STRG+C.

Kann das evtl. aus der crontag - unbewusst kommen? Dort sind aktuell allerdings nur Jobs mit root neu angelegt und die gelten immer egal welcher user aktiv ist.

Glaube user löschen und den neuen nutzen ist das einfachste. Ich weiß nur noch nciht was das ggf. für komplikationen haben könnte, da mit dem anderen user so gut wie alles installiert wurde usw.

Kommando: stop" :D

Habe gerade mal auf meinem neuen "main" user die .bash_aliases angelegt und die aliase von "head" kopiert. Interessanter weise muss ich nun auch hier das sudo kennwort eingeben - ist die Datei wieder gelöscht -> kein passwort mehr.

Gelöst!!

in der .bash_aliases ist anstelle von " scheinbar nur ' zu verwenden. Passwort ist nun jedenfalls weg :D

Danke für euren ganzen Input!

Zitat von @149680:
Gelöst!!

in der .bash_aliases ist anstelle von " scheinbar nur ' zu verwenden.

Nein, man kann genauso gut double quotes verwenden.
Dein Problem ist: Wenn du $(...) innerhalb von double quotes verwendest, wird alles innerhalb der Klammern bereits ausgeführt. Du musst in dem Fall das Dollar-Zeichen escapen, um dies zu verhindern:

alias con_sta="sudo docker start \$(sudo docker ps -aq)"  
alias con_sto="sudo docker stop \$(sudo docker ps -aq)"  

Gruß Thomas

German solved Question Encryption, Certificates Ubuntu