This is impossible. HTTP protocol is different, because there is a "virtual host" concept and HAProxy can differentiate different hosts using "Host:" header. SSH has nothing like this and so the lxc-host is unable to know the container, you are trying to connect.

But you can use another SSH feature called "SSH gateway". Inside ~/.ssh/authorized_keys there is a command= option. Firts setup key-based ssh from your lxc-host to apple and orange. Then put these lines into lxc's authorized_keys file:

command="ssh -q -t user@apple $SSH_ORIGINAL_COMMAND" ssh-rsa AAAAsomeB3N...== user@client
command="ssh -q -t user@orange $SSH_ORIGINAL_COMMAND" ssh-rsa AAAAanotherB3N...== user@client

Now the lxs host can automatically connect to apple and orange, based on the client key.

See more:

https://serverfault.com/questions/329529/virtual-hosts-for-ssh
http://blog.lick-me.org/2012/06/ssh-gateway-shenanigans/

On termux:

apt install openssh
sshd

copy ssh key to .ssh/autorized_keys

On Host:

adb forward tcp:8022 tcp:8022
ssh localhost -p 8022

Done

Modification a faire pour gerer gpg-agent

dans C:\Program Files\Git\cmd> start-ssh-pageant

ssh-pageant-done
gpgconf --launch gpg-agent

failure

OpenSSH Integration with Pageant

For some users, it may be desirable to tie OpenSSH in to the PuTTY authentication agent (Pageant) using ssh-pageant. This is a drop-in replacement for ssh-agent, which simply builds a connection between OpenSSH and Pageant for key-based authentication. The tool makes it easy to leverage OpenSSH for remote repository access, which tends to be the most reliable choice within the specific context of Git for Windows (Git), without the need to run multiple agents which don't interoperate.

This functionality became available with the release of Git 2.8.2.

Starting ssh-pageant Manually from Git Bash

If you always use Git from within Git Bash, then the most straightforward approach is to have it launch ssh-pageant on your behalf. Simply create/edit your _$HOME/.bashprofile (or $HOME/.profile, if you prefer), and add the following.

# ssh-pageant allows use of the PuTTY authentication agent (Pageant)
SSH_PAGEANT="$(command -v ssh-pageant)"
if [ -x "$SSH_PAGEANT" ]; then
   eval $("$SSH_PAGEANT" -qra "${SSH_AUTH_SOCK:-${TEMP:-/tmp}/.ssh-pageant-$USERNAME}")
fi
unset SSH_PAGEANT

The -qra "${TEMP:-/tmp}/.ssh-pageant" construct is equivalent to the -q -r -a filename options. In this context it means:

• -a filename -- Bind to a specific socket file (creating it if necessary)
• -r -- Allow reuse of an existing socket file (exit without error if an existing ssh-pageant/ssh-agent process is using it)
• -q -- Quiet mode (don't echo the PID, if starting a new ssh-pageant process)

By specifying the socket name (defaulting to $SSH_AUTH_SOCK, if set) along with the reuse option, we ensure that only a single running copy of ssh-pageant (per user) is required. Otherwise a separate incarnation would be launched every time Git Bash is invoked.

Verify ssh-pageant Functionality

Now start a new Git Bash session, or source the profile edited just above, and run the ssh-add -l command. If all is well, and Pageant is running (with one or more keys loaded), you should see something similar to the following.

$ ssh-add -l
4096 SHA256:XjN/glikgdBoBclg4EaN8sJ/ibrxTq7zVydpkUwANzk Heinz Doofenshmirtz (RSA)

Starting ssh-pageant Automatically at Logon

If you use Git from Git CMD, or directly from the Windows command prompt, then you'll probably want to ensure that ssh-pageant is launched automatically at logon time. The start-ssh-pageant.cmd script is provided for this purpose, which resides in the cmd subdirectory of your Git installation.

Setting the Environment

Unlike the Git Bash case above, this scenario requires the SSH_AUTH_SOCK environment variable to be set before running the script... otherwise it will simply exit without performing any action. This is normally configured as a persistent USER variable, with the value specifying the desired socket file path in Unix/MSYS2 format.

NOTE: Since there can only be a single global variable of a given name, this approach may or may not cause conflicts if you have multiple environments which utilize the SSH_AUTH_SOCK setting. Running Git alongside of Cygwin, or MSYS2, for example. One way to address this is to use a fully-qualified Windows path for the socket instead of an environment-specific Unix/MSYS2 path.

Windows 7

Launch the Control Panel, and then select System followed by Advanced system settings. Click on the Environment Variables button, and finally New... in the User variables (not System variables) section. Enter SSH_AUTH_SOCK for Variable name and /tmp/.ssh-pageant-%USERNAME% for Variable value, then click OK.

Now launch a new Git CMD or Windows command prompt (pre-existing sessions won't see the new variable), and enter the command set SSH_AUTH_SOCK. If all went according to plan, you should see something similar to the following.

C:\Users\heinz.doofenshmirtz> set SSH_AUTH_SOCK
SSH_AUTH_SOCK=/tmp/.ssh-pageant-heinz.doofenshmirtz

NOTE: the cross-environment-compatible (git for windows, msys2, and cygwin) equivalent would require a fully qualified windows path like C:\Users\MYUSERNAME\AppData\Local\Temp\.ssh-pageant-MYUSERNAME. The correct value can be determined by running a command like cygpath --windows /tmp/.ssh-pageant-%USERNAME% in a Git Bash window.

Launch ssh-pageant

At this point you should run start-ssh-pageant.cmd manually, in order to verify that the agent starts successfully. Assuming that Git is installed into C:\Program Files\Git, this should look something like:

C:\Program Files\Git\cmd> start-ssh-pageant
Starting ssh-pageant...
SSH_AUTH_SOCK='/tmp/.ssh-pageant-heinz.doofenshmirtz'
SSH_PAGEANT_PID=11444

Assuming that the relevant keys have been loaded into Pageant, you should now be able to perform Git operations which rely upon them using OpenSSH without being prompted for the passphrase.

Configure Automatic Startup

The most common approach is to create a shortcut pointing to start-ssh-pageant.cmd, and place it in your startup folder (Start Menu / Programs / Startup). Once in place, it should be launched automatically when you logon to Windows and be available to all Git processes.

Windows 7

1. Click the Start button, right click on All Programs, and select Open
2. Navigate into the Programs folder, followed by Startup
3. Right-click on an empty spot within Startup, and select New / Shortcut
4. Click Browse, navigate to the cmd folder underneath your Git installation, and select start-ssh-pageant.cmd. Click OK.
5. Click Next
6. Enter an alternate name for the shortcut, if desired, and click Finish

Security Considerations

Since ssh-pageant (like ssh-agent) is intended to bypass the requirement to repeatedly enter your private key password, it's imperative that its socket file be private in order to use it safely. In other words, you want to be extremely careful on multi-user systems to ensure that the SSH_AUTH_SOCK file -- and preferably the directory which includes it -- isn't accessible to anyone else. For a normal Git for Windows configuration this shouldn't be an issue, as /tmp is normally mapped to a private location under your Windows user profile.

pid = /var/run/stunnel.pid
cert = /etc/stunnel/stunnel.pem
[ssh]
accept = 192.168.1.200:443
connect = 127.0.0.1:22

Mais cela peut créer une potentielle faille de sécurité : les utilisateurs ayant les droits suffisants sur le serveur (par exemple, root) pourront avoir accès à votre agent ssh, et donc utiliser vos clefs à votre insu, le temps de la session. Spécifier l’option “-c” lors de l’ajout de la clef à votre agent permet de limiter le risque, en vous demandant confirmation avant chaque utilisation de la clef.

# Utilisation de l’option "AgentForwarding" en spécifiant le flag "-A"
client> ssh -A user@62.23.55.220

# Vous pouvez désormais vous connecter sur le serveur cible : les clefs dans le SSH agent de votre client local seront utilisées.
bastion> ssh user@192.168.0.10

Bien évidemment, cela nécessite d’ajouter vos clefs publiques sur toutes les machines cibles.

Pour vous faciliter la vie, vous pouvez formaliser ces méthodes de connexion dans un fichier de configuration : celui par défaut (~/.ssh/config) ou bien un fichier qui vous spécifierez explicitement comme ceci :

client> ssh -F $FICHIER_DE_CONF_SSH

Pour notre exemple, cela donnera le fichier suivant :

Host bastion
  Hostname 62.23.55.220
  IdentityFile ~/.ssh/myPrivateKey
  User user

Host serveurA
  ProxyJump bastion
  Hostname 192.168.0.10
  IdentityFile ~/.ssh/myPrivateKey
  User user

Vous pourrez ainsi vous connecter directement à vos machines, sans spécifier la mécanique derrière, comme suit :

client > ssh serveurA

En utilisant ProxyJump, vous n’effectuez pas de connexion depuis le bastion, car toutes vos connexions sont initiées directement depuis le client.

#To install openssh with ssh daemon
choco install openssh -params '"/SSHServerFeature"' -y

#To enable ssh keyauth
Restart Windows

#To setup ssh keys
https://github.com/PowerShell/Win32-OpenSSH/wiki/ssh.exe-examples
cd ~
ssh-keygen.exe -t rsa -f id_rsa
copy id_rsa.pub .ssh\authorized_keys

Recently, Microsoft has released an early version of OpenSSH for Windows. You can use the package to set up an SFTP/SSH server on Windows.

Cet article va vous expliquer comment installer et configurer un serveur ssh sous Windows.

Un petit mémo/tutoriel sur le mise en place d’un serveur de sauvegarde avec BorgBackup. Il s’agit d’un logiciel de sauvegarde avec déduplication, qui supporte la compression et le chiffrement. Si vous voulez en savoir davantage je vous invite à aller jeter un coup d’œil à la documentation

Hello,

j'ai fait une petite modification d'un github pour avoir mon image de 2Mo d'alpine avec serveur ssh (pratique pour des images docker toutes petites)

le README:

Alpine ARMHF ssh server

Instructions

Key based usage (prefered)

Copy the id_rsa.pub from your workstation to your dockerhost.
On the dockerhost create a volume to keep your authorized_keys.

tar cv --files-from /dev/null | docker import - scratch
docker create -v /root/.ssh --name ssh-container scratch /bin/true
docker cp id_rsa.pub ssh-container:/root/.ssh/authorized_keys

For ssh key forwarding use ssh-agent on your workstation.

ssh-agent
ssh-add id_rsa

Then the start sshd service on the dockerhost (check the tags for alpine versions)

docker run -p 4848:22 --name alpinearmhf-sshd --hostname alpinearmhf-sshd --volumes-from ssh-container  -d alpinearmhf-sshd

Password based

docker run -p 4848:22 --name alpinearmhf-sshd --hostname alpinearmhf-sshd -d alpinearmhf-sshd
docker exec -ti docker-sshd passwd

From your workstation

ssh to your new docker environment, with an agent -i option is not needed

ssh -p 4848 -i id_rsa root@<dockerhost>

Installer le service SSH sous Windows grâce à Cygwin et un tutoriel d'Oracle...

merci ;)

Un tuto sur backupninja, à vérifier

Comment utiliser visualVM à travers un pont SSH ?

par un proxy socks:

ssh -D 9096 user@host

ensuite tools -> options -> network -> proxy socks -> localhost:9096

comment partager un répertoire entre qemu Guest et le host qui lance la machine virtuelle ?

c'est par ici (utilise samba)
on peux faire de même avec NFS ou SSHFS (je préconise sshfs pour ma part, plus rapide à mettre en place)

Comment se connecter en SSH à un serveur en passant par un proxy ?

et bien il faut tout d'abord passer par le port 443 (voir sslh ...)

puis dans .ssh/config :

Outside of the firewall, with HTTPS proxy

Host serveur_ssh_sur_port_443
ProxyCommand connect -H proxy_host:proxy_port %h 443

Inside the firewall (do not use proxy)

Host *
ProxyCommand connect %h %p

pour utiliser git@github.com:

Host github.com
ProxyCommand=ssh serveur_ssh_sur_port_443 "/bin/nc -w1 %h %p"

et voila !

date --set="$(ssh @192.168.251.117 date +%H:%M:%S)"

via pierre.

Aucune distribution n'est à l'abri...

Si ce sont les librairies comme OpenSSL / OpenSSH / OpenGPG qui sont corrompu...
Toutes les distributions les utilisent.

Par contre on peut mettre en place un "bruit de fond" en chiffrant TOUTES les données afin de les obliger à acheter en masse des supercalculateurs (et du coup cela se verra sur les factures ;) ).
Et surtout les obliger à "perdre du temps" en déchiffrant tout...

Je pense que la solution vient de la masse critique a atteindre pour que le gain à nous écouter soit plus faible que celui du cout à mettre en place pour cela.

et pour ceux qui n'ont pas easy_install ou pas pip :

curl http://python-distribute.org/distribute_setup.py | python

ensuite pour la dépendance :
pip install stdeb

Un remplaçant a ssh fait pour gérer les connections itinérante oO

A tester ;)