Arrêter la connexion ssh pour imprimer motd depuis le client?
J'ai configuré SSH sans mot de passe, mais il imprime le MoTD lorsqu'il se connecte. Existe-t-il un moyen d'empêcher cela du côté client?
J'ai essayé ssh -q mais cela ne fonctionne pas. Je ne veux pas utiliser ~/.hushlogin je ne souhaite pas non plus modifier la configuration du serveur. La seule chose qui peut fonctionner est de calmer toutes les sorties, avec >/dev/null 2>&1. Cependant, je ne veux pas ignorer les erreurs au cas où il y aurait réellement un problème. Même en faisant >/dev/null ne fonctionne pas, car ssh semble imprimer le motd sur le stderr.
Mise à jour et raisonnement J'exécute la sauvegarde dans un cron. Je ne veux pas recevoir d'e-mail cron à moins qu'une erreur ne se soit produite. Cependant, si le motd est imprimé, j'obtiendrai toujours un e-mail.
Je veux garder le motd imprimé car cela a des implications juridiques. Le motd dit "accès non autorisé interdit". Vous devez avoir ce genre de déclaration là-dedans pour empêcher légalement les gens d'y accéder (comme un signe de non-intrusion). Par conséquent, je ne veux pas le désactiver tout le temps.
Je ne sais pas pourquoi vous avez une aversion pour le faire correctement - soit sur le serveur à la
PrintMotd no
PrintLastLog no
et
#/etc/pam.d/ssh
# Print the message of the day upon successful login.
# session optional pam_motd.so
Ou en ajoutant ~/.hushlogin pour chaque utilisateur.
Astuce, pour ~/.hushlogin, ajoutez-le à/etc/skel pour que de nouveaux répertoires personnels soient créés avec le fichier.
Mise à jour:
Sans plus d'informations sur votre tâche cron de sauvegarde, ma seule autre suggestion est de rediriger la sortie de la commande vers un fichier (ou de laisser cron la capturer par courrier électronique) et la sortie de la session ssh vers/dev/null. Quelque chose comme:
0 0 * * * ssh backuphost "backup_script_that_writes_to_a_log" >/dev/null
Ou
0 0 * * * ssh backuphost "backup_command 2>&1" >/dev/null
Je devrais jouer un peu avec les commandes, mais cela devrait vous aider à démarrer.
Si vous le souhaitez pour chaque utilisateur, faites simplement un touch ~/.hushlogin et vous êtes prêt pour OpenSSH.
Mise à jour: Comme indiqué ailleurs, pam_motd peut être configuré pour ne pas utiliser un utilisateur par utilisateur .hushlogin; vérifier /etc/login.defs pour HUSHLOGIN_FILE. Il peut être configuré pour que tous les utilisateurs soient répertoriés dans /etc/hushlogins ou similaire.
@note Tous les exemples supposent que vous avez défini une variable connectionString avec quelque chose comme connectionString=user@server.
Comment je suis arrivé à la solution
En utilisant ssh -T devrait fonctionner pour les commandes simples. Par exemple, cela n'imprime aucune information supplémentaire:
ssh -T $connectionString "echo 'blah'"
Le problème est lorsque vous essayez d'utiliser here-doc pour exécuter de nombreuses commandes. Par exemple - le soufflet NE fonctionnera PAS - il fera écho au message du jour (MoTD) et pourrait également vous montrer "stdin: n'est pas un tty".
somethingLocal='something local'
ssh -T $connectionString <<EOC
echo 'blah'
echo "blah $somethingLocal"
EOC
Pour contourner le problème, vous devez d'abord enregistrer les commandes dans une variable locale et les envoyer au serveur distant.
somethingLocal='something local'
read -r -d '' commands <<EOC
echo 'blah'
echo "blah $somethingLocal"
EOC
ssh -T $connectionString "$commands"
Mais c'est désordonné ...
Solution finale
Créez une fonction universelle (notez qu'elle peut prendre une chaîne ou HEREDOC comme commandes).
function silentSsh {
local connectionString="$1"
local commands="$2"
if [ -z "$commands" ]; then
commands=`cat`
fi
ssh -T $connectionString "$commands"
}
Exemples
Utilisez ceci comme ceci:
somethingLocal='something local'
silentSsh $connectionString <<EOC
echo 'blah'
echo "blah $somethingLocal"
EOC
Ou comme ça:
silentSsh $connectionString "echo 'blah'"
Ou comme ça:
silentSsh $connectionString <<'EOC'
echo 'blah'
somethingRemote=`echo 'whatever'`
echo "blah $somethingRemote"
EOC
Ou même comme ça:
silentSsh $connectionString < getlines.sh
Et ce hack? ;-P
ssh -t user@machineName '/bin/bash'
Ce qui suit est pas valide:
Qui passe -T à ssh pour désactiver l'allocation tty:
ssh -T machineName 'echo foo'
De quel système d'exploitation s'agit-il? Sur certains systèmes (comme ubuntu), le motd n'est pas imprimé par le serveur ssh (PrintMotd dans/etc/ssh/sshd_config), mais par pam avec pam_motd. Si tel est le cas, vous ne pourrez probablement pas le contrôler à partir du client.
N'exécutez pas la commande ssh directement par cron.
Créez un script bash d'assistance à la place, exécutez le travail ssh et récupérez la sortie, les erreurs et le code d'erreur si nécessaire; éventuellement les analyser afin de supprimer les chaînes indésirables des messages d'erreur (le MoTD dans votre cas), puis réimprimer sur la sortie du script bash et les flux d'erreur ce que vous avez obtenu de cette manière.
Que mettre ce script bash en cron et vivre heureux :)
Remarque: Ceci est une solution générale, et doit fonctionner quel que soit le travail que vous devez effectuer via ssh. Ce n'est que du côté client aussi, qui devrait répondre à vos besoins ... la seule dépendance du client à la configuration du serveur est la connaissance du message exact que vous souhaitez supprimer de la std err ou du client ssh
Vous devez le faire sur le serveur:
PrintMotd no
PrintLastLog no
Sur debian/ubtuntu, hachez également la ligne avec pam_motd.so:
#/etc/pam.d/ssh
# Print the message of the day upon successful login.
# session optional pam_motd.so
Soit vous n'avez pas essayé ce que vous décrivez, soit vos serveurs sont mal configurés!
Voici ce que je viens d'essayer sur RHEL5:
workstation ~ $ ssh root@server
server ~ # echo "MOTD" > /etc/motd
server ~ # ^D
workstation ~ $ ssh root@server
MOTD
server ~ # ^D
workstation ~ $ ssh root@server echo notice the lack of motd
notice the lack of motd
workstation ~ $
Je suppose que vous n'avez pas besoin que l'avertissement soit envoyé à des shells non interactifs, n'est-ce pas? (Si quelqu'un prétend que vous le faites, faites-moi une faveur, donnez-lui un coup de pied dans les noix.) Parce que c'est exactement pourquoi il y a une distinction entre les coquilles interactives et non interactives.
Mais en tout cas, voici ce que je fais parce que je n'aime pas le courrier provenant de cron: je redirige la sortie vers l'enregistreur. Il suffit de le passer à travers la queue pour supprimer les premières (disons 3) lignes de votre dénégation inutile en tant que telle (code non testé, je n'ai pas accès à mes scripts):
( tail -n +3 | logger -i -t mycronjob -s -p cron.crit ) <&6 &
exec 2>&6
cron_fsckin_job
SOLUTION ICI:
Dans le cas où vous n'êtes pas responsable du serveur et que vous ne pouvez pas modifier la configuration motd ou sshd, utilisez la commande comme suit:
Redirigez STDERR vers STDOUT pour les commandes à distance afin que vous puissiez le voir. Ensuite, redirigez STDERR de ssh vers/dev/null. MOTD passe à STERR et se retrouve dans/dev/null. Tout message d'erreur standard ET de la commande à distance sera affiché (comme il va à STDOUT)
Variante 1 - si vous vous souciez de l'état de sortie de la commande exécutée à distance:
ssh remotehost "(remote_command1 && remote_command2; remote_command3) 2>&1" 2>/dev/null || echo SSH connection or remote command failed - either of them returned non-zero exit code $?
Variante 2 - si vous voulez ignorer le code de sortie de la commande à distance - exécutez simplement true comme dernière commande à distance
ssh remotehost "(remote_command; true) 2>&1" 2>/dev/null || echo SSH connection failed
Exemples de messages d'erreur:
Exemple 1:
ssh remotehost "échoué_remote_command 2> & 1 "2>/dev/null || echo La connexion SSH a échoué ou la commande distante a renvoyé un code de sortie différent de zéro bash: failed_remote_command: commande introuvable La connexion SSH ou la commande à distance a échoué - l'un ou l'autre a renvoyé le code de sortie non nul 127
Exemple 2:
ssh remotehost "échoué_remote_command 2> & 1; vrai"2>/dev/null || écho de la connexion SSH bash: failed_remote_command: commande introuvable
Exemple 3a:
ssh remotehost "échoué_remote_command 2> & 1; true "2>/dev/null || écho de la connexion SSH échec # aucun message n'est affiché
Exemple 3b:
ssh hôte inexistant "échoué_remote_command 2> & 1; true "2>/dev/null || écho de la connexion SSH échec La connexion SSH a échoué
Si je vous comprends, vous avez besoin de motd pour d'autres raisons, mais pas de motd pour la sauvegarde. Dans la configuration de sshd, il ne peut pas être configuré par utilisateur uniquement globalement. Par conséquent, vous devez résoudre la suppression de motd du côté client. Mais il n'y a pas de différence entre le texte de motd et les messages d'erreur du logiciel de sauvegarde. Les deux sont du texte dans le terminal. La seule solution que je vois pour faire la différence entre ces deux messages, puis filtrer celui du motd. Parce que les messages du logiciel sont difficiles à modifier, je suggère de modifier le texte de motd. Par exemple, mettez un cadre autour:
*** BEGIN message from the machine room ***
motd message
*** END message from the machine room ***
Ensuite, vous devez filtrer le texte entre le cadre et le déposer.
Avez-vous essayé de supprimer le texte du fichier motd? Juste une pensée.
Hint: /etc/motd
Qu'essayez-vous de faire et pourquoi le MoTD vous dérange-t-il? Je suppose l'exécution d'une commande à distance et l'analyse de la sortie? Si c'est le cas, cela pourrait être fait de différentes manières sans invoquer un shell interactif (ce qui provoque l'affichage du motd).
Avez-vous essayé d'utiliser une configuration de sous-système ssh? Vous pouvez trouver un exemple sur http://www.hell.org.ua/Docs/oreilly/tcpip2/ssh/ch05_07.htm qui inclut même la sauvegarde de fichiers.